Então eu tenho um programa que pode ou não falhar em segurança (./segf) que também grava outros dados em stderr. Quando o programa falha em segmentação, seu código de retorno é 139 (ou seja, echo $?irá imprimir 139).
Eu gostaria de redirecionar stderr para /dev/nullevitar imprimi-lo, mas fazer isso ( ./segf 2>1) faz com que o código de retorno seja definido como 1. Agora é impossível diferenciar se o programa está realmente com falha de segmentação ou apenas retornando um erro.
É possível canalizar outros erros do stderr e ainda verificar se o código de retorno seria 139?
./segf >/dev/null; echo $?resulta em 139
./segf >/dev/null 2>1; echo $?resulta em 1
bash -c './segf'resulta em 139
bash -c './segf' 2>1resulta em 1
Responder1
Nenhuma das coisas que você tentou deve afetar o status de saída. Você pode testar com este script bem simples:
#!/bin/sh
echo out
echo err >&2
exit 139
Agora execute-o com os vários redirecionamentos:
$ foo.sh; echo $?
out
err
139
#redirect stdout to /dev/null and stderr to a file called '1'
$ foo.sh >/dev/null 2>1; echo $?
139
## Redirect stderr to /dev/null
$ foo.sh 2>/dev/null; echo $?
out
139
A maneira de redirecionar o stderr de um comando é justa command 2>/dev/null, mas isso nunca deve afetar o status de saída do comando, a menos que o redirecionamento falhe. Na verdade, foi isso que provavelmente aconteceu no seu caso. Se você não tem permissões de gravação no diretório onde está e tentou executar ./segf >/dev/null 2>1(em vez de ./segf >/dev/null 2>&1), isso teria tentado criar umarquivochamado 1para redirecionar stderr para. Se o arquivo não puder ser criado, você obterá um status de saída de 1:
$ foo.sh 2>1; echo $?
bash: 1: Permission denied
1