in mozilla/xpfe/bootstrap/nsAppRunner.cpp I started the work for -h,--help,-help,-v,-version,--version support. mcafee, can you finish that work? all that's left is dumping out the right text. see DumpHelp() and DumpVersion() in nsAppRunner.cpp I put the code to do that right after main() gets called, so -v and -h return quickly, without doing a bunch of COM crap. if we want to make the -v and -h output localizable (tao?), we should use a string bundle, and that may means we have to move the -v / -h to after some COM stuff gets initialized.

Why do you have this bug? (Moving to M13)

we have this bug because -v and -h don't work yet. it's a place holder bug. it's really low priority.

Updating QA Contact

M15.

I've fixed the -help part of this, now we need a way to find the version from C++, over to cyeh, the version czar.

I just noticed that mozilla calls run-mozilla.sh which will eat the -h flag, instead of passing it through to mozilla-bin, which is one that will spit out the help when you pass it -h. perhaps we should tweak run-mozilla.sh so that it dumps usage when it gets -h, and then passes -h to mozilla-bin, instead of just dumping usage and then exiting?

or, just let mozilla-bin handle -h. either way, scripts should pass unhandled flags on to the mozilla binary, we'll need this for gtk/X11 flags like --sync.

I agree, let mozilla-bin handle -h but the problem is if you run the app by doing mozilla, this calls run-mozilla.sh, which will eat the -h and exit, before we even get to mozilla-bin

Version problem still exists. Moving argument handling discussion to bug 23084.

looks like mcafee should own this, not me

Move to M16 for now ...

Putting on [nsbeta2-] radar. If someone can help to get this done. Let us know.

Move to M20 target milestone.

posted patch that implements -version, I get an assert in nsServiceManager, but ? we exit right after that so maybe this is Ok.

Nav triage team: [nsbeta3+]

Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so the queries don't get all screwed up.

PDT marking P4 and putting [PDTP4] in status whiteboard

mcafee, have you had a chance to get the patch reviewed for checkin? thx!

Marking "nsbeta3-".

why was this minused? there's a patch attached waiting for review... (sorry about my previous comment, forgot mcafee submitted the patch himself.) clearing status for pdt to reconsider.

This is nsbeta3- because it's just not a serious problem that we need to fix for b3 or rtm.

It seems unclear to me whether this bug requires either of a "developer" or "user" release note. If anyone feels it does, can they please draft one and then nominate with the relnote-user or relnote-rtm strings in the Status Whiteboard. Thanks :-) Gerv

to get the browser version, please run [...] -version instead of [...] -version. Or just run the app and go to help about. [...] because i don't know which the things are :-(

Netscape Nav triage team: this is not a Netscape beta stopper.

I've revised mcafee's patch. I'll attach it. mcafee / alecf, can you review? I'm not getting the assertion that mcafee reported.

on linux, here is what my debug build spits out: Mozilla/5.0 (X11; N; Linux 2.2.12-20 i686) <developer build> that is preceeded by some other debugging printfs. the total output from my debug linux build is: > ./mozilla -version ./run-mozilla.sh ./mozilla-bin -version MOZILLA_FIVE_HOME=/builds/seth/seamonkey/mozilla/dist/bin LD_LIBRARY_PATH=/builds/seth/seamonkey/mozilla/dist/bin LIBRARY_PATH=/builds/seth/seamonkey/mozilla/dist/bin:/builds/seth/seamonkey /mozilla/dist/bin/components SHLIB_PATH=/builds/seth/seamonkey/mozilla/dist/bin LIBPATH=/builds/seth/seamonkey/mozilla/dist/bin ADDON_PATH=/builds/seth/seamonkey/mozilla/dist/bin MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= Type Manifest File: /builds/seth/seamonkey/mozilla/dist/bin/components/xpti.dat HTTP Handler: Instantiating contractid @mozilla.org/cookie-notifier;1 in http startup category. Mozilla/5.0 (X11; N; Linux 2.2.12-20 i686) <developer build>

why did you remove the "static" aspect of this function? sr=alecf with "static" returned

removing static was not intentional. I've added it back and I've checked it in. thanks for the review. thanks to mcafee for the original patch.

thanks for chasing this down, seth.

works just spiffily on linux [comm verif 2000.12.21.08 bits], but not on win32 verification bits. am gonna verify this anyhow, since it works on win32 debug. will add a note to bug 26761 on that...