Re: Redirect stdout and stderr preserving the original order
- From: bsh <brian_hiles@xxxxxxxxxxxxxx>
- Date: Fri, 1 Jan 2010 01:07:25 -0800 (PST)
Stephane CHAZELAS <stephane_chaze...@xxxxxxxx> wrote:
bsh wrote:
Icarus Sparry wrote:
This is why ksh93 utilizes the Kiem-Phong Vo's stdio emulationIn which way does that solve the problem. Are you saying that
library, sfio ("Safe and Fast I/O").
commands run by those shells will use a different stdio by some
sort of LD_PRELOAD trick?
Uh, shells, plural?
Does the LD_PRELOAD facility (trick?) apply at all to _statically_
linked I/O?
I don't have ksh93 source code in front of me; I don't know if ksh93
I/O calls are interpositioned with their stdio.h equivalents or if
they
have been given a discreet namespace.
That has nothing to do with stdio here. With pipes, you'd need
some sort of syncronisation.
I don't and do agree. See my latest response to John Koy.
Then your process that reads the other end of those 2 pipes will
read "x\nz\n" from the first one and "y\n" from the second in no
predictable order, and if it's 2 separate processes reading the
2 pipes, the result is even less likely to be predictable.
I do not have any actual test case that I can give a counterexample
to this (on a system that implements atomic I/O?). My systems
programmer intuition says to me that the true context of the matter
somehow subsumes both of our suppositions.
a LD_PRELOAD solution with a modified stdio that would
do the logging could work assuming all the commands called by
the shell use a dynamically linked stdio.
Hmmm. Isn't "all" (well, when it isn't using sfio...) of process I/O
implemented via dynamically linked in stdio calls?
=Brian
.
- Prev by Date: Re: Redirect stdout and stderr preserving the original order
- Next by Date: Re: unzip | touch | re-zip
- Previous by thread: Re: Redirect stdout and stderr preserving the original order
- Index(es):
Relevant Pages
|
