Re: [Quilt-dev] [OT] bash question

[Jean Delvare]

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