help-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Help-bash] subshell/eval terminates early with set -e when embedded com


From: John Calcote
Subject: [Help-bash] subshell/eval terminates early with set -e when embedded compound command fails early
Date: Thu, 30 Jun 2016 09:23:13 -0600

Hi folks,



I have a problem in bash I’d like to run past you all. I’m not a bash
expert, so I freely admit I may just be misunderstanding the docs. Here’s a
stackoverflow reference for lots of background:



http://stackoverflow.com/questions/38111035/why-does-eval-exit-subshell-mid-pipe-with-set-e



When I run this command:



$ bash -x -c 'set -e; false && true; echo here'

+ set -e

+ false

+ echo here

here



I see what I expect – false is shown to cause the compound command ‘false
&& true’ to bail out early, but the failure of the first sub-command in the
compound command does not cause the entire sequence to terminate (because
of set -e). Rather, ‘here’ is also echoed. This all makes sense to me –
it’s the way it’s documented to work and the way I expect it to work.



However, when I put ‘false && true’ in a subshell like this:



$ bash -x -c 'set -e; (false && true); echo here'

+ set -e

+ false



then only ‘false’ is displayed – ‘here’ is never echoed because false
causes the subshell to exit with the last error code presented by the last
command in the subshell. On the other hand – if I run this command:



$ bash -x -c 'set -e; (false && true; echo hi); echo here'

+ set -e

+ false

+ echo hi

hi

+ echo here

here



I now see ‘here’ from the outer shell – I presume this is because the
semantics of compound commands does not allow set -e to fail the sequence
in the subshell just because a non-terminal sub-command in the compound
command failed. The issue is that if the compound command is the last
command in the sub-shell, it will return the failed sub-command’s error
code to the shell and that will, in turn, be passed as the result of the
sub-shell.



This entire discussion also applies to eval – if I ‘eval’ a sequence of
commands and the last one in the sequence is a compound command that fails
early, then eval will receive (and return) the failed sub-command’s result
code.



Frankly, I see why it’s happening. I just don’t know how to make it not
happen – if I want to ‘eval’ an arbitrary (user-entered) command, and I
want it to act like a shell normally acts, I really don’t want eval to
return an error code if a compound command happens to be the last command
in the eval sequence and it fails early.


Any ideas would be appreciated.



Thanks in advance,

John


reply via email to

[Prev in Thread] Current Thread [Next in Thread]