Hi Andreas, > > > for ((i = 0; i < 4; i++)) > > > do > > > n=$i > > > done \ > > > | cat > (...) > The issue here is the pipe, where each pipe command is run in its own > sub-shell.
That's what I had finally figured out, yeah. > The cat in the example doesn't make a lot of sense (it's useless). Yup, I know, it was simply for the benefit of the example. My real code does sense and is useful :) > Think about this: > > #! /bin/bash > > set -x > > i=1 > echo $i > > i=2 | i=3 > echo $i At this point I was surprised. Firstly because I'd have expected that at least one half of the pipe would be run by the current process (and as such would succeed in setting the value of i), and that's not the case. Secondly because there's only one '+' in the trace log in front of "i=2" and "i=3". I thought that subshells were identified by '++' instead? > i=4 < <(i=5) > echo $i I think I remember that older versions of bash don't support this syntax though. John was wanting to replace them, right? > i=6 <<EOF > $(i=7) > EOF > echo $i Nice, thanks for the lesson. However it doesn't seem to address my immediate problem. In both cases, the part which is able to set the value of variables is the part receiving the data flow, not the part emitting it. Is there a way to somehow revert these constructs so that emitting part is run by the current process instead? Thanks, -- Jean Delvare _______________________________________________ Quilt-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/quilt-dev
