Article View: gnu.misc.discuss
Article #73029Re: Who wants long options anyway? (Re: Poll: syntax of long options)
From: Roland Dunkerley
Date: Thu, 07 Nov 1991 19:31
Date: Thu, 07 Nov 1991 19:31
40 lines
2926 bytes
2926 bytes
In article <1991Nov6.163614.942@nntp.uoregon.edu> haertel@euclid.uoregon.edu writes: >I don't think long options are of any use themselves, but I occasionally >find it helpful that getopt has long names compiled in with the short names, >because it can automatically produce a usage message that lists all the >possible options together with (by virtue of the long names) some indication >of what they do. That's mainly what I use the long options for. As an aside, find has had long options all along, and is much easier to learn to use because of it, maybe providing short options for find would be consistant with the long options added for other programs. For things like gcc, (-fstrength-reduce, ...) the long options make a lot more sense than any other means of accessing specific optimisations (-f[0-9a-zA-Z], perhaps? :-)) I rarely use the long options in the standard (from unix) utilities, but I imagine this is partially because I've been doing fine without them for years (as long as I've had a stack of manuals within digging range). > >Brian Fox would probably tell you that the long options will be useful >someday for shell completion of program options. This would be nice from a use standpoint, but would be inelegant if it were built in to the shell at compile time. Maybe this is in fact the wrong newsgroup for this point in particular, but I've just had an idea in this area. Maybe programs could either come with an auxilliary file or have a string compiled in (kind of like the SCCS strings for what) that would specify option syntax for the shell to use in doing completion. Which would be better? I can think of points in favor of either approach. Having a seperate file would be more efficient in some cases, or maybe even have the option syntax be 'compiled' in to a gdbm file at installation time. That would win for efficiency, one would think... -- Roland Pleasant Dunkerley III orion@nuchat.sccsi.com Opinions expressed herein are mine and Eris' alone, others are hereby spared from incrimination. Someone send me some decent hardware please, this MDA monitor is killing me... :-) (I can wish, can't I?)
Technical Details
Message-ID:
<1991Nov7.193122.23496@nuchat.sccsi.com>Path:
arc1-ca.pugleaf.net!gmdzi!zeus.ieee.org!sdd.hp.com!zaphod.mps.ohio-state.edu!menudo.uh.edu!buster!nuchat!orionReferences:
<ABRAHAM.91Oct29173322@freja.iesd.auc.dk> <DAMIAN.CUGLEY.91Nov4142743@pierrot.prg.ox.ac.uk> <1991Nov6.163614.942@nntp.uoregon.edu>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1025b4,5071a1d1ccc07109 X-Google-Attributes: gid1025b4,public X-Google-ArrivalTime: 1991-11-07 13:53:45 PST Path: arc1-ca.pugleaf.net!gmdzi!zeus.ieee.org!sdd.hp.com!zaphod.mps.ohio-state.edu!menudo.uh.edu!buster!nuchat!orion From: orion@nuchat.sccsi.com (Roland Dunkerley) Newsgroups: gnu.misc.discuss Subject: Re: Who wants long options anyway? (Re: Poll: syntax of long options) Message-ID: <1991Nov7.193122.23496@nuchat.sccsi.com> Date: 7 Nov 91 19:31:22 GMT References: <ABRAHAM.91Oct29173322@freja.iesd.auc.dk> <DAMIAN.CUGLEY.91Nov4142743@pierrot.prg.ox.ac.uk> <1991Nov6.163614.942@nntp.uoregon.edu> Organization: Eristic Rite In Software, Houston, Tx. Lines: 40