Solution 1 :
set -e provoque la fermeture du shell si une sous-commande ou un pipeline renvoie un statut différent de zéro.
La réponse que l'intervieweur cherchait probablement est :
Il serait dangereux d'utiliser "set -e" lors de la création de scripts init.d :
Depuis http://www.debian.org/doc/debian-policy/ch-opersys.html 9.3.2 --
Soyez prudent lorsque vous utilisez set -e dans les scripts init.d. L'écriture de scripts init.d corrects nécessite l'acceptation de divers états de sortie d'erreur lorsque les démons sont déjà en cours d'exécution ou déjà arrêtés sans abandonner le script init.d, et les bibliothèques de fonctions init.d courantes ne peuvent pas être appelées en toute sécurité avec set -e en vigueur. Pour les scripts init.d, il est souvent plus facile de ne pas utiliser set -e et de vérifier à la place le résultat de chaque commande séparément.
Il s'agit d'une question valable du point de vue de l'intervieweur, car elle évalue les connaissances pratiques des candidats en matière de scripts et d'automatisation au niveau du serveur
Solution 2 :
À partir du 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.
Malheureusement, je ne suis pas assez créatif pour penser à la raison pour laquelle ce serait dangereux, à part "le reste du script ne sera pas exécuté" ou "cela pourrait peut-être masquer de vrais problèmes".
Solution 3 :
A noter que set -e peut être activé et désactivé pour différentes sections d'un script. Il n'est pas nécessaire qu'il soit activé pendant toute l'exécution du script. Il pourrait même être conditionnellement activé. Cela dit, je ne m'en sers jamais puisque je fais moi-même la gestion des erreurs (ou pas).
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
Il convient également de noter ceci dans la section de la page de manuel Bash sur le trap commande qui décrit également comment set -e fonctionne dans certaines circonstances.
L'interruption ERR n'est pas exécutée si la commande qui a échoué fait partie de la liste de commandes suivant immédiatement un mot clé while ou until, une partie du test dans une instruction if, une partie d'une commande exécutée dans une liste &&ou ⎪⎪, ou si la valeur de retour de la commande est être inversé via !. Ce sont les mêmes conditions auxquelles obéit l'option errexit.
Il existe donc certaines conditions dans lesquelles un statut différent de zéro ne provoquera pas de sortie.
Je pense que le danger est de ne pas comprendre quand set -e entre en jeu et quand ce n'est pas le cas et s'y fier de manière incorrecte sous une hypothèse invalide.
Veuillez également consulter BashFAQ/105 Pourquoi set -e (ou set -o errexit, ou trap ERR) ne fait-il pas ce que j'attendais ?
Solution 4 :
Gardez à l'esprit qu'il s'agit d'un quiz pour un entretien d'embauche. Les questions peuvent avoir été écrites par le personnel actuel, et elles peuvent être erronées. Ce n'est pas nécessairement mauvais, et tout le monde fait des erreurs, et les questions d'entretien restent souvent dans un coin sombre sans examen, et ne sortent que lors d'un entretien.
Il est tout à fait possible que 'set -e' ne fasse rien que nous considérerions comme "dangereux". Mais l'auteur de cette question peut croire à tort que 'set -e' est dangereux, en raison de sa propre ignorance ou de ses préjugés. Peut-être qu'ils ont écrit un script shell buggé, il a horriblement bombardé, et ils ont pensé à tort que 'set -e' était à blâmer, alors qu'en fait ils ont négligé d'écrire une vérification d'erreur appropriée.
J'ai participé à probablement 40 entretiens d'embauche au cours des 2 dernières années, et les enquêteurs posent parfois des questions erronées ou ont des réponses erronées.
Ou peut-être s'agit-il d'une question piège, qui serait boiteuse, mais pas tout à fait inattendue.
Ou peut-être est-ce une bonne explication :http://www.mail-archive.com/[email protected]/msg473314.html
Solution 5 :
set -e indique à bash, dans un script, de quitter chaque fois que quelque chose renvoie une valeur de retour différente de zéro.
Je pouvais voir à quel point cela serait ennuyeux et bogué, pas sûr que ce soit dangereux, à moins que vous n'ayez ouvert des autorisations sur quelque chose, et avant que vous ne puissiez les restreindre à nouveau, votre script est mort.