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

[Jean Delvare]

Hi Andreas,

> > 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?
> 
> I never needed such a contruct yet, but it could be implemented like
> this. On  the other hand, you might better want to avoid things like
> this; I wouldn't  be surprised if bash has some bugs here.
> 
> #! /bin/bash
> 
> i=1
> echo i=$((i++)) > >(sed -e 's:^:| :')
> # Q: how to wait for the subshell?
> echo i=$i
> 
> j=1
> exec 3> >(sed -e 's:^:| :')
> echo j=$((j++)) >&3
> exec 3>&-
> # Q: how to wait for the subshell?
> echo j=$j
> 
> k=1
> dir=$(mktemp -dt ${0##*/}.XXXXXX)
> trap "rm -rf $dir" EXIT
> mkfifo $dir/fifo
> sed -e 's:^:| :' < $dir/fifo &
> echo k=$((k++)) > $dir/fifo
> wait
> echo k=$k

Thanks for the lesson once again. The fact that we don't seem to know
when the subshell finishes his work in the first two examples is a
problem. And the third example is a bit overkill and probably won't save
me much, it might even take longer than my original code, and is way
less readable too. No luck for me this time, it seems. But at least now
I know that these constructs exist.

It's about time that I share my real code with you all, as - you guessed
- it is a quilt hack. I'll do that right now in a new thread, and maybe
you'll have new ideas when seeing the actual code.

-- 
Jean Delvare