Prev: list out thousand of files
Next: unzip | touch | re-zip
From: bsh on 1 Jan 2010 04:07
Stephane CHAZELAS <stephane_chaze...(a)yahoo.fr> wrote:
> bsh wrote:
> > Icarus Sparry wrote:

> > This is why ksh93 utilizes the Kiem-Phong Vo's stdio emulation
> > library, sfio ("Safe and Fast I/O").
> In which way does that solve the problem. Are you saying that
> 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
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: list out thousand of files
Next: unzip | touch | re-zip