> One construct in bash is absolutely super: process substitution. You can read the output of a program as if it were a file with the construct: <(myprogram)
Actually had to look that one up[1] -- unfortunately you're right, it's not posix (I don't think I would've tried it in a [ed: non-interactive] script, but I agree it is very nice).
I wonder if you could make a function as a work-around, something like:
r() {
#r(first some args <(second other args))
# Use a fifo:
ff=$(mktemp fifo)
# might as well use that for parsing the commands...
echo "$*" > $ff
first=`sed -re 's/\((.*) <\(.*/\1/p' < ${ff}`
echo "$*" > $ff
second=`sed -re 's/\(.* <\((.*)\)/\1/p' < ${ff}`
${second} > $ff &
${first} < $ff
}
Adjust for parsing the direction of the <() vs >() etc... Not particularly robust, and the above is un-tested... Just an idea.
I'm not convinced trying to parse shell command lines for macro functionality is a good idea in general...
I hadn't really thought about that echo'ing the filename might be useful, but this is pretty equivalent to how things work in bash -- with "diff <(some) <(other)", diff gets two temporary file-handles to two fifos -- that are later cleaned up by the shell. As most good ideas, obvious when you think about it :-)
Actually had to look that one up[1] -- unfortunately you're right, it's not posix (I don't think I would've tried it in a [ed: non-interactive] script, but I agree it is very nice).
I wonder if you could make a function as a work-around, something like:
Adjust for parsing the direction of the <() vs >() etc... Not particularly robust, and the above is un-tested... Just an idea.I'm not convinced trying to parse shell command lines for macro functionality is a good idea in general...
[1] http://mywiki.wooledge.org/Bashism