Handling getopt for option without optional argument value

[lisa-asket]

From: Chet Ramey <chet.ramey@case.edu>
To: lisa-asket@perso.be;
   help-bash@gnu.org
Subject: Re: Handling getopt for option without optional argument value
Date: 23/07/2021 19:27:01 Europe/Paris
Cc: chet.ramey@case.edu

On 7/23/21 1:23 PM, lisa-asket@perso.be wrote:

> How would you propose adding the specification of these long options to the
> existing getopts argument syntax in a compatible way?
> 
> Couldn't we get ideas from getopt and from gcc getopt.h ?

Presumably. Why not go ahead and suggest some?

> Handling long options has been done within gnu programs before, am I right 
> ? This is about
> introducing it for gnu bash.  Otherwise I will continue using getopt.  But 
> some are saying that
> getopt will not be supported in the next major release.  But this does not 
> bother certain other
> people of having others get their scripts broken.  What is the sense of not 
> allowing getopt
> when you don't provide a replacement !

>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.



All because getopts in supposed to be a replacement getopt, but stopped the work

when it came to handle long options.  Now you tell everyone to write their own 

and that we are in error chiding some big shot developer.   



I am not in the wrong on this.