[prev] [thread] [next] [lurker] [Date index for 2006/05/26]
* On 2006.05.26, in <20060526155250.GA30730@xxxxxxxxx.xxxxxxx.xxx>, * "Phil Pennock" <phil.pennock@xxxxxxx.xxx> wrote: > > No, but it does argue against having a default action produce desirable > behaviour, where that action is subject to implementation doing OK, but... > But that's the behaviour which the OP hated. I'd just hate it if things > did as the OP likes things. Each to their own. I think you're conflating the OP with someone else, FTR. Suggesting that all unrecognized options map onto --help one to one was someone else's contribution. Not that this matters; your point is your point, no matter who you're disagreeing with. Myself, I like something along the lines of "-@ is an error. here is short usage text." But I never put long usage information in my built-in help anyway; that belongs in a manual, not in the last three screensful of my terminal window. In this arrangement, both interests are met. It's clear what is not a known option, and it's actually helpful rather than meta-helpful. The OP asked that -h be made a published interface to help, absent any particular reason not to. So what's a particular reason not to? I say: not much. Myself, I always make -h produce help up front. (And sometimes also --help, even though I rarely use --godawful-long-options.) It's easy; it makes sense; it can be anticipated by a broad set of users. I'm not concerned with BSD- or GNU-similitude should the program one day present alternative behaviors with respect to symbolic links or file sizes. My program will never be a BSD program or a GNU program, so why should I? And why should "use lstat/lchown/lwhatever" take precedence over "help, please" anyway? If you need lsomething(), you're familiar enough to find out how to do it, or to remember. If you need help, you know little to nothing. Help should be the easiest thing to get. -- -D. dgc@xxxxxxxx.xxx NSIT University of Chicago
Generated at 09:00 on 29 May 2006 by mariachi 0.52