Handling long options with getopts

Faki · 10-29-2021, 06:42 PM

I am parsing options with `getopts` but would like to handle long options as well.

Code:

mygetopts ()
{
 aggr=()
 for arg in "$@"; do
   case $arg in
    ("--context")  aggr+=( "-C" ) ;;
    (*)  aggr+=( "$arg" ) ;;
   esac
 done

 set -- "${aggr[@]}"
 
 local OPTIND OPTARG
 local shortopts="C:"
 while getopts "$shortopts" arg; do
   case $arg in
    ("C") context="$OPTARG" ;;
    (*) break ;; 
   esac
 done
}

But I wonder whether the use of set -- "${aggr[@]}" is correct.

Or is the following (using `eval`) more appropriate?

Code:

eval set -- "${aggr[@]}"

or

Code:

eval "set -- ${aggr[@]}"

pan64 · 10-30-2021, 03:53 AM

https://stackoverflow.com/questions/...ptions/7948533

boughtonp · 10-30-2021, 09:09 AM

Quote:

Originally Posted by Faki

But I wonder whether the use of set -- "${aggr[@]}" is correct.

Or is the following (using `eval`) more appropriate?

Code:

eval set -- "${aggr[@]}"

or

Code:

eval "set -- ${aggr[@]}"

1. Not sure how this is different to what you've asked already...

https://www.linuxquestions.org/questions/linux-desktop-74/alternative-to-eval-4175702722
https://www.linuxquestions.org/questions/linux-software-2/difference-between-%60eval-set-%24opts-%60-and-the-direct-call-%60set-%24opts-%60-4175702775

2. Use ShellCheck to check shell scripts.

The warnings/errors it raises provide your answer.

pan64 · 10-30-2021, 10:56 AM

Quote:

Originally Posted by boughtonp

1. Not sure how this is different to what you've asked already...

this eval set construct is completely pointless with arrays. That can only cause additional troubles
the goal of this eval set is to parse/split the string into an array.

GazL · 10-31-2021, 07:14 AM

Yeah, you can trick getopts into doing it with something like this:

Code:

while getopts ':a:b:v-:' opt
do
  case "$opt" in
    a)  of_a=1 ; oarg_a=$OPTARG  ;;
    b)  of_b=1 ; oarg_b=$OPTARG  ;;
    v)  of_v=1 ;;
    -)  case "$OPTARG" in
          long-opt) of_long_opt=1 ;;
        esac
        ;;
    \?) echo "Unexpected option: -$OPTARG" 
	exit 1 ;;
    :)  echo "Missing operand for option -$OPTARG" 
	exit 1 ;;
  esac
done

.. but it's very fragile and I wouldn't recommend it.

If you want long-options and portability is not a concern then stick with gnu getopt.

If portability is a concern then you'll most likely want to stick with the POSIX rules: short-options only, and no optional option arguments, in which case getopts is a good choice.

pan64 · 10-31-2021, 09:06 AM

you don't need getopt at all, you can simply write a while loop to process options. That is not that difficult:
https://stackoverflow.com/questions/...uments-in-bash

But obviously you can have different needs, in that case probably better use another language. bash is not really suitable to do fancy things like parsing complex argument structures.

GazL · 10-31-2021, 09:44 AM

Yes, it's pretty easy so long as you don't support POSIX option combining.

I have, in the past, as an exercise, written a bash script that does its own parsing and which supports combined option strings, but I wouldn't want to use that in something real, unless there was no other choice.

There's a reason why getopt/getops exist.