getopt optional argument with optional value

[Khan Smith]

   Sent: Monday, October 11, 2021 at 2:12 AM
   From: "Dennis Williamson" <dennistwilliamson@gmail.com>
   To: "Khan Smith" <khansmith@mail.com>
   Cc: "help-bash" <help-bash@gnu.org>
   Subject: Re: getopt optional argument with optional value
   On Sun, Oct 10, 2021, 7:41 PM Khan Smith <khansmith@mail.com> wrote:
   > I am using getopt and want to have an option -l that takes an
   optional
   > value. I am finding that when matching -l by itself with no argument
   > value provided, I still have to use shift 2 rather than just one
   shift.
   > What is going on and how does this happen?
   > opts=$( getopt -o "$shortopts" -l "$longopts" -n "${0##*/}" -- "$@" )
   > eval "set -- ${opts}"
   > while (( $# > 0 )); do
   > case $1 in
   > ("-l")
   > case "$2" in
   > (+([[:digit:]]))
   > # matches -lNUM, optional argument value
   > nl="$2"; shift 2 ;;
   > (*)
   > # matches -l, no argument value provided
   > nl=1 ; shift ;;
   > esac
   > ;;
   > ("--") shift ; break ;;
   > (*) opt_error=1 ; break ;;
   > esac
   > done
   >
   Here we go again.
   getopt is not Bash. For help with getopt, try mailing lists or forums
   that
   are devoted to your operating system or distribution. Much advice you
   will
   see in various places says not to use getopt. Consider following that
   advice. getopt has implementations with bugs.
   Bash has a feature called getopts - note the s. It doesn't support long
   options. It works consistently though. It supports flags with arguments
   and
   flags without.
   As for "optional" options - how do you suppose that a flag followed by
   no
   option then another flag could be distinguished from a flag followed by
   an
   option that looks like a flag?

   It depends on good design of the function so that there are no
   ambiguities
   between values and flags.  If you are hacking in a way that tries to
   fool a
   system to think of a value as a flag, you are making the problem,
   rather than
   being a problem of the design.

   There exist many messed up things exist in gnu that we live with
   because
   of historical reasons that many developers do not want to get unstuck
   with.

   Not using something because of some weird thing you want fail it with
   is no
   excuse to stop using it.  It is called pragmatic programming.  And
   perhaps a
   lack of documentation on use and limitations.  Standardisation could be
   helpful,
   but as times move on, standards can become stifling, as has happened
   with
   some aspects of the posix standard.

   >

   Have seen that an option with optional value that is not used produces
   and empty
   argument field ''.

   opts=$( getopt -o "$shortopts" -l "$longopts" -n "${0##*/}" -- "$@" )

   printm -n35 -l "First-Line" "Second-Line" "Third-Line"
   opts:  -n '35' -l '' -- 'First-Line' 'Second-Line' 'Third-Line'
   printm -n35 -l1 "First-Line" "Second-Line" "Third-Line"
   opts:  -n '35' -l '1' -- 'First-Line' 'Second-Line' 'Third-Line'
   printm -n35 -l2 "First-Line" "Second-Line" "Third-Line"
   opts:  -n '35' -l '2' -- 'First-Line' 'Second-Line' 'Third-Line'