Possible to parse multiple long options?

[msabramo]

I have this code:

while getopts_long ':remoteHost: toDir:' OPTKEY; do
    case ${OPTKEY} in
        'remoteHost')
            REMOTE_HOST="${OPTARG}"
            ;;
        'toDir')
            TO_DIR="${OPTARG}"
            ;;
        '?')
            echo "INVALID OPTION -- ${OPTARG}" >&2
            exit 1
            ;;
        ':')
            echo "MISSING ARGUMENT for option -- ${OPTARG}" >&2
            exit 1
            ;;
        *)
            echo "UNIMPLEMENTED OPTION -- ${OPTKEY}" >&2
            exit 1
            ;;
    esac
done

and I'm invoking my script with arguments: --remoteHost=somehost --toDir=/tmp/foo

The result is:

INVALID OPTION -- remoteHost

The result is the same if I use as arguments: --remote-host somehost --to-dir /tmp/foo

How do I specify that both --remoteHost and --toDir are valid long options?

[msabramo]

Hmmm, it seems that it works as long as I have some short options also -- e.g.:

while getopts_long 'r:t: remoteHost: toDir:' OPTKEY; do

I guess the bug is that multiple long options don't work if you define no short options.

[billyzkid]

This works: while getopts_long ': remoteHost: toDir:' OPTKEY; do

[AndrewDDavis]

starting the optspec string with a space also works if you change the getopts call on line 20 to builtin getopts -- ....

[UrsaDK]

Using getopts_long without short options is an edge case I hadn’t really considered before. Most of my use includes at least "-h" (help), so I rarely run into this. That said, short options aren’t required, so this should be possible.

In “silent mode” (when OPTSPEC starts with :), if no short options are needed, just start OPTSPEC with : (that’s : followed by a space) and define long options as usual — exactly as @billyzkid pointed out.

We could introduce a special character for verbose mode as a counterpart to :, but personally, I’d be against it. Every new character exception we add diverges getopts_long further from the built-in getopts, increases cognitive load, and adds (minimal) risk of future collisions.

“Space” is the most logical choice — it’s standard ASCII, unlikely to conflict with options, and even if built-in getopts adopts it later, it would (hopefully) be to support the same feature. 🤞

So, for verbose mode without short options, just start OPTSPEC with a space.

PS: Thanks @AndrewDDavis for the idea and for catching that bug! I’ve added tests to prevent it happening in the future, and it’ll be included in getopts_long v1.2.3 once #21 is merged.