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:57:45 Europe/Paris

On Fri, Jul 23, 2021 at 07:35:36PM +0200, lisa-asket@perso.be wrote:
> An Gnu has already implemented long options in programs before, how does it 
> seem such
> 
> insurmountable obstacle asking if people can use long options ?

Find a GNU program written in bash (or in sh) and see how they do it.
If you like how they do it, copy their parser and use it in your
project.



---

My argument is that if this has happened, it would be good functionality to have

available to everybody.  Could not the people at gcc help a little bit?  As I 
was saying,

I have been using getopt and can handle short and long options, something you 
do not approve.

You might not like linux but there is no need to trash them.  Hope one day the 
maintainer

of Gnu Bash will think about supporting long option as natural.  History always 
seems to get 

developers stuck because they do not want to mess with the design of their 
predecessors.

---  



If you don't like how they do it, find another way.

I believe you will find that the GNU project is quite big on portability,
and that they won't be using the Linux-only getopt program. Remember,
the GNU project started long before Linux existed, and one of its early
strategies was to write drop-in replacements for the Unix command set.
GNU programs therefore need to work on as many different flavors of Unix
as possible, with as few disruptions as possible.

If GNU had written a getopt program, it would certainly be compatible

with the Unix version.



I understand that but find it hard to see the stumbling block with long-options.

There could be advantages to have some capability on some systems, rather than

nothing at all.  Others can work on better portability later on.  There should 
be a mix

of school of thoughts, but that's just my opinion.