Re: Handling getopt for option without optional argument value

[Greg Wooledge]

On Fri, Jul 23, 2021 at 06:32:00PM +0200, lisa-asket@perso.be wrote:
> How is it that people avoid long options, they are good instruments to use.

Once your program has more than a dozen options, sure.  You start to
run out of unique letters.

That's why there is an example of a --long-option parser on the wiki.

> libc has the long option function,

Only in GNU/Linux.  If you want to write a program that uses GNU's
getopt(3), then write it in C, and recognize that it will only work
on GNU/Linux systems.

> whilst bash is the most widely used shell packaged

What does that have to do with anything?

> by default for most distributions, making the use of long options in bash 
> functions
> 
> extremely useful.

You seem to have a fundamental misunderstanding of how bash and Unix
work in general.

There are 40 (going on 45) years of history tied to everything.  A shell
script written in 1985 using the Bourne shell and getopt will still
probably work on today's Unix systems, unless the script uses a handful
of features that were dropped from the shell post-Bourne (like ^ being
a synonym for | ).

Or, "work", meaning it will have the same bugs today as it did back then.

Bash doesn't arbitrarily change how things work because it would be
"useful".  Not without carefully considering how the change would affect
existing programs.

Unix is the same way.  Commands like getopt(1) can't just be changed,
because doing so would break existing programs.