mainThe GNU Bourne-Again SHell - Support: sr #109542, "set -e" is not...

 
 

sr #109542: "set -e" is not evaluated properly in outer script when command substitution in here-doc or here-string fails

Submitter:  Björn Kautler <vampire0>
Submitted:  Thu 09 Aug 2018 05:48:58 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  Invalid
Privacy:  Public Assigned to:  None
Open/Closed:  Open Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 23 Aug 2018 02:34:52 PM UTC, comment #4: 

Yeah, I see it in this case, as the expansion is done in the redirect which is handled separately.

Björn Kautler <vampire0>
Mon 20 Aug 2018 02:08:26 PM UTC, comment #3: 

The same answer: those are not commands; they are word expansions.

The return status of a word expansion does not affect the exit status of, for instance, the `cat' commands in the examples.

Chet Ramey <chet>
Group administrator
Mon 20 Aug 2018 12:46:44 PM UTC, comment #2: 

Same reasoning as for https://savannah.gnu.org/support/index.php?109540.
The docs about `set -e` suggest to me this should be failing as it does not qualify for the "do not fail if" conditions.
As far as I understood the `set -e` intention is to fail the script as often and as soon as possible if some command does not work like expected / intended to find script errors more thoroughly.

Björn Kautler <vampire0>
Fri 17 Aug 2018 06:50:53 PM UTC, comment #1: 

Why would you think that the failure of a command substitution during word expansion would affect the output of a simple command that is not a variable assignment, overriding the exit status of the command itself?

It is the variable assignment containing a command substitution that is the special case, not the other way around. This is documented in the SIMPLE COMMAND EXPANSION section of the manual page.

Chet Ramey <chet>
Group administrator
Thu 09 Aug 2018 05:48:58 PM UTC, original submission:  

This properly fails the outer script, no output.


#!/usr/bin/env bash
set -e
foo=$(false)
echo after





This properly fails the outer script, no output.


#!/usr/bin/env bash
set -e; shopt -s inherit_errexit
foo=$(false; echo foo)
echo after





This properly fails the outer script, no output.


#!/usr/bin/env bash
set -e
set -o pipefail
foo=$(false | true)
echo after





This does not fail the outer script, four times "foo" and "after" are output. Expected would be failure of the outer script for #1 and #4.


#!/usr/bin/env bash
set -e
cat <<< $(false)
cat <<< $(false; echo foo)
cat <<< $(false | true; echo foo)
cat << EOM
        $(false)
EOM
cat << EOM
        $(false; echo foo)
EOM
cat << EOM
        $(false | true; echo foo)
EOM
echo after





This does not fail the outer script, two times "foo" and "after" are output, so the `-e` is at least forwarded to the subshell. Expected would be failure of the outer script for #1, #2, #4 and #5.


#!/usr/bin/env bash
set -e; shopt -s inherit_errexit
cat <<< $(false)
cat <<< $(false; echo foo)
cat <<< $(false | true; echo foo)
cat << EOM
        $(false)
EOM
cat << EOM
        $(false; echo foo)
EOM
cat << EOM
        $(false | true; echo foo)
EOM
echo after





This does not fail the outer script, only "after" is output, so the `-e` and the `pipefail` are at least forwarded to the subshell. Expected would be failure of the outer script for all 6 examples.


#!/usr/bin/env bash
set -e; shopt -s inherit_errexit
set -o pipefail
cat <<< $(false)
cat <<< $(false; echo foo)
cat <<< $(false | true; echo foo)
cat << EOM
        $(false)
EOM
cat << EOM
        $(false; echo foo)
EOM
cat << EOM
        $(false | true; echo foo)
EOM
echo after


Björn Kautler <vampire0>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by chet (Posted a comment)
  • -email is unavailable- added by vampire0 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-08-17 chet StatusNone Invalid

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code