Uma matriz bash pode ser usada no lugar de eval set - “$ params”?

1

Estou dando uma olhada na biblioteca optparse para a análise da opção bash , especificamente este bit no código gerado:

params=""
while [ $# -ne 0 ]; do
  param="$1"
  shift

  case "$param" in

    --my-long-flag)
      params="$params -m";;
    --another-flag)
      params="$params -a";;
    "-?"|--help)
      usage
      exit 0;;
    *)
      if [[ "$param" == --* ]]; then
        echo -e "Unrecognized long option: $param"
        usage
        exit 1
      fi
      params="$params \"$param\"";;  ##### THIS LINE
  esac
done

eval set -- "$params"  ##### AND THIS LINE

# then a typical while getopts loop

Haveria algum motivo real para usar eval aqui? A entrada para eval parece ser devidamente higienizada. Mas não funcionaria da mesma maneira:

params=()
# ...
    --my-long-flag)
      params+=("-m");;
    --another-flag)
      params+=("-a");;
# ...
      params+=("$param");;
# ...
set -- "${params[@]}"

Isso parece mais limpo para mim.

Na verdade, isso não permitiria que as opções fossem analisadas diretamente da matriz params (mesmo sem usar set ) usando while getopts "ma" option "${params[@]}"; do em vez de while getopts "ma" option; do ?

    
por Wildcard 05.01.2016 / 21:21

1 resposta

4

A pergunta é " Deve uma matriz bash ser usada no lugar de eval set -" $ params "?", e a resposta é yes! .

No seu script, a entrada para eval é claramente não devidamente higienizada. Experimente

    yourscript ''xterm''

e você verá que um xterm é iniciado, mesmo que os backticks sejam citados corretamente por aspas simples. (Compare com

    echo ''xterm''

que não inicia um xterm.

Corrigir o erro enquanto mantém eval é muito difícil. Mesmo mudando a linha

    params="$params \"$param\"";;

para

    params="$params '$param'";;

não ajudaria: agora

    yourscript ''xterm''

não inicia mais um xterm, mas

    yourscript \'' 'xterm' '\'

ainda faz.

    
por 06.01.2016 / 00:21