Solución 1:
set -e hace que el shell se cierre si algún subcomando o tubería devuelve un estado distinto de cero.
La respuesta que probablemente estaba buscando el entrevistador es:
Sería peligroso usar "set -e" al crear scripts init.d:
De http://www.debian.org/doc/debian-policy/ch-opersys.html 9.3.2 --
Tenga cuidado al usar set -e en scripts init.d. Escribir scripts init.d correctos requiere aceptar varios estados de salida de error cuando los demonios ya se están ejecutando o ya se han detenido sin cancelar el script init.d, y las bibliotecas de funciones init.d comunes no son seguras para llamar con set -e en efecto. Para las secuencias de comandos init.d, a menudo es más fácil no usar set -e y, en su lugar, verificar el resultado de cada comando por separado.
Esta es una pregunta válida desde el punto de vista del entrevistador porque mide el conocimiento práctico de los candidatos sobre automatización y secuencias de comandos a nivel de servidor
Solución 2:
Desde bash(1) :
-e Exit immediately if a pipeline (which may consist of a
single simple command), a subshell command enclosed in
parentheses, or one of the commands executed as part of
a command list enclosed by braces (see SHELL GRAMMAR
above) exits with a non-zero status. The shell does not
exit if the command that fails is part of the command
list immediately following a while or until keyword,
part of the test following the if or elif reserved
words, part of any command executed in a && or ││ list
except the command following the final && or ││, any
command in a pipeline but the last, or if the command’s
return value is being inverted with !. A trap on ERR,
if set, is executed before the shell exits. This option
applies to the shell environment and each subshell envi-
ronment separately (see COMMAND EXECUTION ENVIRONMENT
above), and may cause subshells to exit before executing
all the commands in the subshell.
Desafortunadamente, no soy lo suficientemente creativo como para pensar por qué sería peligroso, aparte de "el resto del script no se ejecutará" o "tal vez podría enmascarar problemas reales".
Solución 3:
Cabe señalar que set -e se puede activar y desactivar para varias secciones de un guión. No tiene que estar activado para la ejecución de todo el script. Incluso podría habilitarse condicionalmente. Dicho esto, nunca lo uso ya que hago mi propio manejo de errores (o no).
some code
set -e # same as set -o errexit
more code # exit on non-zero status
set +e # same as set +o errexit
more code # no exit on non-zero status
También cabe destacar esto de la sección de la página de manual de Bash en el trap comando que también describe cómo set -e funciona bajo ciertas circunstancias.
La trampa ERR no se ejecuta si el comando fallido es parte de la lista de comandos inmediatamente después de un tiempo o hasta la palabra clave, parte de la prueba en una instrucción if, parte de un comando ejecutado en una lista &&o ⎪⎪, o si el valor de retorno del comando es siendo invertido a través de !. Estas son las mismas condiciones obedecidas por la opción errexit.
Entonces, hay algunas condiciones bajo las cuales un estado distinto de cero no provocará una salida.
Creo que el peligro está en no entender cuando set -e entra en juego y cuándo no y confiar en él incorrectamente bajo alguna suposición inválida.
Consulte también BashFAQ/105 ¿Por qué set -e (o set -o errexit, o trap ERR) no hace lo que esperaba?
Solución 4:
Tenga en cuenta que este es un cuestionario para una entrevista de trabajo. Las preguntas pueden haber sido escritas por el personal actual y pueden estar equivocadas. Esto no es necesariamente malo, y todo el mundo comete errores, y las preguntas de la entrevista a menudo quedan en un rincón oscuro sin revisión, y solo salen a la luz durante una entrevista.
Es muy posible que 'set -e' no haga nada que consideremos "peligroso". Pero el autor de esa pregunta puede creer erróneamente que 'set -e' es peligroso, debido a su propia ignorancia o parcialidad. Tal vez escribieron un script de shell con errores, bombardeó horriblemente y pensaron erróneamente que la culpa era de 'set -e', cuando en realidad se olvidaron de escribir una verificación de errores adecuada.
Participé en probablemente 40 entrevistas de trabajo en los últimos 2 años, y los entrevistadores a veces hacen preguntas incorrectas o tienen respuestas incorrectas.
O tal vez sea una pregunta capciosa, que sería tonta, pero no del todo inesperada.
O quizás esta sea una buena explicación:http://www.mail-archive.com/[email protected]/msg473314.html
Solución 5:
set -e le dice a bash, en un script, que salga siempre que algo devuelva un valor de retorno distinto de cero.
Pude ver cómo eso sería molesto y con errores, no estoy seguro de si es peligroso, a menos que haya abierto permisos en algo, y antes de que pueda restringirlos nuevamente, su secuencia de comandos murió.