From: Kenn Humborg (kenn at domain bluetree.ie)
Date: Mon 14 Feb 2000 - 11:28:34 GMT
> > On Fri, 11 Feb 2000 20:02:33 -0000 "Kenn Humborg" <kenn at domain bluetree.ie>
> > wrote:
> > | > sed 's/ *| */|/g' file | cat > file
> >
> > | > surely ??
> >
> > | Is that _guaranteed_ not to truncate 'file' before sed
> > | reads it?
> >
> well, yes it should do, because its handing the output to cat before being
> piped back into itself . . . now of course thats down to how much info cat
> can hold . . . but you certainly shouldn't see sed overwrite the file it's
> trying to parse
I'd have to disagree. I'd see it working like this:
1. Shell breaks up pipeline into two commands:
sed -e '...' file
cat > file
2. It creates a pipe.
3a. To execute the first command, it creates an argv array,
hooks fd 1 up to the pipe's input and forks/execs.
3b. To execute the second command, it opens 'file' for writing
on fd 1, which should truncate the file. Then it forks
and execs cat.
So, depending on the order in which 3a and 3b are done, sed
might get enough time to read all of file (if it is short and
in-cache) before the shell truncates it.
Of course, I might be wrong, and there might be some obscure
trick which makes this work the way you want, but I can't see
it from the bash manpage.
And let's say file is 100MB and not in-cache. I really doubt this
would work.
Later,
Kenn
This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:05:25 GMT