Shell Programming and Scripting

If you look at the usage statements this script prints:

Code:

echo "USAGE: cluster_on_lev3.csh -dir <full_path Lev3 gfeat cope directory> [options]"
echo "USAGE: cluster_on_lev3.csh -dir <full_path Lev3 gfeat cope directory> -t <value> -p <value> -c <value> -l <value> -h <value>"

you might notice that this script requires its options and option arguments to be presented as separate arguments. When a command line is presented as expected, flag will be set to an option introducer -dir, -t, -p, etc. The shift then removes the option introducer from the list of remaining arguments and $argv[1] refers to the option-argument corresponding to that option introducer. The switch statement then sets a variable corresponding to the given option introducer to the value of the option-argument (which is then also shifted off of the remaining list of unprocessed arguments).

Note that each case can do a shift in addition to the shift after picking up the option introducer because every option in this script requires an option-argument.

The command:

Code:

echo "Incorrect use of argument: $flag"

is only printed when an option introducer is found on the command line that does not match an expected option.

Until now i used either arrays to parse the args (compare item with string '-h') and do action (or set variable) of array(+1), skipping i and i+1 after or even worse (but most used - lazy) hard coded argument positions....

eg - pseudo code - tired:

Code:

i=0
ARGS=($@)
for cur in $(seq 0 1 $#@);do
   ((i++))
   case "${ARGS[$cur]}" in
   "-h") echo "help" ;;
   "-o") echo other
         otherValue=${ARGS[$i]}
         unset ARGS[$i] ARGS[$cur] ;;
   *) echo "no args, or unhandled) ;;
    esac
done

This switch method kind of sounds faster.

Did i understand this properly (simplified?):
We're switching the flag, which is the actual argument trigger/toggle/(lost in translation), while argv[1] is the actual current value to be set as variable?

I was merely trying to explain what this csh script was doing.

I do not approve of this method of parsing command line options and option-arguments.

When using standards conforming shells (such as ksh and bash), you can use the getopts shell built-in so any shell script can parse options just like standards-conforming utilities are required to do. For instance, if a utility has a -h option (which does not take an option-argument) and a -f option (which takes a filename as an option-argument), a shell script should be able to recognize any of the following as equivalent ways to specify both options and to recognize that -x is an operand (not an option):

Code:

scriptname -h -f file -- -x
scriptname -f file -h -- -x
scriptname -h -ffile -- -x
scriptname -ffile -h -- -x
scriptname -hf file -- -x
scriptname -hffile -- -x

You can write a shell script (bash, csh, ksh, etc.) to do this type of command line argument processing without using getopts, but few programmers make it work with the same look and feel as that provided by standard utilities. Why reinvent the wheel or limit the way in which your script recognizes command line options when getopts can be used to make your script handle command line options the same way almost all of the standard UNIX utilities handle command line options?

For an example using the getopts shell built-in, check out the EXAMPLES section of the getopts(1) man page.