Last Comment Bug 355889 - No command line parameters -help (e.g., for langpacks, profiles)
: No command line parameters -help (e.g., for langpacks, profiles)
Status: RESOLVED INVALID
[has workaround, see comment #4]
:
Product: Core Graveyard
Classification: Graveyard
Component: Cmd-line Features (show other bugs)
: Trunk
: x86 Windows 2000
: -- normal with 6 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
: 26761 353236 661852 806479 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-07 15:32 PDT by gekacheka
Modified: 2015-05-31 14:41 PDT (History)
18 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description gekacheka 2006-10-07 15:32:09 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
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:

-p 
  for creating/managing/choosing profiles

-P profileName
  for starting with an existing profile

-UILocale ab-CD 
  for choosing a langpack (for people who share sunbird on a computer with someone who prefers a different language)

Reproducible: Always

Steps to Reproduce:
1. Start sunbird from the command line with 
   sunbird -?
   sunbird -h
   sunbird -help


Actual Results:  
sunbird exits immediately with no message

Expected Results:  
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).
Comment 1 Simon Paquet [:sipaq] 2006-10-07 16:26:05 PDT
*** Bug 50596 has been marked as a duplicate of this bug. ***
Comment 2 Simon Paquet [:sipaq] 2006-10-07 16:26:26 PDT
*** Bug 26761 has been marked as a duplicate of this bug. ***
Comment 3 Simon Paquet [:sipaq] 2006-10-07 16:27:21 PDT
*** Bug 207280 has been marked as a duplicate of this bug. ***
Comment 4 Tony Mechelynck [:tonymec] 2006-10-07 17:24:30 PDT
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.
Comment 5 Wayne Mery (:wsmwk, NI for questions) 2006-12-17 09:31:35 PST
will be fixed by bug 328887, according to bug 207280.
Comment 6 Mark Banner (:standard8, afk until Dec) 2006-12-22 04:20:01 PST
(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?
Comment 7 Wayne Mery (:wsmwk, NI for questions) 2008-08-23 12:21:36 PDT
*** Bug 353236 has been marked as a duplicate of this bug. ***
Comment 8 Wayne Mery (:wsmwk, NI for questions) 2008-10-10 08:27:39 PDT
(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?
Comment 9 Charles Evans 2009-03-27 10:28:02 PDT
Works for me on Linux, Firefox 3.0.7
Comment 10 Benjamin Smedberg [:bsmedberg] 2009-05-04 13:31:01 PDT
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.
Comment 11 gekacheka 2009-05-04 14:31:35 PDT
Please explain:  How is this bug report 'incomplete'?  What additional information is needed?

(In reply to comment #10)
> Benjamin Smedberg  [:bs] (bsmedberg) <benjamin@smedbergs.us> 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
> Linux.
Comment 12 John David Galt 2009-05-05 22:36:46 PDT
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.
Comment 13 gekacheka 2009-05-06 05:27:44 PDT
(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.)
Comment 14 Karsten Düsterloh 2009-11-15 07:56:17 PST
(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! 

Reopening.
Comment 15 timeless 2009-11-15 23:54:10 PST
ok. to simplify matters: "This bug is dead."

-help does produce help, and it produces help for command line parameters.

=> INVALID.

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.
Comment 16 Philip Chee 2011-06-03 10:20:01 PDT
*** Bug 661852 has been marked as a duplicate of this bug. ***
Comment 17 Terrell Kelley 2012-06-20 00:20:16 PDT
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.
Comment 18 John David Galt 2012-06-20 08:30:21 PDT
Bug 403920 seems to address the same problem.  I hope he doesn't kill that one, too.
Comment 19 Mark A. Ziesemer 2012-07-08 20:30:13 PDT
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.
Comment 20 Kastor 2013-02-14 17:11:13 PST
"
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]
"
-- timeless



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.
Comment 21 Terrell Kelley 2013-03-10 17:05:18 PDT
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.
Comment 22 Tony Mechelynck [:tonymec] 2013-03-10 21:29:07 PDT
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.
Comment 23 Kastor 2013-03-10 23:41:52 PDT
From the desk of Matthew Kastor

On this glorious Monday, March 11, 2013

Summary

An even more Glorious reacharound

Message

@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!

https://github.com/matthewkastor/Redirector





Matthew Kastor

Contact Info

Phone:	(616) 439-0091
Email:	matthewkastor@gmail.com
Google Profile:	https://plus.google.com/100898583798552211130/posts
Blogger:	http://matthewkastor.blogspot.com/
Github:	https://github.com/matthewkastor?tab=repositories


Disclaimer

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.

Copyright notice

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.
Comment 24 Eric Hughes 2013-03-11 05:18:13 PDT
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.
Comment 25 Matthias Versen [:Matti] 2014-09-21 15:55:48 PDT
*** Bug 806479 has been marked as a duplicate of this bug. ***
Comment 26 dave 2014-11-12 09:53:09 PST
Somebody can and should fix -help.

Supporting statements:

* 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.
Comment 27 tyaremco 2015-05-31 14:41:36 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.