Re: Bug when trapping exit from subshell

[Mark Ferrell]

I believe that if you actually execute the script as intended you will
find that your reading of the code is incorrect.  Really though,
redirection should not be the problem since:

  1. Redirection of the output of one command does not change the
redirection of the script as a whole, and so it should never change
redirection of the command invoked by the handler. Changing
redirection of the script as a whole via 'exec' sure .. but not for a
single command.
  2. Redirection would not have effected the output when 2 different
commands where used for handling the exit condition.  As mentioned in
the first email, the exit handler gets called and reports properly
when the script is handed /bin/false as the command to execute.
  3. Again, as previously stated .. the output is valid when
interpreted  with dash, ksh, and zsh.  It is only when interpreted
with bash that it fails.
  4. Changing the body of main() from {( ... )} to { ... } results in
bash calling the exit handler.

The lack of space in '!:' in this context acts as an invalid command.
If you actually "run" the script and hand it various commands to test
against, say "true", "false", "/bin/false", or "no/such/command" you
will find that the exit handler DOES indeed get called for valid
commands, even if the command returns a non-zero exitcode.  So
/bin/false results in the exit handler being called, but the builtin
false() does not, nor will 'no/such/command'.

Lastly, this script was the simplest example I could come up with
after finding this bug, the original use-case had the exit handler
logging to a file in which the message was lost when interpreted by
bash.

On Fri, May 16, 2014 at 9:48 PM, Maarten Billemont <lhunath@gmail.com> wrote:
> the exit handler is called, you just muted it.  remove the redirections, and
> you'll also notice you need a space after your !
>
>
> On 16 May 2014 12:41, Mark Ferrell <major@homeonderanged.org> wrote:
>>
>> The following script properly reports the exit code to the calling
>> environment, , but the exit handler is not called if a function
>> triggers the exit vs an external command.
>>
>> Script executed via:
>> bash <script> false;echo $?
>> bash <script> /bin/false;echo $?
>>
>> Expected the function 'exit_handler()' to be called in both cases.
>> When using bash, exit_handler() was only called in the '/bin/false' case.
>>
>> Note: this behaviour is only seen in bash (tested on 4.1.2 on CentOS
>> 6.5 and 4.2.25 on Ubuntu 12.04).  The following shells where also
>> tested and all behaved as expected (i.e. the exit handler was called):
>> ksh, dash, BusyBox's ash, and zsh.
>>
>> Script:
>> set -e
>> exit_handler() { echo "exit code: $?"; }
>> false() { !:; }
>>
>> main()
>> {(
>>     trap exit_handler 0
>>     "$@" >> /dev/null 2>&1
>> )}
>> main "$@"
>> echo "after main"
>>
>