Double hyphen not handled correctly in some situations

[dodecatheon]

Try

_usage () { echo "usage" 1>&2; exit ${1:-0}; }
_die () { printf "\n$1\n" 1>&2; _usage ${2:-1}; }
while read args ; do
  OPTIND=1
  while getopts_long ":hvab: alpha bravo: charlie" OPT  $args ; do
    case "$OPT" in
      h|help   ) _usage          ;; # E.g., help option
      v|verbose) ((++verbose))   ;; # E.g., an incrementing option
      a|alpha  ) alpha=1         ;; # E.g., non-arg-requiring option
      b|bravo  ) bravo="$OPTARG" ;; # E.g., argument-requiring option
      charlie  ) charlie=1       ;; # E.g., long-option-only
      ':') _die "OPTION '${OPTARG}': MISSING ARGUMENT" 1;;
      '?') _die "UNKNOWN OPTION: '${OPTARG}'"          2;;
    esac
    echo "OPT=$OPT, OPTIND=$OPTIND, OPTARG=$OPTARG"
  done
done < <( cat <<EOF
-a-- param
EOF
)

and compare with the behavior of getopts. getopts is correctly able to stop parsing when the double-hyphen is grouped with the non-argument-requiring option, whether or not it is space separated, and whether or not '-:' is included in the shortopt spec.

[AndrewDDavis]

This is a strange edge case where it's not so clear what the correct behaviour is, IMO, but it does make sense to do the same as getopts.

[UrsaDK]

Thanks for reporting this guys! It took me a while, but I finally had a chance to look into it, and it turns out the issue isn’t just with "--" alone.

The root cause is that Bash’s built-in getopts supports adjacent variable-value syntax, like what you often see when compiling C: gcc -Llib -o example example.c -lmylib. Unfortunately, getopts_long can’t handle that properly.

The good news is the fix is fairly straightforward – #f263a9c – and will be available in getopts_long v1.2.3. 🙂