Advanced shell scripting question :-)

Steven W. Orr steveo at syslang.net
Thu Sep 5 13:22:20 EDT 2002


On Thu, 5 Sep 2002, Bob Bell wrote:

=>On Thu, Sep 05, 2002 at 10:04:17AM -0400, Steven W. Orr <steveo at syslang.net> wrote:
=>> What I currently have that gets me closer is as follows:
=>> 
=>> p  2>&1 2> >(tee ERR)  | tee BOTH
=>
=>    BTW, I don't know what the '2>&1' is for.  I get the same behavior
=>without it.
The 2>&1 says "dup stderr onto stdout".
=>
=>> The problem is this: I expect that when data is written to a pipe, that 
=>> the the order is preserved. Using this construct, the order is *not* 
=>> preserved. So on a p that produces many kilobytes of spew, I get big 
=>> chunks in the BOTH file which are from each seperate channel.
=>
=>    I think what you are see is that p is writing to the pipe to "tee
=>BOTH", and "tee ERR" is writing to the pipe to "tee BOTH".  Due to
=>scheduling between the two processes, buffering, etc., ordering is not
=>guaranteed.

This is actually even closer to what I want. The problem is now strictly 
that the output into both is not coming out in the same order as what 
appears on the screen.

p 2>&1 3> >(tee err 1>&2)  2>&3 | tee both

So now I have the process substitution tee reading from channel 3 and 
writing to err and to stderr. (That's the 1>&2)

Then the 2>&3 says to take stdout and dup it onto channel 3. Finally, the 
out and error channels are both sent to the final tee where it gets copied 
to both. It works great, except that the order is not being preserved. :-(

I was under the impression that the order of was supposed to be preserved 
because of the pipe mechanism.

-- 
-Time flies like the wind. Fruit flies like a banana. Stranger things have -
-happened but none stranger than this. Does your driver's license say Organ
-Donor?Black holes are where God divided by zero. Listen to me! We are all-
-individuals! What if this weren't a hypothetical question? steveo at syslang.net





More information about the gnhlug-discuss mailing list