1 Aug
2021
1 Aug
'21
4:04 a.m.
On Jul 31, 2021, at 12:20 PM, Jon Steinhart <jon(a)fourwinds.com> wrote:
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.