Getopt And Getopts

^ click above ^

03.11.04

By A.P. Lawrence

Both "getopt" and getopts are tools to use for processing and validating shell script arguments. They are similar, but not identical. More confusingly, functionality may vary from place to place, so you need to read the man pages carefully if your usage is more than casual.

Properly handling command line arguments is difficult if you want the usage to be flexible. It's easy to write a script that demands arguments in a specific order; much harder to allow any order at all. It's also hard to allow bunched together arguments or spaced out to be equivalent:

These are the problems that getopt(s) are designed to handle. They ease the job considerably, but introduce their own little quirks that your script will need to deal with.

getopt

This is a standalone executable that has been around a long time. Older versions lack the ability to handle quoted arguments (foo a "this won't work" c) and the versions that can do so clumsily. If you are running a recent Linux version, your "getopt" can do that; SCO OSR5, Mac OS X 10.2.6 and FreeBSD 4.4 has an older version that does not.

The simple use of "getopt" is shown in this mini-script:

What we have said is that any of -a, -b, -c or -d will be allowed, but that -c is followed by an argument (the "c:" says that).

If we call this "g" and try it out:

We start with two arguments, and "getopt" breaks apart the options and puts each in its own argument. It also added "--".

Of course "getopt" doesn't care that we didn't use "-d"; if that were important, it would be up to your script to notice and complain. However, "getopt" will notice if we try to use a flag that wasn't specified:

However, if you preface the option string with a colon:

"getopt" will be silent about the unwanted flag.

As noted at the beginning, if we give "getopt" arguments containing spaces, it breaks:

Not only has "foo bar" become two arguments, but they have been separated. This will be true whether you have the newer version that is capable of handling those arguments or not, because it requires different syntax to handle them. If you do have the newer "getopt", you'd need to write the script differently:

We've added a "-o", changed $* to $@ in quotes, and used an "eval" for the set. With the newer (as is on Linux) version, that works:

However, if you use that script with the older getopt, you get a useless result:

It's unfortunately easy to get bad results from "getopt" by misquoting or using the wrong syntax. Whenever I've had to use this, I make sure to print out the arguments as I did in the "After getopt" while testing. Once you get it right, using it is easy:

and the results are as expected.

Read the Full Article

About the Author:
A.P. Lawrence provides SCO Unix and Linux consulting services http://www.pcunix.com

Read this newsletter at: http://www.perlpronews.com/2004/0311.html

Free Newsletters

Part of the iEntry Network
over 4 million subscribers

PerlProNews

WebProASP

NetworkNewz

Send me relevant info on products and services.

WebmasterFree Downloads

From the Forum:

Do you write your own scripts?

I have come across many webmasters who author their own scripts, and in some cases, charge for the development of the scripts to each customer. Personally, I see no reason why common applications need to be reinvented, or why customers need to pay more than is absolutely required.

I have used hundreds of scripts from 10's of different developers, sometimes customizing them, sometimes leaving them as is. Without these prewritten scripts, simple projects would take hours, or even days longer than necessary.

Realizing that scripts are a hot commodity among webmasters, we created a resource with several full site scripts and templates at ...

Go Here

-- PerlProNews is an iEntry, Inc. publication --
iEntry, Inc. 880 Corporate Drive, Lexington, KY 40503
2004 iEntry, Inc. All Rights Reserved Privacy Policy Legal

archives | advertising info | news headlines | free newsletters | comments/feedback | submit article