🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: gnu.misc.discuss
Article #73029

Re: Who wants long options anyway? (Re: Poll: syntax of long options)

#73029
From: Roland Dunkerley
Date: Thu, 07 Nov 1991 19:31
40 lines
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!orion
References: <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