Handling getopt for option without optional argument value

[lisa-asket]

From: Greg Wooledge <greg@wooledge.org>
To: help-bash@gnu.org
Subject: Re: Handling getopt for option without optional argument value
Date: 23/07/2021 19:08:03 Europe/Paris

On Fri, Jul 23, 2021 at 07:00:01PM +0200, lisa-asket@perso.be wrote:
> An maintainer of bash, I want to suggest an improvement to the capability of 
> bash built-in
> 
> getopt

>I won't speak for Chet, and I won't read the rest of what you wrote
>here, but you've made a huge error.

>getopt is NOT a shell builtin. It's an external command.



True but it handles long options as well



>getopts (with the 's') is a shell builtin, standardized by POSIX, and
>implemented as part of bash in adherence with that standard.



Understood.



>If you'd like to propose an extension to bash's implementation of getopts
>which supports --long-options in some kind of backward compatible manner,
>go ahead. If you can design how it should work, without breaking existing
>scripts, and if you're willing to write a patch to implement it, it's
>possible that Chet might consider accepting it.



Either an extension or an additional function we can use if you want to trash 
getopt. 

An Gnu has already implemented long options in programs before, how does it 
seem such

insurmountable obstacle asking if people can use long options ?



--