O 'getopts' é útil apenas quando todas as opções são fornecidas antecipadamente?

Question

Estou tentando ver se posso usar getopts para meu script Bash. No entanto, não tenho certeza do que está errado:

#! /bin/bash

while getopts "a:b" opt ; do
    case $opt in
        a)
            A_OPTION="option a was given argument $OPTARG"
            ;;
        b)
            B_OPTION="option b was found"
            ;;
    esac
done
if [ -n "$A_OPTION" ] ; then echo $A_OPTION ; fi
if [ -n "$B_OPTION" ] ; then echo $B_OPTION ; fi
shift $((OPTIND - 1))
echo "The remaining arguments are: $@"

A saída é:

$ ./getopts-test foo goo -a moo -b
The remaining arguments are: foo goo -a moo -b
$ ./getopts-test -a moo -b foo goo
option a was given argument moo
option b was found
The remaining arguments are: foo goo
$ ./getopts-test -a moo foo goo -b
option a was given argument moo
The remaining arguments are: foo goo -b
$ ./getopts-test -b foo goo -a moo
option b was found
The remaining arguments are: foo goo -a moo

Por que o script não detecta as opções em todos os casos? O getopts é útil apenas quando as opções são todas fornecidas antecipadamente e não misturadas com outros argumentos?

    

Answer 1

(isso é muito longo para ser um comentário e muito ruim para ser uma resposta)

getopt tenta detectar a opção de letra única com - (sinal de menos) e opção com argumento.

Ele pára quando não há opção (não mais) (não -b , não -a foo ). Não analisa a lista completa.

Então, a resposta para a segunda pergunta é sim.

Você pode desejar escrever um analisador getopt por conta própria e lidar com essa questão são -foo --bar arguements (por exemplo, um arquivo, uma string) ou uma opção.

por um longo tempo a tradição era colocar as opções primeiro, argumento depois, precisamente para que você soubesse quando a opção parasse, e se -foo fosse um nome de arquivo real.