On 10 Nov 2002 23:08:21 +0100, Dominik Vogt wrote: > > On Sun, Nov 10, 2002 at 09:02:34AM +0000, Mikhael Goikhman wrote: > > > > 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. A user wants to see that "option -X is not supported", he does not > > need to go several screens up to determine whether this option means > > "show usage" or it is unrecognized or maybe needs an additional argument. > > 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. > > The proper solution - in my eyes - is to print the > "unknown option xyz" message *after* the usage message. If the > verbose message is too long it should omit the lengthy > explanation. And of course only the one letter options belong > into the usage line. For example: > > $ foobar -z > usage: foobar [-a] [-b] [-c] ... [-x] [-y] <- one to two lines > foobar: unknown option -z > 1 $ <-- return code 1 > > and > > $ foobar --help > usage: foobar [-a] [-b] [-c] ... [-x] [-y] <- many lines > -a: explanation of option a > -b: explanation of option b > ... > -x: explanation of option x > -y: explanation of option y > 0 $ <-- return code 0
If a short usage line helps, it may be added. But usually a usage line with dozens of unrelated options (especially a one letter ones and without description) only distracts an attention from the actual error message. I am pretty happy with how programs in bin/ handle the situations. (BTW, it always bugged me that "fvwm-bug --help" tried to send an email.) > I think this is a good solution in between. I have committed a > patch that cleans up the chaos in the fvwm executable and the man > page and uses this style. Take a look and tell me what you think. > Try "fvwm -x" and "fvwm --help". Hmm, I don't like too much short names. If it is a unix command that is run often short names help, fvwm is not run often by hand. I would only support long names except for the backward compatibility (-d, -f, -s). You see we already ran out of letters, this is not really necessary. Do you think a usage line like this helps to understand anything: fvwm (2.5.5): usage: fvwm [-d display] [-D] [-f cfgfile] [-c cmd] [-s] [-V] [-h | -?] [-r] [-i client-id] [-F sm_file] [-I vis-id | -C vis-class] [-l colors [-L] [-A] [-S] [-N]] See also 'xv -reuse', can you understand what was a problem? Hardly, but at least it uses long descriptive option names. Long names are good. But I just let you decide what should be the option list of fvwm itself. Regards, Mikhael. -- 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]
