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
signature.asc
Description: OpenPGP digital signature
