exit
não encerra o script quando o erro é chamado.
resultado
Error: Could not resolve localhost
after exit
roteiro
#!/bin/sh
resolve_ip (){
if [ -z "$1" ]; then
host="localhost"
ip=$(dig +short myip.opendns.com @resolver1.opendns.com)
else
host="$1"
ip=$(dig +short $1)
fi
if [ -z "$ip" ]; then
error "Could not resolve $host"
fi
echo "$ip"
}
error (){
(>&2 echo "Error: $1")
exit 1
}
master_host='google.com'
if [ "$(resolve_ip)" = "$(resolve_ip $master_host)" ]; then
error "some error"
fi
echo "after exit"
exit
exit
sai do processo shell atual¹.Em
$(resolve_ip)
,resolve_ip
está sendo executado em um processo de subshell.Você pode fazer:
Para o shell principal sair (com o mesmo código de saída do subshell) quando o subshell sair com um status de saída diferente de zero.
Além disso, como
resolve_ip
é executado em um ambiente de subshell, as variáveis$ip
e$host
não sobreviverão após o retorno desse subshell.Observe também que o
(...)
in(>&2 echo "Error: $1")
também inicia um subshell. Não é realmente necessário aqui, a menos que você queira cobrir o caso em que stderr é um pipe quebrado e escrever a mensagem de erro causaria uma entrega SIGPIPE para o processo shell principal comoecho
está embutido.Aqui, em vez de retornar a saída sobre stdout, você pode devolvê-la armazenando-a em variáveis fornecidas pelo usuário:
¹ Ambientes subshell estritamente falando não precisam ser implementados com processos filhos, e alguns shells gostam
ksh93
de não como uma otimização, mas aindaexit
assim apenas sai o subshell, não o shell principal.ksh93
no entanto, tem um${ ...; }
formulário ou substituição de comando que não envolve um ambiente de subshell, portanto,exit
sairia do shell principal.