On 09:02 10 Nov 2002, Mikhael Goikhman <[EMAIL PROTECTED]> wrote: | > With that preamble, in my shells I expect to be able to go | > foo -? | > to most programs and get a usage message _because_ -? is not a valid | > option. And I insist on my shells letting me type an unescaped -?, | > and take care not to make stupidly named -* files. | | You know, zsh and tcsh by default give you an error on unescaped -?.
I'm a zsh user myself, and turn that behaviour off. I consider it a sop to [t]csh users (zsh has extensive "pretend to be csh" customisation options). | > So, what's I'm asking here is that: | > - whether you implement an actual -? option doesn't | > bug me, provided that _any_ bad option elicits the | > full usage string | | It is good that you said GNU tells to print 2 lines only in this case, | so I don't need to add more than several paragraphs of reasonings. :) | I am against dumping the whole usage (that is usually more than 24 lines | since all my programs are very configurable) every time a user makes a | typo. For long usage messages, I agree. For short (eg up to, say, 12 lines?) I'd much rather get a usage message than have to invoke the program yet again. [...] | The only correct way to handle a bad option is to print 2 lines: | | program: unrecognized option '-o' (or: missing file argument after -o) | Run --help to get the list of all recognized options. For many-option commands, again I agree. But _please_, support '-h' in addition to '--help'; --help is a pain to type for such a trivial task. | A user knows what he does if he specified -o option, he wants the result | now. Or to see the diagnostic error line to know what he did wrong. He is | not interested in anything forced like copyright/license/--version/--help. Speaking as a user: agree/agree/maybe/disagree. Unless the help is very long. | (In fact, IMHO the only place for copyrights is the man page and sources.) Yep. | And I would prefer these two lines to be dumped to stderr like gcc does it | and not stdout like gnome-terminal does it. Because stdout should contain | the result of the program's run designed to be parsable/piped, an error | option should not damage the expectations of the following piped program. And also, not only does error->stdout bugger the pipeline, it swallows the error message from the user's eyes! | In any case, I would not blindly follow all GNU "standards", only the | reasonable ones. Even GNU projects do not follow all of them. Hear hear! Cheers, -- Cameron Simpson, DoD#743 [EMAIL PROTECTED] http://www.zip.com.au/~cs/ Pardon my driving, I'm trying to reload. -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
