[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Handling getopt for option without optional argument value

From: lisa-asket
Subject: Handling getopt for option without optional argument value
Date: Fri, 23 Jul 2021 18:55:50 +0200 (CEST)

From: Greg Wooledge <>
To: help-bash <>
Subject: Re: Handling getopt for option without optional argument value
Date: 23/07/2021 18:44:35 Europe/Paris

On Fri, Jul 23, 2021 at 06:32:00PM +0200, 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.

I only care about Gnu here, not other things

> whilst bash is the most widely used shell packaged

What does that have to do with anything?

It is basic so long option functionality is good to use when writing function

for people to use on the terminal.  Many things that can be done via command 

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

It is a recurrent problem of Gnu to be extremely resistant to change.  Forget

the history, because we want to do our work today, rather than telling us 

to go along with the restrictions of the past.  We want to do better things

than the folks of the past.  Their life is over, it is our turn now.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]