What does 'set -e' do, and why might it be considered dangerous?
Solution 1:
set -e causes the shell to exit if any subcommand or pipeline returns a non-zero status.
The answer the interviewer was probably looking for is:
It would be dangerous to use "set -e" when creating init.d scripts:
From http://www.debian.org/doc/debian-policy/ch-opersys.html 9.3.2 --
Be careful of using set -e in init.d scripts. Writing correct init.d scripts requires accepting various error exit statuses when daemons are already running or already stopped without aborting the init.d script, and common init.d function libraries are not safe to call with set -e in effect. For init.d scripts, it's often easier to not use set -e and instead check the result of each command separately.
This is a valid question from an interviewer standpoint because it gauges a candidates working knowledge of server-level scripting and automation
Solution 2:
From 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.
Unfortunately I'm not creative enough to think of why it would be dangerous, other than "the rest of the script won't get executed" or "it might possibly perhaps mask real problems".
Solution 3:
It should be noted that set -e can be turned on and off for various sections of a script. It doesn't have to be on for the whole script's execution. It could even be conditionally enabled. That said, I don't ever use it since I do my own error handling (or not).
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
Also noteworthy is this from the Bash man page section on the trap command which also describes how set -e functions under certain circumstances.
The ERR trap is not executed if the failed command is part of the command list immediately following a while or until keyword, part of the test in an if statement, part of a command executed in a && or ⎪⎪ list, or if the command's return value is being inverted via !. These are the same conditions obeyed by the errexit option.
So there are some conditions under which a non-zero status will not cause an exit.
I think the danger is in not understanding when set -e comes into play and when it doesn't and relying on it incorrectly under some invalid assumption.
Please also see BashFAQ/105 Why doesn't set -e (or set -o errexit, or trap ERR) do what I expected?
Solution 4:
Keep in mind this is a quiz for a job interview. The questions may have been written by the current staff, and they may be wrong. This isn't necessarily bad, and everyone makes mistakes, and interview questions often sit in a dark corner without review, and only come out during an interview.
It's entirely possible that 'set -e' does nothing that we would consider "dangerous". But the author of that question may mistakenly believe that 'set -e' is dangerous, due to their own ignorance or bias. Maybe they wrote a buggy shell script, it bombed horribly, and they mistakenly thought that 'set -e' was to blame, when in fact they neglected to write proper error checking.
I've participated in probably 40 job interviews over the last 2 years, and the interviewers sometimes ask questions which are wrong, or have answers which are wrong.
Or maybe it's a trick question, which would be lame, but not entirely unexpected.
Or maybe this is a good explanation: http://www.mail-archive.com/[email protected]/msg473314.html
Solution 5:
set -e tells bash, in a script, to exit whenever anything returns a non-zero return value.
i could see how that would be annoying, and buggy, not sure about dangerous, unless you had opened up permissions on something, and before you could restrict them again, your script died.