Início / unix / Perguntas / 785754
Accepted
EndlosSchleife
Asked: 2024-10-28 21:54:33 +0800 CST

seguro se: tratar apenas o status de saída 1 como falso, outros diferentes de zero como erro

  • 772

No bash if, todos os status de saída diferentes de zero são tratados como falsos. Mas frequentemente (como por exemplo em grep -q), 1 é o único status que realmente significa falso, outros indicam erros.

Posso pensar nas seguintes alternativas à planície if "${cmd[@]}"; then echo yes; else echo no; fi:

Simplescase

#!/usr/bin/env bash
set -o errexit -o pipefail
cmd=(bash -c 'exit 10')

st=0; "${cmd[@]}" || st=$?
case $st in
    (0) echo yes;;
    (1) echo no;;
    (*) exit $st;;
esac

Verifique se há 0 ou 1

#!/usr/bin/env bash
set -o errexit -o pipefail
cmd=(bash -c 'exit 10')

st=0; "${cmd[@]}" || st=$?
[ $st -eq 0 -o $st -eq 1 ]
if [ $st -eq 0 ]; then
    echo yes
else
    echo no
fi

Função auxiliar para mapear status para saída

#!/usr/bin/env bash
set -o errexit -o pipefail

# Put this somewhere for reuse:
map-status() {
    local st=0
    "$@" || st=$?
    case $st in
        (0) echo t;;
        (1) echo f;;
        (*) return $st;;
    esac
}

cmd=(bash -c 'exit 10')

st=$(map-status "${cmd[@]}") && if [ $st = t ]; then
    echo yes
else
    echo no
fi

Questões

  1. Todos eles têm o problema de serem necessários ||após o comando check, então errexit não está ativo no comando check. (Dependendo do comando, isso pode ser corrigido com um subshell com essa opção; mas um subshell não funciona quando o comando deve definir uma variável para uso posterior.) Como isso pode ser corrigido?

  2. Existem outras maneiras concisas de escrever um careful if? Alguma delas talvez seja considerada a maneira idiomática?

As soluções devem funcionar com as opções errexit e pipefail habilitadas.

bash

3 respostas

  1. Best Answer

    Você só precisa testar de alguma forma especial se o status de saída de grepfor diferente de zero, o que eu faço aqui no elifbranch da ifdeclaração. A expansão ${status=$?}expande para o valor de $? e define o valor de statuspara o que $?for. Isso torna statusdisponível tanto para o elifbranch quanto para o elsebranch, você gostaria de usá-lo para algo.

    #!/bin/sh

unset -v status

if grep -q Hello file; then
        echo pattern matched
elif [ "${status=$?}" -eq 1 ]; then
        echo pattern did not match
else
        printf 'error (status %d)\n' "$status"
fi

    Ou, se você não quiser exibir ou usar o valor retornado de grep:

    #!/bin/sh

if grep -q Hello file; then
        echo pattern matched
elif [ "$?" -eq 1 ]; then
        echo pattern did not match
else
        echo some kind of error
fi

    O código acima funcionaria da mesma forma, independentemente de você executá-lo com bashe habilitar a configuração pipefailou a errexitconfiguração, já que o comando é executado como parte da ifdeclaração. Em geral, use apenas errexitcom moderação, quando você tem uma série de comandos e não quer colocar || exitatrás de cada um deles (então desabilite a configuração novamente). Veja também o Bash FAQ de Greg Wooledge sobre isso.

    Se essa é a maneira "idiomática" de fazer isso, eu não sei. As pessoas geralmente não fazem diferença entre os status de saída não nulos de grep. No entanto, isso pode ser porque a diferença entre grepdar erro e grepnão corresponder a um padrão em um arquivo pode não importar para a maioria dos scripts.

    • 7

  2. Acho que você poderia fazer algo assim:

    #!/bin/bash
careful() {
    "$@"
    local ret=$?
    if [ "$ret" -ge 2 ]; then
         printf >&2 "command '%s' returned error status %d, exiting...\n" "$*" "$ret"
         exit "$ret"
    fi
    return "$ret"
}

if careful grep -e '***' file; then
    echo match
else
    echo no match 
fi

    onde a função verifica explicitamente o status de retorno do comando fornecido antes de retornar.

    Isso também funcionaria em outros contextos careful whatever || ..., mas não detectaria, por exemplo, erros de redirecionamento que acontecem antes da função ser chamada, mas acho que eles são definidos $?como 1 de qualquer maneira (nos shells que tentei, incluindo Bash e zsh).

    • 4

  3. A abordagem que costumo usar em meus scripts quando quero fazer algo assim é:

    safe_run() {
    case "$-" in
        *e*) set +e; _reset_e=1 ;;
        *) _reset_e='' ;;
    esac

    "$@"

    _safe_run_rc=$?

    [ -n "${_reset_e}" ] && set -e

    return 0
}

safe_run cmd

case "${_safe_run_rc}" in
    0) echo "SUCCESS" ;;
    1) echo "FAILURE" ;;
    *) echo "UNKNOWN" ;;
esac

    Essa abordagem é compatível com POSIX, o que significa que funciona EM TODO LUGAR (mesmo em todas as shimplementações do busybox notoriamente problemáticas) e também não se importa se o script em que está sendo executado define o errfailsinalizador ou não. A safe_runfunção encapsula o comando a ser executado de forma que, se set -o errfailestiver habilitado, ele será desabilitado apenas o tempo suficiente para executar o comando encapsulado e salvar o código de retorno e, em seguida, reabilitado, preservando ainda a saída e o código de retorno.

    Eu também prefiro pessoalmente uma declaração de caso para esse tipo de coisa, pois é mais concisa do que uma ifdeclaração e não exige salvar o código de saída ou depender de semântica que muitas pessoas desconhecem (embora seja provável que muitas pessoas não saibam o que $-é, eu diria que a maioria das pessoas será capaz de inferir facilmente a partir do contexto o que é, enquanto o mesmo não é verdade para o tratamento de $?conforme aplicado a condições em ifdeclarações).

    Dito isso, isso não é algo que acontece com muita frequência na minha experiência, a menos que você esteja lidando com um script que encapsula algum outro comando para fornecer uma interface mais útil para ele ou esteja invocando uma função ou comando que você mesmo escreveu e que usa o código de retorno para comunicar mais do que um simples status de aprovação/reprovação.

    • 1

relate perguntas