Re: Handling getopt for option without optional argument value

[Chet Ramey]

On 7/23/21 1:43 PM, lisa-asket@perso.be 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
later.

> 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    chet@case.edu    http://tiswww.cwru.edu/~chet/