Differences between revisions 7 and 12 (spanning 5 versions)
Revision 7 as of 2016-03-07 17:39:10
Size: 9449
Editor: JarnoSuni
Comment: process-getopt is deprecated in favour of argp.sh
Revision 12 as of 2016-12-05 20:06:39
Size: 12408
Editor: 213-211-57-37
Comment: Added section heading for process-getopt + placed existing deprecation warning to the beginning of the section
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
This page is a split-off from [[BashFAQ/035|Bash FAQ 35]]. It holds all of the crazy nonstandard ideas that people have come up with to write option-parsing code. These ideas tend to be over-engineered, half-baked, inefficient, unreliable, unsafe, or downright insane, or any combination of the above. Use at your own risk.

If you find yourself writing a bash script which is so large that you think you need a third-party option-processing module, then you are [[BashWeaknesses|writing in the wrong language]].

<<TableOfContents>>
Line 2: Line 8:

-----

==== IMPORTANT NOTE BEFORE YOU READ ANY FURTHER AND TRY TO APPLY THIS TO YOUR SCRIPT ====

Suppose that you want to check for `--hello` and `--world` and for `-a`, `-b` and `-c`.
You pass this optspec to getopts: `:abc-:`, and then you check if $OPTARG is `hello` or `world`.

This will be parsed as correct: `./myscript -a --hello -b --world -c` but '''so will this''': `./myscript -ab-hello -c- world`

===== DO YOU REALLY WANT THAT? =====

Sure, you can work around this thing by doing triple backflips with $OPTIND, but please stop using this blindly and posting it on the internet where uninformed noobs will read it.

-----
Line 35: Line 57:
Line 94: Line 115:
With this version you can have long and short options side by side and you shouldn't need to modify the code from line 26 to 60. This solution can also handle multiple arguments for long options, just use ${OPTARG} or ${OPTARG[0]} for the first argument, ${OPTARG[1]} for the second argument, ${OPTARG[2]} for the third argument and so on. It has the same disadvantage of its predecessor in not being portable and specific to bash. Additionally, it breaks arguments with whitespace (line 49) for long options, when given using the syntax that does not include equal sign (=). With this version you can have long and short options side by side and you shouldn't need to modify the code from line 25 to 59. This solution can also handle multiple arguments for long options, just use ${OPTARG} or ${OPTARG[0]} for the first argument, ${OPTARG[1]} for the second argument, ${OPTARG[2]} for the third argument and so on. It has the same disadvantage of its predecessor in not being portable and specific to bash. Additionally, it breaks arguments with whitespace (line 48) for long options, when given using the syntax that does not include equal sign (=).
Line 140: Line 161:

=== process-getopt ===

{{{#!wiki caution
'''Deprecation warning'''

This utility is reported to be deprecated in favour of [[https://sourceforge.net/projects/argpsh/|argp.sh]] (reported by -JarnoSuni)
}}}
Line 182: Line 212:

'' process-getopt is deprecated in favour of [[https://sourceforge.net/projects/argpsh/|argp.sh]] -JarnoSuni ''
=== Argbash ===

[[https://github.com/matejak/argbash|Argbash]] is a simple-to-use yet feature-rich code generator that can either generate the parsing code for your script, tailor-made. The project features extensive [[http://argbash.readthedocs.io/en/stable/index.html|documentation]].

The sample project from above (script accepting a `-f|--file|--verbose|...`) would use the following template:

{{{#!highlight bash
#!/bin/bash

# ARG_OPTIONAL_SINGLE([file],[f],[input file])
# ARG_VERBOSE()
# ARG_POSITIONAL_DOUBLEDASH()
# ARG_LEFTOVERS([other args])
# ARGBASH_GO()

# [ <-- needed because of Argbash

if [ "$_arg_verbose" -gt 0 ]; then
 echo "Input file: $_arg_file"
 echo "Other args: ${_arg_leftovers[*]}"
fi

# ] <-- needed because of Argbash
}}}

Then, executing the result script as `./script.sh -f my-file --verbose -- one two three --file foo` would yield

{{{
    Input file: my-file
    other args: one two three --file foo
}}}

The project also features a [[http://argbash.readthedocs.io/en/stable/example.html#minimal-example|quickstart utility]] that can generate a minimal template for you like this:
`argbash-init --opt file --pos arg-positional | argbash - -o basic_script.sh && ./basic_script.sh -h`

{{{
<The general help message of my script>
Usage: ./basic_script.sh [--file <arg>] [-h|--help] <arg-positional>
 <arg-positional>: <arg-positional's help message goes here>
 --file: <file's help message goes here> (no default)
 -h,--help: Prints help
}}}

One can then just fine-tune the template and get a script with argument parsing capabilities with little effort.
Line 247: Line 319:

----
CategoryShell

This page is a split-off from Bash FAQ 35. It holds all of the crazy nonstandard ideas that people have come up with to write option-parsing code. These ideas tend to be over-engineered, half-baked, inefficient, unreliable, unsafe, or downright insane, or any combination of the above. Use at your own risk.

If you find yourself writing a bash script which is so large that you think you need a third-party option-processing module, then you are writing in the wrong language.

getopts long option trickery


IMPORTANT NOTE BEFORE YOU READ ANY FURTHER AND TRY TO APPLY THIS TO YOUR SCRIPT

Suppose that you want to check for --hello and --world and for -a, -b and -c. You pass this optspec to getopts: :abc-:, and then you check if $OPTARG is hello or world.

This will be parsed as correct: ./myscript -a --hello -b --world -c but so will this: ./myscript -ab-hello -c- world

DO YOU REALLY WANT THAT?

Sure, you can work around this thing by doing triple backflips with $OPTIND, but please stop using this blindly and posting it on the internet where uninformed noobs will read it.


Here is an example which claims to parse long options with getopts. The basic idea is quite simple: just put "-:" into the optstring. This trick requires a shell which permits the option-argument (i.e. the filename in "-f filename") to be concatenated to the option (as in "-ffilename") as POSIX requires. The POSIX standard says you should pass arguments to options as separate options (to avoid problems with empty arguments) but requires getopts to handle the case where the argument is stuck to the option in the same argument. However, POSIX leaves the behaviour unspecified when an option is not alpha-numerical, so POSIX does not guarantee this to work. However, it should work in all of bash, dash, yash, zsh and all implementations of ksh, the only exception reported so far being posh.

   1 #!/bin/bash
   2 # Uses bash extensions.  Not portable as written.
   3 
   4 usage() {
   5     echo "Usage:"
   6     echo " $0 [ --loglevel=<value> | --loglevel <value> | -l <value> ] [ --range <beginning> <end> ] [--] [non-option-argument]..."
   7     echo " $0 [ --help | -h ]"
   8     echo
   9     echo "Default loglevel is 0. Default range is 0 to 0"
  10 }
  11 
  12 # set defaults
  13 loglevel=0
  14 r1=0 # beginning of range
  15 r2=0 # end of range
  16 
  17 i=$(($# + 1)) # index of the first non-existing argument
  18 declare -A longoptspec
  19 # Use associative array to declare how many arguments a long option
  20 # expects. In this case we declare that loglevel expects/has one
  21 # argument and range has two. Long options that aren't listed in this
  22 # way will have zero arguments by default.
  23 longoptspec=( [loglevel]=1 [range]=2 )
  24 optspec=":l:h-:"
  25 while getopts "$optspec" opt; do
  26 while true; do
  27     case "${opt}" in
  28         -) #OPTARG is name-of-long-option or name-of-long-option=value
  29             if [[ ${OPTARG} =~ .*=.* ]] # with this --key=value format only one argument is possible
  30             then
  31                 opt=${OPTARG/=*/}
  32                 ((${#opt} <= 1)) && {
  33                     echo "Syntax error: Invalid long option '$opt'" >&2
  34                     exit 2
  35                 }
  36                 if (($((longoptspec[$opt])) != 1))
  37                 then
  38                     echo "Syntax error: Option '$opt' does not support this syntax." >&2
  39                     exit 2
  40                 fi
  41                 OPTARG=${OPTARG#*=}
  42             else #with this --key value1 value2 format multiple arguments are possible
  43                 opt="$OPTARG"
  44                 ((${#opt} <= 1)) && {
  45                     echo "Syntax error: Invalid long option '$opt'" >&2
  46                     exit 2
  47                 }
  48                 OPTARG=(${@:OPTIND:$((longoptspec[$opt]))})
  49                 ((OPTIND+=longoptspec[$opt]))
  50                 echo $OPTIND
  51                 ((OPTIND > i)) && {
  52                     echo "Syntax error: Not all required arguments for option '$opt' are given." >&2
  53                     exit 3
  54                 }
  55             fi
  56 
  57             continue #now that opt/OPTARG are set we can process them as
  58             # if getopts would've given us long options
  59             ;;
  60         l|loglevel)
  61             loglevel=$OPTARG
  62             ;;
  63         range)
  64             r1=${OPTARG[0]}
  65             r2=${OPTARG[1]}
  66             ;;
  67         h|help)
  68             usage
  69             exit 0
  70             ;;
  71         ?)
  72             echo "Syntax error: Unknown short option '$OPTARG'" >&2
  73             exit 2
  74             ;;
  75         *)
  76             echo "Syntax error: Unknown long option '$opt'" >&2
  77             exit 2
  78             ;;
  79     esac
  80 break; done
  81 done
  82 
  83 echo "Loglevel: $loglevel"
  84 echo "Range: $r1 to $r2"
  85 echo "First non-option-argument (if exists): ${!OPTIND-}"
  86 
  87 # End of file

With this version you can have long and short options side by side and you shouldn't need to modify the code from line 25 to 59. This solution can also handle multiple arguments for long options, just use ${OPTARG} or ${OPTARG[0]} for the first argument, ${OPTARG[1]} for the second argument, ${OPTARG[2]} for the third argument and so on. It has the same disadvantage of its predecessor in not being portable and specific to bash. Additionally, it breaks arguments with whitespace (line 48) for long options, when given using the syntax that does not include equal sign (=).

Silly repeated brute-force scanning

Another approach is to check options with if statements "on demand". A function like this one may be useful:

   1 #!/bin/bash
   2 
   3 HaveOpt ()
   4 {
   5     local needle=$1
   6     shift
   7 
   8     while [[ $1 == -* ]]
   9     do
  10         # By convention, "--" means end of options.
  11         case "$1" in
  12             --)      return 1 ;;
  13             $needle) return 0 ;;
  14         esac
  15 
  16         shift
  17     done
  18 
  19     return 1
  20 }
  21 
  22 HaveOpt --quick "$@" && echo "Option quick is set"
  23 
  24 # End of file

and it will work if script is run as:

  • YES: ./script --quick
  • YES: ./script -other --quick

but will stop on first argument with no "-" in front (or on --):

  • NO: ./script -bar foo --quick
  • NO: ./script -bar -- --quick

Of course, this approach (iterating over the argument list every time you want to check for one) is far less efficient than just iterating once and setting flag variables.

It also spreads the options throughout the program. The literal option --quick may appear a hundred lines down inside the main body of the program, nowhere near any other option name. This is a nightmare for maintenance.

Complex nonstandard add-on utilities

process-getopt

Deprecation warning

This utility is reported to be deprecated in favour of argp.sh (reported by -JarnoSuni)

bhepple suggests the use of process-getopt (GPL licensed) and offers this example code:

PROG=$(basename $0)
VERSION='1.2'
USAGE="A tiny example using process-getopt(1)"

# call process-getopt functions to define some options:
source process-getopt

SLOT=""
SLOT_func()   { [ "${1:-""}" ] && SLOT="yes"; }      # callback for SLOT option
add_opt SLOT "boolean option" s "" slot

TOKEN=""
TOKEN_func()  { [ "${1:-""}" ] && TOKEN="$2"; }      # callback for TOKEN option
add_opt TOKEN "this option takes a value" t n token number

add_std_opts     # define the standard options --help etc:

TEMP=$(call_getopt "$@") || exit 1
eval set -- "$TEMP" # just as with getopt(1)

# remove the options from the command line
process_opts "$@" || shift "$?"

echo "SLOT=$SLOT"
echo "TOKEN=$TOKEN"
echo "args=$@"

Here, all information about each option is defined in one place making for much easier authoring and maintenance. A lot of the dirty work is handled automatically and standards are obeyed as in getopt(1) - because it calls getopt for you.

  • Actually, what the author forgot to say was that it's actually using getopts semantics, rather than getopt. I ran this test:

     ~/process-getopt-1.6$ set -- one 'rm -rf /' 'foo;bar' "'"
     ~/process-getopt-1.6$ call_getopt "$@"
      -- 'rm -rf /' 'foo;bar' ''\'''
  • It appears to be intelligent enough to handle null options, whitespace-containing options, and single-quote-containing options in a manner that makes the eval not blow up in your face. But this is not an endorsement of the process-getopt software overall; I don't know it well enough. -GreyCat

It's written and tested on Linux where getopt(1) supports long options. For portability, it tests the local getopt(1) at runtime and if it finds an non-GNU one (ie one that does not return 4 for getopt --test) it only processes short options. It does not use the bash builtin getopts(1) command. -bhepple

Argbash

Argbash is a simple-to-use yet feature-rich code generator that can either generate the parsing code for your script, tailor-made. The project features extensive documentation.

The sample project from above (script accepting a -f|--file|--verbose|...) would use the following template:

   1 #!/bin/bash
   2 
   3 # ARG_OPTIONAL_SINGLE([file],[f],[input file])
   4 # ARG_VERBOSE()
   5 # ARG_POSITIONAL_DOUBLEDASH()
   6 # ARG_LEFTOVERS([other args])
   7 # ARGBASH_GO()
   8 
   9 # [ <-- needed because of Argbash
  10 
  11 if [ "$_arg_verbose" -gt 0 ]; then
  12         echo "Input file: $_arg_file"
  13         echo "Other args: ${_arg_leftovers[*]}"
  14 fi
  15 
  16 # ] <-- needed because of Argbash

Then, executing the result script as ./script.sh -f my-file --verbose -- one two three --file foo would yield

    Input file: my-file
    other args: one two three --file foo

The project also features a quickstart utility that can generate a minimal template for you like this: argbash-init --opt file --pos arg-positional | argbash - -o basic_script.sh && ./basic_script.sh -h

<The general help message of my script>
Usage: ./basic_script.sh [--file <arg>] [-h|--help] <arg-positional>
        <arg-positional>: <arg-positional's help message goes here>
        --file: <file's help message goes here> (no default)
        -h,--help: Prints help

One can then just fine-tune the template and get a script with argument parsing capabilities with little effort.

Rearranging arguments

If you want to mix flags and arguments here's a function to rearrange all options to place flags first. Use before doing your normal getopts parsing.

   1 arrange_opts() {
   2     local flags args optstr=$1
   3     shift
   4 
   5     while (($#)); do
   6         case $1 in
   7             --) args+=("$@")
   8                 break;
   9                 ;;
  10             -*) flags+=("$1")
  11                 if [[ $optstr == *"${1: -1}:"* ]]; then
  12                     flags+=("$2")
  13                     shift
  14                 fi
  15                 ;;
  16             * ) args+=("$1")
  17                 ;;
  18         esac
  19         shift
  20     done
  21     OPTARR=("${flags[@]}" "${args[@]}")
  22 }
  23 
  24 example() {
  25     local OPTIND OPTARR optstring=ab:cd
  26 
  27     printf 'before arrange:'
  28     printf '<%s>' "$@"
  29     echo
  30 
  31     arrange_opts "$optstring" "$@"
  32     set -- "${OPTARR[@]}"
  33 
  34     printf 'after  arrange:'
  35     printf '<%s>' "$@"
  36     printf \\n\\n
  37 
  38     printf flag:arg\\n
  39 
  40     OPTIND=1
  41     while getopts "$optstring" opt; do
  42         case $opt in
  43             a|c|d) printf        %s\\n "$opt"    ;;
  44             b    ) printf      b:%s\\n "$OPTARG" ;;
  45             \?   ) printf badopt:%s\\n "$OPTARG" ;;
  46             :    ) printf  noarg:%s\\n "$OPTARG" ;;
  47             *    ) printf    wtf:%s\\n "$opt"    ;;
  48         esac
  49     done
  50     shift $((OPTIND-1))
  51 
  52     printf \\nargs:
  53     printf '<%s>' "$@"
  54     echo
  55 }
  56 
  57 example -ad foo -b bar baz


CategoryShell

ComplexOptionParsing (last edited 2023-12-07 09:46:56 by emanuele6)