[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Handling getopt for option without optional argument value

From: Chet Ramey
Subject: Re: Handling getopt for option without optional argument value
Date: Fri, 23 Jul 2021 14:17:30 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0

On 7/23/21 1:43 PM, wrote:

 >There is a basic disconnect here. I'm not interested in the external
 >command `getopt'. I am asking about your ideas about how to change the
 >current builtin command `getopts' to satisfy your requirements in a
 >backwards-compatible way.

Look, this all started because people started giving me shit for using getopt.

I'm soliciting your suggestions about possible solutions that are worth the
implementation cost and preserve backwards compatibility. I'm after
something more than "look at GNU getopt."

All because getopts in supposed to be a replacement getopt, but stopped the work when it came to handle long options.

There are a couple of misconceptions here. First, while getopts was
intended to replace getopt, it was not intended to work in the same way.
Second, the historical version of getopt, the one that getopts was
developed to supersede, did not do anything with long options. That came

Now you tell everyone to write their own
and that we are in error chiding some big shot developer.

Please. Read what I wrote.

I am not in the wrong on this.

There is no being "in the right" or "in the wrong." There is an open
question about how to move forward.

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU

reply via email to

[Prev in Thread] Current Thread [Next in Thread]