Re: Handling getopt for option without optional argument value

[Greg Wooledge]

On Fri, Jul 23, 2021 at 05:17:01PM +0200, lisa-asket@perso.be wrote:
> Tho approach should be to fix getopt if there are problems with it, no?

No.  It's an ancient non-standard command.  It's a historic artifact.
There is no changing it (because doing so would break scripts).

Check out various man pages:

http://man.openbsd.org/getopt

  The getopt utility cannot handle option arguments containing whitespace;
  consider using the standard getopts shell built-in instead.


https://www.freebsd.org/cgi/man.cgi?getopt

  Arguments containing whitespace or embedded shell metacharacters gener-
  ally will not survive intact; this looks easy to fix but is not.
  People trying to fix getopt or the example in this manpage should
  check the his- tory of this file in FreeBSD.


https://docs.oracle.com/cd/E23823_01/html/816-5165/getopt-1.html#scrolltoc

  The getopts command supersedes getopt. For more information, see
  NOTES below.

  getopt will not be supported in the next major release. For this
  release a conversion tool has been provided, namely, getoptcvt. For
  more information, see getopts(1) and getoptcvt(1).

  getopt does not support the part of Rule 8 of the command syntax
  standard (see Intro(1)) that permits groups of option-arguments
  following an option to be separated by white space and quoted. [...] To
  correct this deficiency, use the getopts command in place of getopt.


The getopts (note the 's') builtin command replaces getopt, and is not
broken.  Use that instead.  Or, if you need to handle --gnu-long-opts
or -findopts, write your own option parser.  Or don't write the program
in bash in the first place.  Or STOP FEELING THAT YOU NEED --gnu-long-opts
or -findopts in your program.  Just... don't do it.

People make their own lives SO much more complicated than they need to be.
I don't understand why.