Counting Whitespace in Arguments in KSH?

The last item in your case statement should have a backslash instead of a slash. Let's make a couple of other changes for the sake of diagnostics so you can see what's happening.

#!/bin/kshwflag=falsecflag=false# the first colon means suppress error messages# the colon after the x means that -x requires an argumentwhile getopts ":cwx:" optdo    echo "opt $opt"    case "$opt" in        c)            cflag=true            ;;        w)            wflag=true            ;;        x)            echo "x is an option, $OPTARG is its argument"            ;;        \?)            echo "invalid option"            ;;        *)            echo "missing argument"            ;;    esacdoneecho "cflag $cflag"echo "wflag $wflag"

Now let's call it several ways:

$ ./script.ksh -copt [c]cflag truewflag false

Fine.

$ ./getoptstest.ksh -c -wopt [c]opt [w]cflag truewflag true

Also fine.

$ ./getoptstest.ksh -cwopt [c]opt [w]cflag truewflag true

Still fine, but our answer is foreshadowed.

$ ./getoptstest.ksh '-c -w'opt [c]opt [?]invalid optionopt [?]invalid optionopt [w]cflag truewflag true

Now we're getting somewhere. The Korn shell man page says:

A leading : in optstring causes getopts to store the letter of an invalid option in OPTARG, and to set vname to ? for an unknown option and to : when a required option argument is miss‐ ing. Otherwise, getopts prints an error message.

As you can see from the example before this last one, you can run the options together as in -cw. When you pass an option like '-c -w', getopts sees it as -c -space -- and -w. So, in addition to two invalid options (-- and -space) it sees both -c and -w and that's why both flags are getting set. Without the leading colon (which is the way the original script is posted in the question), you should be getting error messages like these:

./script.ksh: - : unknown option./script.ksh: --: unknown option

If you look closely, you'll notice the telltale space and extra dash.

It's unfortunate that the man page doesn't discuss the ability of getopts to process arguments passed separately or bunched together.

I'm not sure if I understand what or if there's a problem with your ksh program.ksh "what up" example.

Try my modified script with these options and arguments to see how the rest of it works.

./script.ksh -x./script.ksh -x foo./script.ksh -z./script.ksh -c bar -w

That last one is tricky. When an argument that doesn't begin with a dash is found and the preceding option doesn't take an argument, the getopts stops processing and the rest of the arguments are left in place. You can use shift $(($OPTIND - 1)) after the while loop and then you'll be able to access the remaining positional parameters in the usual way.

Unfortunately, the shell builtin getopts doesn't handle long options like --version. The external utility getopt does, but there can be some issues that have to be dealt with when it is used.