&2 ; exit 1 ; fi # Note the quotes around `$ TEMP': they are essential! eval set -- "$TEMP" while true ; do case "$1" in -a|--a- long) echo "Option a" ; shift ;; -b|--b-long) echo "Option b. It takes a numeric value and getopt 's -n switch confused the hell out of me: does it belong to the stack-size: option definition ("takes numeric value?") OR; is it something else? Upon investigating, it seems to be just a switch to ´getopt´, so IMO this would have been clearer: getopt -n 'parse-options' -o vhns: -long verbose."> &2 ; exit 1 ; fi # Note the quotes around `$ TEMP': they are essential! eval set -- "$TEMP" while true ; do case "$1" in -a|--a- long) echo "Option a" ; shift ;; -b|--b-long) echo "Option b.">

Bash Getopts Optional Argument Example Essay

When you want to parse command line arguments in a professional way, is the tool of choice. Unlike its older brother (note the missing s!), it's a shell builtin command. The advantages are:

  • No need to pass the positional parameters through to an external program.

  • Being a builtin, can set shell variables to use for parsing (impossible for an external process!)

  • There's no need to argue with several implementations which had buggy concepts in the past (whitespace, …)

  • is defined in POSIX®.

Some other methods to parse positional parameters (without ) are described in: How to handle positional parameters.

Note that is not able to parse GNU-style long options () or XF86-style long options ()!

Terminology

It's useful to know what we're talking about here, so let's see… Consider the following command line:

mybackup -x -f /etc/mybackup.conf -r ./foo.txt ./bar.txt

These are all positional parameters, but they can be divided into several logical groups:

  • is an option (aka flag or switch). It consists of a dash () followed by one character.

  • is also an option, but this option has an associated option argument (an argument to the option ): . The option argument is usually the argument following the option itself, but that isn't mandatory. Joining the option and option argument into a single argument is valid.

  • depends on the configuration. In this example, doesn't take arguments so it's a standalone option like .

  • and are remaining arguments without any associated options. These are often used as mass-arguments. For example, the filenames specified for , or arguments that don't need an option to be recognized because of the intended behavior of the program. POSIX® calls them operands.

To give you an idea about why is useful, The above command line is equivalent to:

mybackup -xrf /etc/mybackup.conf ./foo.txt ./bar.txt

which is complex to parse without the help of .

The option flags can be upper- and lowercase characters, or digits. It may recognize other characters, but that's not recommended (usability and maybe problems with special characters).

How it works

In general you need to call several times. Each time it will use the next positional parameter and a possible argument, if parsable, and provide it to you. will not change the set of positional parameters. If you want to shift them, it must be done manually:

shift $((OPTIND-1)) # now do something with $@

Since sets an exit status of FALSE when there's nothing left to parse, it's easy to use in a while-loop:

while getopts ...; do ... done

will parse options and their possible arguments. It will stop parsing on the first non-option argument (a string that doesn't begin with a hyphen () that isn't an argument for any option in front of it). It will also stop parsing when it sees the (double-hyphen), which means end of options.

Used variables

variabledescription
OPTINDHolds the index to the next argument to be processed. This is how "remembers" its own status between invocations. Also useful to shift the positional parameters after processing with . is initially set to 1, and needs to be re-set to 1 if you want to parse anything again with getopts
OPTARGThis variable is set to any argument for an option found by . It also contains the option flag of an unknown option.
OPTERR(Values 0 or 1) Indicates if Bash should display error messages generated by the builtin. The value is initialized to 1 on every shell startup - so be sure to always set it to 0 if you don't want to see annoying messages! is not specified by POSIX for the builtin utility — only for the C function in (). is bash-specific and not supported by shells such as ksh93, mksh, zsh, or dash.

also uses these variables for error reporting (they're set to value-combinations which arent possible in normal operation).

Specify what you want

The base-syntax for is:

getopts OPTSTRING VARNAME [ARGS...] where:
tells which options to expect and where to expect arguments (see below)
tells which shell-variable to use for option reporting
tells to parse these optional words instead of the positional parameters

The option-string

The option-string tells which options to expect and which of them must have an argument. The syntax is very simple — every option character is simply named as is, this example-string would tell to look for , and :

getopts fAx VARNAME

When you want to expect an argument for an option, just place a (colon) after the proper option flag. If you want to expect an argument (i.e. to become ) just do:

getopts fA:x VARNAME

If the very first character of the option-string is a (colon), which would normally be nonsense because there's no option letter preceding it, switches to "silent error reporting mode". In productive scripts, this is usually what you want because it allows you to handle errors yourself without being disturbed by annoying messages.

Custom arguments to parse

The utility parses the positional parameters of the current shell or function by default (which means it parses ).

You can give your own set of arguments to the utility to parse. Whenever additional arguments are given after the parameter, doesn't try to parse the positional parameters, but these given words.

This way, you are able to parse any option set you like, here for example from an array:

while getopts :f:h opt "${MY_OWN_SET[@]}"; do ... done

A call to without these additional arguments is equivalent to explicitly calling it with :

getopts ... "$@"

Error Reporting

Regarding error-reporting, there are two modes can run in:

For productive scripts I recommend to use the silent mode, since everything looks more professional, when you don't see annoying standard messages. Also it's easier to handle, since the failure cases are indicated in an easier way.

Verbose Mode

Silent Mode

A first example

Enough said - action!

Let's play with a very simple case: only one option () expected, without any arguments. Also we disable the verbose error handling by preceding the whole option string with a colon ():

#!/bin/bash   whilegetopts":a" opt; docase$optin a)echo"-a was triggered!">&2;; \?)echo"Invalid option: -$OPTARG">&2;;esacdone

I put that into a file named , which is the name you'll see below in the examples.

Let's do some tests:

Calling it without any arguments

$ ./go_test.sh $ Nothing happened? Right. didn't see any valid or invalid options (letters preceded by a dash), so it wasn't triggered.

Calling it with non-option arguments

$ ./go_test.sh /etc/passwd $ Again — nothing happened. The very same case: didn't see any valid or invalid options (letters preceded by a dash), so it wasn't triggered.

The arguments given to your script are of course accessible as - .

Calling it with option-arguments

Now let's trigger : Provide options.

First, an invalid one:

$ ./go_test.sh -b Invalid option: -b $ As expected, didn't accept this option and acted like told above: It placed into and the invalid option character () into . With our statement, we were able to detect this.

Now, a valid one ():

$ ./go_test.sh -a -a was triggered! $ You see, the detection works perfectly. The was put into the variable for our case statement.

Of course it's possible to mix valid and invalid options when calling:

$ ./go_test.sh -a -x -b -c -a was triggered! Invalid option: -x Invalid option: -b Invalid option: -c $

Finally, it's of course possible, to give our option multiple times:

$ ./go_test.sh -a -a -a -a -a was triggered! -a was triggered! -a was triggered! -a was triggered! $

The last examples lead us to some points you may consider:

  • invalid options don't stop the processing: If you want to stop the script, you have to do it yourself ( in the right place)

  • multiple identical options are possible: If you want to disallow these, you have to check manually (e.g. by setting a variable or so)

An option with argument

Let's extend our example from above. Just a little bit:

  • now takes an argument

  • on an error, the parsing exits with

#!/bin/bash   whilegetopts":a:" opt; docase$optin a)echo"-a was triggered, Parameter: $OPTARG">&2;; \?)echo"Invalid option: -$OPTARG">&2exit1;; :)echo"Option -$OPTARG requires an argument.">&2exit1;;esacdone

Let's do the very same tests we did in the last example:

Calling it without any arguments

$ ./go_test.sh $

As above, nothing happened. It wasn't triggered.

Calling it with non-option arguments

$ ./go_test.sh /etc/passwd $

The very same case: It wasn't triggered.

Calling it with option-arguments

Invalid option:

$ ./go_test.sh -b Invalid option: -b $

As expected, as above, didn't accept this option and acted like programmed.

Valid option, but without the mandatory argument:

$ ./go_test.sh -a Option -a requires an argument. $

The option was okay, but there is an argument missing.

Let's provide the argument:

$ ./go_test.sh -a /etc/passwd -a was triggered, Parameter: /etc/passwd $
invalid option is set to (question-mark) and is unset
required argument not found is set to (question-mark), is unset and an error message is printed
invalid option is set to (question-mark) and is set to the (invalid) option character
required argument not found is set to (colon) and contains the option-character in question

Today i was writing a bash script that should manage some input arguments, and so i studied , this is a convenient and elegant way to manage input parameters in a bash script. With it you can define switch (present or not) or parameters with an option, thus making your simple bash script much more professional.

Let’s see how to use this command and its options.

Please note that on Linux there are two different ways of parsing command line arguments. There is an utility called (man 1 getopt). This utility is available in all shells. Then in bash, there is another built-in tool for parsing arguments called (it’s a built-in, so it doesn’t have it’s own man-page — try help getopts). In this article I’ll talk of the first one, after some problems with script not working in dash i prefer to use external small programs rather than bash built-in commands.




In Debian and Ubuntu the command is contained in the package util-linux that is automatically installed, i expect that also on other Linux distribution you find it without any need of installing additional packages.

Basic usage

In getopt the parameters are parsed from left to right. Each parameter is classified as a short option, a long option, an argument to an option, or a non-option parameter.

A simple short option is a `-‘ followed by a short option character. If the option has a required argument, it may be written directly after the option character or as the next parameter (ie. separated by whitespace on the command line). If the option has an optional argument, it must be written directly after the option character if present.

It is possible to specify several short options after one `-‘, as long as all (except possibly the last) do not have required or optional arguments.

A long option normally begins with `–‘ followed by the long option name. If the option has a required argument, it may be written directly after the long option name, separated by `=’, or as the next argument (ie. separated by whitespace on the command line). If the option has an optional argument, it must be written directly after the long option name, separated by `=’, if present . Long options may be abbreviated, as long as the abbreviation is not ambiguous.

In my opinion the best way to present the command is with an example.

I want a script that can take the short option -h -1 -2 and -3 with an argument, like -3=Hello, and that can also manage the following long options –help, –one, –two and –three with an argument.

#!/bin/bash   # Execute getopt on the arguments passed to this program, identified by the special character [email protected]PARSED_OPTIONS=$(getopt-n"$0"-o h123: --long"help,one,two,three:"--"[email protected]")   #Bad arguments, something has gone wrong with the getopt command.if[$?-ne0]; thenexit1fi   # A little magic, necessary when using getopt.evalset--"$PARSED_OPTIONS"     # Now goes through all the options with a case and using shift to analyse 1 argument at a time.#$1 identifies the first argument, and when we use shift we discard the first argument, so $2 becomes $1 and goes again through the case.whiletrue; docase"$1"in   -h|--help)echo"usage $0 -h -1 -2 -3 or $0 --help --one --two --three"shift;;   -1|--one)echo"One"shift;;   -2|--two)echo"Dos"shift;;   -3|--three)echo"Tre"   # We need to take the option of the argument "three"if[-n"$2"]; thenecho"Argument: $2"fishift2;;   --)shiftbreak;;esacdone

#!/bin/bash # Execute getopt on the arguments passed to this program, identified by the special character [email protected] PARSED_OPTIONS=$(getopt -n "$0" -o h123: --long "help,one,two,three:" -- "[email protected]") #Bad arguments, something has gone wrong with the getopt command. if [ $? -ne 0 ]; then exit 1 fi # A little magic, necessary when using getopt. eval set -- "$PARSED_OPTIONS" # Now goes through all the options with a case and using shift to analyse 1 argument at a time. #$1 identifies the first argument, and when we use shift we discard the first argument, so $2 becomes $1 and goes again through the case. while true; do case "$1" in -h|--help) echo "usage $0 -h -1 -2 -3 or $0 --help --one --two --three" shift;; -1|--one) echo "One" shift;; -2|--two) echo "Dos" shift;; -3|--three) echo "Tre" # We need to take the option of the argument "three" if [ -n "$2" ]; then echo "Argument: $2" fi shift 2;; --) shift break;; esac done



The options we have used with in this example are:

-l, –longoptions (longopts)
The long (multi-character) options to be recognized. More than one option name may be specified at once, by separating the names with commas. This option may be given more than once, the longopts are cumulative. Each long option name in longopts may be followed by one colon to indicate it has a required argument, and by two colons to indicate it has an optional argument.

-o, –options (shortopts)
The short (one-character) options to be recognized. If this option is not found, the first parameter of getopt that does not start with a `-‘ (and is not an option argument) is used as the short options string. Each short option character in shortopts may be followed by one colon to indicate it has a required argument, and by two colons to indicate it has an optional argument.

Conclusions

if you look at the example you can see that is longer to describe how work than using it, you just need to define the short and long list of options and than manage them with a loop and a , and you’ll have a bash script that can smartly manage options.

Popular Posts:

Categories: 1

0 Replies to “Bash Getopts Optional Argument Example Essay”

Leave a comment

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *