Entonces tengo un programa que puede tener o no un defecto de segmentación (./segf) que también escribe otros datos en stderr. Cuando el programa falla, su código de retorno es 139 (es decir, echo $?imprimirá 139).
Me gustaría redirigir stderr para /dev/nullevitar imprimirlo, sin embargo, al hacerlo ( ./segf 2>1) el código de retorno se establece en 1. Ahora es imposible diferenciar si el programa realmente tiene una segmentación o simplemente devuelve un error.
¿Es posible canalizar los otros errores de stderr y al mismo tiempo poder verificar que el código de retorno sea 139?
./segf >/dev/null; echo $?resultados en 139
./segf >/dev/null 2>1; echo $?resultados en 1
bash -c './segf'resultados en 139
bash -c './segf' 2>1resultados en 1
Respuesta1
Ninguna de las cosas que intentó debería afectar el estado de salida. Puedes probar con este script muy simple:
#!/bin/sh
echo out
echo err >&2
exit 139
Ahora ejecútelo con las distintas redirecciones:
$ 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
La forma de redirigir el stderr de un comando es simplemente command 2>/dev/null, pero eso nunca debería afectar el estado de salida del comando, a menos que falle la redirección. En realidad, esto es lo que probablemente sucedió en su caso. Si no tiene permisos de escritura en el directorio donde se encuentra e intentó ejecutar ./segf >/dev/null 2>1(en lugar de ./segf >/dev/null 2>&1), habría intentado crear unarchivollamado 1para redirigir stderr a. Si no se puede crear el archivo, obtendrá un estado de salida de 1:
$ foo.sh 2>1; echo $?
bash: 1: Permission denied
1