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


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

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

Started byEli Schwartz <eschwartz@archlinux.org>
First post2019-11-14 18:16 -0500
Last post2019-11-14 18:16 -0500
Articles 1 — 1 participant

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 Eli Schwartz <eschwartz@archlinux.org> - 2019-11-14 18:16 -0500

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

FromEli Schwartz <eschwartz@archlinux.org>
Date2019-11-14 18:16 -0500
SubjectRe: set -e ignored in subshell if part of command list
Message-ID<mailman.1501.1573773402.13325.bug-bash@gnu.org>

[Multipart message — attachments visible in raw view] — view raw

On 11/14/19 6:02 PM, Ángel wrote:
> I would say that the confusing part is that the behavior of the subshell
> is dependant on *where* it is being executed in the parent.
> 
> In general terms, I would expect
>   ( <code> )
> to be roughly equivalent to 
>   bash -c "<code>"
> 
> i.e. <code> being executed on its own context and unable to affect the
> parent

But that's totally wrong for *numerous* reasons.

> but the provided case shows that 
>   ( set -e; false; echo here ) && echo bar
> behaves differently than
>   bash -c "set -e; false; echo here" && echo there

What about

var=value; (echo "$var")

which behaves differently from

var=value; bash -c 'echo "$var"'

or,

func() { echo "hi there"; }; (func)

which behaves differently from

func() { echo "hi there"; }; bash -c 'func'

> since the initial subshell has an advanced knowledge that there will be
> a later command joined by an and.

An initial subshell has advanced knowledge about lots of things from the
parent shell, it is deeply, worryingly dangerous to write code that
doesn't take this into account. Things will tend to go pretty badly wrong.

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

[toc] | [standalone]


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


csiph-web