Re: [TUHS] Systematic approach to command-line interfaces [ meta issues ]

[Bakul Shah <bakul@iitbombay.org>]

On Jul 31, 2021, at 3:14 PM, Bakul Shah <bakul@iitbombay.org> wrote:
> 
> On Jul 31, 2021, at 3:13 PM, Larry McVoy <lm@mcvoy.com> wrote:
>> 
>> On Sat, Jul 31, 2021 at 03:04:48PM -0700, Bakul Shah wrote:
>>> On Jul 31, 2021, at 12:20 PM, Jon Steinhart <jon@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.
>> 
>> 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
> 
> 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.

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.