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.