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