Re: [OT] - Bash question: get output as a variable?
Boyd Stephen Smith Jr. wrote:
> On Friday 05 February 2010 14:47:21 Stephen Powell wrote:
>> On Fri, 5 Feb 2010 12:42:47 -0500 (EST), Bob McGowan wrote:
>> Let me give you a
>> simple example of a CMS pipeline for illustrative purposes,
>> so that you will get some idea of what I'm talking about.
>>
>
> [snip: Long, but very useful description.]
>
>> This pipeline can be illustrated graphically as follows:
>>
>> +---+ +-------+ +--------+ +----------+ +---+
>> |-| < |-->| NFIND |-->| LOCATE |------>| FANINANY |-->| > |-|
>> +---+ +-------+ +--------+ 1 1 +----------+ +---+
>> | 2 | 2
>> V A
>> | +--------+ |
>> LOCM:-->| LOCATE |-->-FIN:
>> +--------+
>
> mkfifo "LOCM" &&
> mkfifo "FIN" &&
> (
> "<" | "NFIND" | "LOCATE" 2> "LOCM" | "FANINANY" 2< "FIN"| ">" &
> "LOCATE" < "LOCM" > "FIN" &
> wait
> )
>
> People with more shell magic than me might be able to simplify that to not use
> fifos, but I figured they were fair game since you get stream labels. (That's
> basically all a fifo is.)
I believe the use of fifo's in this context is required. Unless you're
willing to write the 'LOCATE' and 'FANINANY' tools first, to deal with
inputs on descriptors other than 0, 1 and 2.
Not something I'd care to do, personally. ;)
You might be able to do this using 'exec' to open and redirect the I/O
streams at the shell level, but the nature of the '|' in UNIX/Linux is
to read stdin and write stdout, so everything would need to ultimately
go through those two descriptors, which would disallow having the
"parallel" processing implied by the above diagram.
>
> Technically speaking, that's all one command, per the Single UNIX Specifation.
> It matches the shell grammar start symbol "complete_command" documented
> <http://www.opengroup.org/onlinepubs/007908775/xcu/chap2.html#tag_001_010_002>.
>
> So, basically, we have different basic building blocks (I don't know a grep
> variant that acts like LOCATE, for example), but the larger structure is very
> similar.
>
> Most UNIX/Linux utilities for the command line assume all input on fd 0, all
> normal output on fd 1, and end-user notifications written to fd 2. However,
> there's nothing actively preventing binaries from reading from fd 2, writing
> to fd 0, or expecting i/o on fds 3 through 9. (IIRC, anything greater than 9
> is reserved when using the shell.)
--
Bob McGowan
Reply to: