Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #15674 > unrolled thread

Re: set -e ignored in subshell if part of command list

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: set -e ignored in subshell if part of command list Chet Ramey <chet.ramey@case.edu> - 2019-11-13 11:30 -0500

#15674 — Re: set -e ignored in subshell if part of command list

On 11/13/19 10:59 AM, Shaun Crampton wrote:
> But the commands in the subshell execute inside a different shell
> execution context so they shouldn't have
> their own set -e context (Section 2.12)?

Why? That section says the only thing that changes in the subshell 
environment is signal dispositions.

In fact, the example in the set builtin description explicitly assumes
the subshell inherits the errexit setting. The only thing the standard
requires here is that setting -e in the subshell doesn't change the
parent's setting.

But that's not exactly the point. The shell is "executing any command of an
AND-OR list other than the last" so errexit is ignored.

> 
> I don't see where the spec says that the subshell has to inherit the
> and/or list-ness of the
> parent context.  Section 2.12 doesn't mention that as being one of the
> things that a subshell inherits
> (and unless I'm missing a good use-case, it seems like a pretty
> useless thing to inherit in a subshell
> or a function that happens to be called on the LHS of an and/or).

"A subshell environment shall be created as a duplicate of the shell
environment, except that signal traps that are not being ignored shall be
set to the default action. "

It's an exact duplicate of the shell environment. It's easier to list the
exceptions rather than the long list of things it inherits (more than the
list earlier in that section).

In any event, it's how existing shells behave, and the standard is
attempting to match existing practice. In fact, part of the proposed
language from 2009, when this was debated at length, was "The -e option is
ignored and cannot be enabled by any command run by these lists" but that
was considered unnecessary.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web