1 Aug
2021
1 Aug
'21
4:20 a.m.
-- Bakul
On Jul 31, 2021, at 3:16 PM, Jon Steinhart
<jon(a)fourwinds.com> wrote:
Bakul Shah writes:
:-)
On Jul 31, 2021, at 12:20 PM, Jon Steinhart
<jon(a)fourwinds.com> wrote:
Ah, well, you've given away the secret of real UNIX geezers, we're on both
this mailing list and the nmh list :-)
So I never got getopt(). One of my rules is that I don't use a library
in cases where the number of lines of gunk that that it takes to use a
library function is >= the number of lines to just write it myself. Yeah,
I know the "but the library has more eyeballs and is debugged" argument
but in reality libraries are the source of many bugs. I've always taken
the approach that I would never hire someone who had to use a library to
implement a singly-linked list.
getopt() is perhaps the wrong solution but consider something like MH,
whose commands all follow a common pattern. Consider:
- options (switches) all start with a single '-'
- they may be abbreviated to a unique prefix.
- Boolean options may be inverted by prepending -no (e.g. -nolist)
- value options may also have -no format to remove a previous (or default) value
- options may appear anywhere and the last instance wins
But different commands take different options. It would make sense to factor
out common parsing, help etc. for a consistent treatment. In my Go code for
parsing MH like options I used Go's flag package as a model.
Personally I vastly prefer MH style option processing to either single char
options or --very-long-names which can't be abbreviated. Never mind options for
commands like gcc, who can even remember 40+ ls options?
But I haven't thought about how to extend this for shell scripts, or
exposing these so that shells like zsh can do command completion. To specify
these you need a vector of tuples (name, type, default, brief-help) but that
is painful to do in a shell. Yes, I'm mostly happy with the way that nmh does
options.
I guess that I would look more kindly on getopt if it had existed much earlier
so that people writing new commands would be encouraged to use the same format.
Not as happy with it as an afterthought.
Once again, I have to go back to the meatspace locality of reference issues.
Sure, it would be nice to be able to factor out common parsing, for example
if a related set of programs shared the same option set. But unless it's
something huge, I'd just put it in it's own file and use it for multiple
programs; I wouldn't put it in a library. My point is that the code that
does the actual parsing is really trivial, and not necessarily the best
use of a library.
As far as help goes, I don't expect help built into command line programs;
I expect to look up error messages on the manual pages. I'm happy with a
generic usage error as most "helpful" output that I get from programs is
not actually helpful.
Note that -help in MH program is far more useful as it spells out the full option name.
Consider
% refile -he
Usage: refile [msgs] [switches] +folder ...
switches are:
-draft
-[no]link
-[no]preserve
-[no]retainsequences
-[no]unlink
-src +folder
-file file
-rmmproc program
-normmproc
-version
-help
...
vs
% ls -z
ls: invalid option -- z
usage: ls [-ABCFGHILPRSTUWZabcdfghiklmnopqrstuwxy1,] [--color=when] [-D format] [file
...]