1 Aug
2021
1 Aug
'21
4:17 a.m.
On Jul 31, 2021, at 3:14 PM, Bakul Shah <bakul(a)iitbombay.org> wrote:
On Jul 31, 2021, at 3:13 PM, Larry McVoy <lm(a)mcvoy.com> wrote:
Forgot to add that whoever extends "program" should know not to create a new
option that uses a longer name breaking a full form old options.
On Sat, Jul 31, 2021 at 03:04:48PM -0700, Bakul Shah wrote:
That is easy to fix: use full options in scripts. Abbreviations for
interactive use. Much better than --always-having-to-type-long-names.
>
> program --this-is-the-even-longer-option
>
> We wrote our own getopt() for BitKeeper and it had long and short options
> but no gotcha unique prefix. On Jul 31, 2021, at 12:20 PM, Jon Steinhart
<jon(a)fourwinds.com> wrote:
That last one is a gotcha waiting to happen:
program --this-is-the-long-option
is the same as
program --this
but that will break scripts (and fingers) when program gets a new
option like
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.