User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:18.104.22.168) Gecko/20060909 Firefox/22.214.171.124
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061006 Sunbird/0.3 [0.3rc2]
There is no command line help for command line parameters.
Command line parameters many users need to know about include:
for creating/managing/choosing profiles
for starting with an existing profile
for choosing a langpack (for people who share sunbird on a computer with someone who prefers a different language)
Steps to Reproduce:
1. Start sunbird from the command line with
sunbird exits immediately with no message
Sunbird prints command line parameters help message, then exits.
Even better: whenever sunbird finds unknown command line parameters, it prints help and exits (so works for any language).
*** Bug 50596 has been marked as a duplicate of this bug. ***
*** Bug 26761 has been marked as a duplicate of this bug. ***
*** Bug 207280 has been marked as a duplicate of this bug. ***
Workaround (works with Firefox, Thunderbird, and, I suppose, other programs too):
<program-name> -h | more
The bug happens because, without redirection, the program releases its stdout before handling the -help parameter. With redirection, stdout is not released and you can see the output.
will be fixed by bug 328887, according to bug 207280.
(In reply to comment #5)
> will be fixed by bug 328887, according to bug 207280.
No it won't. Those bugs are SeaMonkey specific.
Does this affect debug builds or is this release builds on Windows only?
*** Bug 353236 has been marked as a duplicate of this bug. ***
(In reply to comment #6)
> (In reply to comment #5)
> > will be fixed by bug 328887, according to bug 207280.
> No it won't. Those bugs are SeaMonkey specific.
> Does this affect debug builds or is this release builds on Windows only?
perhaps joshua could say?
Works for me on Linux, Firefox 3.0.7
If this is Windows-only (caused by Windows virtual consoles), I don't really care: Windows users rarely use commandline args anyway. This seems to work on Linux.
Please explain: How is this bug report 'incomplete'? What additional information is needed?
(In reply to comment #10)
> Benjamin Smedberg [:bs] (bsmedberg) <email@example.com> changed:
> Status|NEW |RESOLVED
> Resolution| |INCOMPLETE
> If this is Windows-only (caused by Windows virtual consoles), I don't really
> care: Windows users rarely use commandline args anyway. This seems to work on
Sometime shortly before the 3.0 release, *all* command-line args in all Mozilla apps on Windows seem to have been disabled en masse -- not just -help. This is a major annoyance because it means I can no longer create shortcuts (desktop icons) with options that do useful things such as -p <profile name> or -offline.
(In reply to comment #12)
> I can no longer create shortcuts ... such as -p <profile name> or -offline.
This is the wrong bug for that problem.
Command line parameter -P works fine for me (on w2k), both on command line and in shortcuts.
This bug is about -help text not showing up in the command line window, so command line parameters are undiscoverable.
(back to this bug: I would like to know how this bug report is 'incomplete', what additional information is needed.)
(In reply to comment #10)
> If this is Windows-only (caused by Windows virtual consoles), I don't really
> care: Windows users rarely use commandline args anyway.
Yes, it's Windows only.
But that's no justification for calling this bug incomplete,
especially not since bug 26761 got duped here!
ok. to simplify matters: "This bug is dead."
-help does produce help, and it produces help for command line parameters.
that it happens to not produce help that is visible in your cmd prompt unless you use a pipe is not particularly interesting to anyone.
Please note that Microsoft has for perhaps a decade recommended the approach we use, and has also generally moved its own applications to follow this recommendation.
If you reopen this bug, I will WONTFIX it and then work to have your bugzilla bits removed. Please don't tempt me.
*** Bug 661852 has been marked as a duplicate of this bug. ***
No, this is not recommended behavior, and, no Microsoft does not do this. All of their apps still support the /? switch on the command line, and give results. It is too very interesting that you have a BUG where you shutdown stdout before the application is finished working, one that other Windows programs do not have. It might not be a priority fix, but it's still a bug.
And, no, bullying me by threatening to remove my bits won't work. Such behavior is unacceptable on this or any other collaborative project. If someone says something you think is wrong, you can present arguments for why they are wrong, and work to find a solution, not try to ban them because they disagree with you.
Bug 403920 seems to address the same problem. I hope he doesn't kill that one, too.
Please re-open this bug and move out of the graveyard, or provide a reference to where Microsoft "recommends this approach" without requiring a workaround for providing a working "/?" command-line option.
Status: RESOLVED INVALID
-- Bug 355889
Works for me on Linux
-- Charles Evans
If this is Windows-only [...], I don't really care: Windows users [are retards]. This seems to work on Linux.
-- Benjamin Smedberg
-help does produce help , and it produces help for command line parameters [just not on windows].
that it happens to not produce help [on windows] that is visible in your cmd prompt unless you use a pipe is not particularly interesting to anyone [i.e. we don't give two ****].
[lies] Please note that Microsoft has for perhaps a decade recommended the approach we use, and has also generally moved its own applications to follow this recommendation. [/lies]
The bug that causes help text to be absent on the windows command line is the same bug that requires Firefox, Thunderbird, XULRunner and others to have to create a useless console window when the -console option is used. This means that while we're trying to develop applications for XULRunner or debug addons for Firefox, Thunderbird, etc. we have an additional handicap to completing projects.
That so much effort was put into fixing -no-remote and adding -new-instance, just to get things going on X, yet this BUG here is considered invalid simply because it affects windows users is telling.
Let's do the math. Take the total number of users, subtract everyone who doesn't use multiple profiles on X regularly. Hold that number in memory, let's call it "fuckin nobody". Now take the number of users, subtract everyone who doesn't use windows and take the idea that windows users are dipshits who can barely work a mouse and shove it up your ass. Let's call this number "much more substantial than". Finally we have a solution: the number of Windows users is "much more substantial" than "fuckin nobody".
It seems like every time I turn around I'm running into some intentionally manufactured problem intentionally designed to make it difficult to develop Gecko based "anything" on Windows. It also seems to be a rather strong opinion within the Mozilla developer community that windows users are **** stupid. This is disturbing.
I'm just trying to imagine how many hours of work went into hacking in workaround solutions addressing this same issue where stdout and stderr never make it to the console. Sure redirecting to a file or piping to more works, and I hear you can run a car on pig ****. Neither one of them sounds like an ideal solution to me.
Animosity aside, the above poster is correct. A bug is not fixed because a workaround can be found. Claiming you don't care because people won't see your bug is disturbing. It really is hard to read that as anything but a slight against Windows users.
If anyone should have their bits removed, it's timeless, for marking a bug as RESOLVED INVALID when it doesn't fit Mozilla's rules for doing such.
I will leave other comments about the actual issue to the other bug mentioned. I will just point out that, if you don't want this type of animosity, don't let developers get away with this sort of thing.
Valid or not, it seems clear to me that this bug will never be fixed. Maybe the owner of the relevant Module, or whoever acts as owner if the module is unowned, should mark this bug WONTFIX, it will better reflect reality.
From the desk of Matthew Kastor
On this glorious Monday, March 11, 2013
An even more Glorious reacharound
@Terrel Kelley You're making great sense. Thank you for your support.
@Tony Mechelynck It does indeed appear that this is a WONTEVERFIX issue and agree that reclassification would better reflect reality.
Luckily for everyone, an even more Glorious reacharound has been devised. Using Atropa Inc. Intl.'s Amazing Redirector, not only can windows users get console output redirected to the console they launched Firefox from but, they can also get help options on screen. But wait, there's more! They can also do whatever else a person would normally do with stdin & stdout without resorting to piping data into useless dead ends!! Give it a try today! Slap the Redirector right behind Firefox and reacharound to the pipe. You'll get a fist full of data in no time and can spread it around in any way that tickles your fancy!
Don't wait, ACT NOW!
Phone: (616) 439-0091
Google Profile: https://plus.google.com/100898583798552211130/posts
This email and any files transmitted with it are confidential, privileged, and/or otherwise protected by work-product immunity or other legal rules. This email and any files transmitted with it are intended solely for the use of the individuals or entities to whom they are addressed. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please notify Mr. Kastor immediately. Mr. Kastor accepts no liability for the content of this email or for the consequences of any actions taken on the basis of the information provided.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. Mr. Kastor accepts no liability for any damage caused by any virus transmitted by this email. Email transmission cannot be guaranteed to be secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Mr. Kastor, therefore, does not accept liability for any errors or omissions in the contents of this message which arise as a result of email transmission.
This email and its content is copyright of Matthew Kastor - © Matthew Kastor 2013. All rights reserved.
Any transmission, redistribution, or reproduction of part or all of the contents in any form is strictly prohibited. You may not, except with Mr. Kastor's express written permission, distribute or commercially exploit the content. You may not transmit it or store it in any other form of electronic retrieval system other than the email system to which this message was originally delivered. Any written permission granting use of these contents must be notarized to be considered for validity.
I just got bitten by this defect while working on an extension under Windows 7. I was trying to see if a component was registering correctly by seeing if its helpInfo was showing up on the screen. Nothing was showing up at all. I only found this defect when I decided to search to see if I had spelled "-help" correctly.
*** Bug 806479 has been marked as a duplicate of this bug. ***
Somebody can and should fix -help.
* Some of the statements made in this thread half a decade ago aren't in line with Mozilla's current marketing goals (Aurora --> Dev Edition).
* The command line on windows is currently entering a sort of renaissance--reports indicate that the next major release of Windows will have a command-line based package manager.
Somebody can and should fix -help. Thank you for your time.
This is absurd. Windows users (who are unaware of an obscure workaround) need to Google command line parameters for Firefox? Ridiculous. Just fix the command so it behaves as it should.
> If you reopen this bug, I will WONTFIX it and then work to have your bugzilla bits removed.
> Please don't tempt me.
What is this nonsense?
This bug is neither RESOLVED nor INVALID.