Closed Bug 355889 Opened 18 years ago Closed 15 years ago

No command line parameters, -help (e.g., for langpacks, profiles) doesn't display on Windows

Categories

(Core :: General, defect)

x86
Windows
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: gekacheka, Unassigned)

References

Details

(Whiteboard: [has workaround, see comment #4])

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).
Component: Sunbird Only → Cmd-line Features
Product: Calendar → Core
QA Contact: sunbird
Version: unspecified → Trunk
*** 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.
Summary: No command line parameters help (e.g., for langpacks, profiles) → No command line parameters -help (e.g., for langpacks, profiles)
(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?
(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?
QA Contact: cmd-line
Whiteboard: [has workaround, see comment #4]
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.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → INCOMPLETE
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.
Product: Core → Core Graveyard
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! 

Reopening.
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
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.
Status: REOPENED → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → INVALID
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]
"
-- 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.
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

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.
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.
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.
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.
@timeless
>ok. to simplify matters: "This bug is dead."
You probably meant "This bug report is dead" beacause the bug is well alive, and smells bad.

>-help does produce help, and it produces help for command line parameters.
>=> INVALID.
I don't know what INVALID means on bugzilla, but again you must be referring to the bug report, because the bug doesn't care if you consider it valid or not, it's still there, whether you like it or not. 

>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.
Ok. That could be an argument: "We have 1000s things to do and this is not very important, especially since there's a simple workaround". But my wording is much respectful. 
I perfectly understand that problems to be solved have to be "interesting" (especially if you working for no pay), BUT stating that a problem is stupid BECAUSE you find it "not particularly interesting" is illogic.

>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.
I know nothing about gecko architecture nor about Microsoft consoles. 
I know firsthands that MS itself keeps bug forever. But this is no excuse for defending bad code. 
99% of developers managed to have help on the command line (what a feat!). 
It is pathetic pointing finger to the 1% that might have had a problem like us or excruciated the problem itself in the first place.

Don't know you but when people find bug in my code I smile, I say I'm sorry, maybe a give some insight and then get to work to fix it. You must have some big anger towards that code.

>If you reopen this bug, I will WONTFIX it 
As other stated WONTFIX could be more honest. But even more accurate would be to leave it unassigned and set it open.

>and then work to have your bugzilla bits removed. Please don't tempt me.
Menaces suggest that you don't really care of what is right or wrong.

>Reported:	11 years ago
I saw it happen many times everywhere, but it's still a shame.
Summary: No command line parameters -help (e.g., for langpacks, profiles) → No command line parameters, -help (e.g., for langpacks, profiles) doesn't display on Windows
Component: Cmd-line Features → General
OS: Windows 2000 → Windows
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.