bash - Why cant I have a space between option and optional argument using getopt? -

bash - Why cant I have a space between option and optional argument using getopt? -

when using getopt parse commandline parameters can set space in between alternative flag , argument required arguments not optional arguments. optional arguments parsed if right after option.

temp=`getopt -o p:q:: -n 'mkqueue.sh' -- "$@"` if [ $? != 0 ] ; echo "terminating..." >&2 ; exit 1 ; fi # note quotes around `$temp': essential! eval set -- "$temp" # go through options while true ; case "$1" in -p) echo "option p, argument \`$2'" ; shift 2 ;; -q) case "$2" in "") echo "option q, no argument"; shift 2 ;; *) echo "option q, argument \`$2'" ; shift 2 ;; esac ;; --) shift ; break ;; *) echo "internal error!" ; exit 1 ;; esac done

(based on this: http://software.frodo.looijaard.name/getopt/docs/getopt-parse.bash)

when run script without optional argument works:

./mkqueue.sh -p adfsa -q alternative p, argument `adfsa' alternative q, no argument

if seek add together optional argument -q space in between doesnt work:

./mkqueue.sh -p adfsa -q sdfasdfa alternative p, argument `adfsa' alternative q, no argument

it works if don't have space in between alternative , argument, though required arguments work space:

./mkqueue.sh -p adfsa -qsdfasdfa alternative p, argument `adfsa' alternative q, argument `sdfasdfa'

is there prepare this?

that limitation documented in manpage getopt:

a simple short alternative `-' followed short alternative character. if alternative has required argument, may written straight after alternative character or next parameter (ie. separated whitespace on command line). if alternative has optional argument, must written straight after alternative character if present.

although getopt allows "optional alternative arguments", considered bad idea. posix utility syntax guidelines, example, include:

guideline 7: option-arguments should not optional.

the basic reason guideline convention argument command-line alternative may string whatsoever. might option, example. might literal string --, indicates end of alternative list. might empty string. anything.

the problem "optional alternative arguments" way know optional alternative argument not provided recognize next argument either alternative or --. means value of optional argument cannot start -.

alternatively, can take solution taken getopt command-line utility, require optional argument follow option, without intervening space (that is, beingness in same word). in case, optional argument cannot empty string.

rather creating complicated rules resolving these ambiguities, simple solution -- recommended posix (and, lot less authority, me) -- not allow alternative arguments optional. if there mutual value command-line alternative , want simplify life of user not requiring typed, implement 2 different command-line options, 1 of takes argument , other of doesn't. mutual techniques include using lower-case character version without argument, , corresponding upper-case character version argument, or using long alternative (--option) version.

for prefer dense , packed explanation, posix rationale explains that:

guideline 7 allows string option-argument; option-argument can begin character, can - or --, , can empty string. example, commands pr -h -, pr -h --, pr -h -d, pr -h +2, , pr -h '' contain option-arguments -, --, -d, +2, , empty string, respectively. conversely, command pr -h -- -d treats -d option, not argument, because -- option-argument here, not delimiter.

bash getopt