[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 <greg@wooledge.org>
To: help-bash <help-bash@gnu.org>
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, 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.
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
line.
> 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.
- Re: Handling getopt for option without optional argument value, (continued)
- Re: Handling getopt for option without optional argument value, Greg Wooledge, 2021/07/23
- Re: Handling getopt for option without optional argument value, Alex fxmbsw7 Ratchev, 2021/07/23
- Re: Handling getopt for option without optional argument value, Greg Wooledge, 2021/07/23
- Handling getopt for option without optional argument value, lisa-asket, 2021/07/23
- Re: Handling getopt for option without optional argument value, Dennis Williamson, 2021/07/23
- Handling getopt for option without optional argument value, lisa-asket, 2021/07/23
- Re: Handling getopt for option without optional argument value, Greg Wooledge, 2021/07/23
- Handling getopt for option without optional argument value,
lisa-asket <=
- Re: Handling getopt for option without optional argument value, Chet Ramey, 2021/07/23
- Handling getopt for option without optional argument value, lisa-asket, 2021/07/23
- Re: Handling getopt for option without optional argument value, Greg Wooledge, 2021/07/23
- Handling getopt for option without optional argument value, lisa-asket, 2021/07/23
Re: Handling getopt for option without optional argument value, Lawrence Velázquez, 2021/07/23
Handling getopt for option without optional argument value, lisa-asket, 2021/07/23