Re: Handling getopt for option without optional argument value

[Greg Wooledge]

On Fri, Jul 23, 2021 at 07:07:40PM +0200, lisa-asket@perso.be wrote:
> 
> We complicate because we want the capability to do more things, some more 
> complicated than in the past.
> 
> Some of us have big aspirations. And some do not like the code to be so 
> cryptic (single letter options only),
> 
> even though it satisfied the older cohort thirty years ago. But really, long 
> options are not a new thing.
> 
> Resisting something which has become standard is not something that will 
> enhance our capabilities today
> 
> and for the future.

Again, there is an example of a long option parser on the wiki FAQ page
that I've already linked in this thread.  If you insist on doing this
in bash, you could use that as a starting point.  Or throw it away and
create your own option parser -- *many* projects do that.  The generic
option parsers (in a multitude of languages) never cover all possible
cases.

You, however, seem to be unwilling to write an option parser of your own,
and also unwilling to use the one on the FAQ, and also unwilling to listen
to any advice.  You insist that there *must* be some kind of already-rolled
option parser that will simply work for you and your "big aspirations",
and that the absence of such a creature is a galling bug.

Meanwhile you insult everyone who's been doing this longer than you have
(not so much in this message, but in previous messages), and insist that
maintaining backward compatibility is not a worthy goal.  I guess that
in your world, rewriting every script on the entire planet every few
years is no big deal, and everyone will just bend to that requirement
because it would make lisa-asket's life simpler.

Good luck in whatever you're doing, because you're going to need it.