Re: Handling getopt for option without optional argument value

[Greg Wooledge]

> From: Chet Ramey <chet.ramey@case.edu>
> How would you propose adding the specification of these long options to the
> existing getopts argument syntax in a compatible way?

On Fri, Jul 23, 2021 at 07:23:16PM +0200, lisa-asket@perso.be wrote:
> Couldn't we get ideas from getopt

getopt and getopts do very different things.

The basic goal of getopt is to take the program's arguments and rewrite
them as a new list of arguments, with -xyz expanded to -x -y -z.  After
that, you process the options in a loop.

getopt is an external program, so it can't return an actual list of
arguments.  It can only write a string to standard output, and it relies
on the shell to parse that string back in as its new argument list.

This sounds simple, but the way it was done historically was flawed, in
an unfixable way.  It only works when there are no zero-length arguments,
and no arguments with whitespace in them.

The Linux people tried to "fix" this by writing an incompatible getopt
program.  It writes the new argument list in a *different* form compared
to the traditional Unix getopt.  That means it has to be *called*
differently by the script which uses it.  In other words, it has a
different API.

If you use the Linux getopt, your script will need to be changed, and
your script will also no longer work on any non-Linux systems.

It should be noted that the loop which you need to write to process the
options after getopt has done its work is going to look a *lot* like
the FAQ's example.  You're doing all of the remaining processing yourself.

getopts, on the other hand, works in conjunction with your option
processing loop.  It hands each option to you one at a time, with its
argument (if it has one) in a separate variable.  Your loop becomes
simpler.  But the issue that some people have with getopts is that it
does not handle -findopts or --gnu-opts.