Soluzione 1:
set -e fa uscire la shell se qualsiasi sottocomando o pipeline restituisce uno stato diverso da zero.
La risposta che l'intervistatore stava probabilmente cercando è:
Sarebbe pericoloso usare "set -e" durante la creazione di script init.d:
Da http://www.debian.org/doc/debian-policy/ch-opersys.html 9.3.2 --
Fai attenzione a usare set -e negli script init.d. La scrittura di script init.d corretti richiede l'accettazione di vari stati di uscita di errore quando i daemon sono già in esecuzione o sono già stati arrestati senza interrompere lo script init.d e le librerie di funzioni init.d comuni non sono sicure da chiamare con set -e attivo. Per gli script init.d, spesso è più semplice non utilizzare set -e e controllare invece il risultato di ciascun comando separatamente.
Questa è una domanda valida dal punto di vista di un intervistatore perché misura la conoscenza operativa di un candidato di scripting e automazione a livello di server
Soluzione 2:
Da 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.
Sfortunatamente non sono abbastanza creativo da pensare al motivo per cui sarebbe pericoloso, a parte "il resto della sceneggiatura non verrà eseguito" o "potrebbe forse mascherare problemi reali".
Soluzione 3:
Va notato che set -e può essere attivato e disattivato per varie sezioni di uno script. Non deve essere attivo per l'intera esecuzione dello script. Potrebbe anche essere abilitato in modo condizionale. Detto questo, non lo uso mai poiché mi occupo personalmente della gestione degli errori (o meno).
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
Degno di nota è anche questo dalla sezione della pagina man di Bash sul trap comando che descrive anche come set -e funzioni in determinate circostanze.
La trap ERR non viene eseguita se il comando non riuscito fa parte dell'elenco di comandi immediatamente successivo a una parola chiave while o until, parte del test in un'istruzione if, parte di un comando eseguito in un elenco &&o ⎪⎪ o se il valore di ritorno del comando è essere invertito tramite !. Queste sono le stesse condizioni cui obbedisce l'opzione errexit.
Quindi ci sono alcune condizioni in cui uno stato diverso da zero non causerà un'uscita.
Penso che il pericolo stia nel non capire quando set -e entra in gioco e quando non lo fa e si basa su di esso in modo errato in base a presupposti non validi.
Consulta anche BashFAQ/105 Perché set -e (o set -o errexit o trap ERR) non fa quello che mi aspettavo?
Soluzione 4:
Tieni presente che questo è un quiz per un colloquio di lavoro. Le domande potrebbero essere state scritte dallo staff attuale e potrebbero essere sbagliate. Questo non è necessariamente negativo e tutti commettono errori e le domande del colloquio spesso si trovano in un angolo buio senza essere esaminate e vengono fuori solo durante un colloquio.
È del tutto possibile che 'set -e' non faccia nulla che considereremmo "pericoloso". Ma l'autore di quella domanda potrebbe erroneamente credere che "set -e" sia pericoloso, a causa della propria ignoranza o pregiudizio. Forse hanno scritto uno script di shell difettoso, è stato bombardato in modo orribile e hanno erroneamente pensato che la colpa fosse di 'set -e', quando in realtà hanno trascurato di scrivere un corretto controllo degli errori.
Ho partecipato a circa 40 colloqui di lavoro negli ultimi 2 anni e gli intervistatori a volte fanno domande sbagliate o hanno risposte sbagliate.
O forse è una domanda trabocchetto, che sarebbe noiosa, ma non del tutto inaspettata.
O forse questa è una buona spiegazione:http://www.mail-archive.com/[email protected]/msg473314.html
Soluzione 5:
set -e dice a bash, in uno script, di uscire ogni volta che qualcosa restituisce un valore di ritorno diverso da zero.
ho potuto vedere quanto sarebbe stato fastidioso e buggato, non sicuro se pericoloso, a meno che tu non avessi aperto i permessi su qualcosa, e prima che tu potessi restringerli di nuovo, il tuo script è morto.