On Fri, 26 May 2000, Tom Rauschenbach wrote:
> > The -o option of the sort command is designed to get around the
> > stdout redirection in a case such as:
> >
> > sort file > file
> >
> > which WILL NOT WORK, even under modern shells. In this case, you will
> > definitely wipe out your input file. But if you do
> >
> > cat file | sort > file
> >
> > This will work just fine. It's just not necessary and adds overhead. On
> > the other hand, with modern hardware the overhead is probably not worth
> > mentioning unless you've got a REALLY busy machine.
>
>
> Or unless you do the expirement on a relatively slow device like a ZIP drive
> hoping that you will have time to see the tmp file...
>
> [root@grumpers zipdrive]# cat gnomesrc.zip |sort >gnomesrc.zip
> [root@grumpers zipdrive]# ls -l
> total 12
> -rw-rw-r-- 1 root root 0 May 26 18:45 gnomesrc.zip
> drwxr-xr-x 2 root root 12288 Feb 2 1999 lost+found
> [root@grumpers zipdrive]#
>
>
> I ran this
> > $ echo j > junk; cat junk | sed "s/j/p/" > junk
> > $ cat junk
> > p
>
> and got the result you said I would. Now I'm really puzzled.
After doing some more experiments with this myself, I am too. I realized
later that the second example I gave still shouldn't work, and with a
large enough input file, it doesn't. I think I was half right; commands
separated by a ; should work fine, but those separated by pipes should
have issues.
My best guess at this point is that if the original file fits inside a
single kernel I/O buffer, it will work. I'm gonna CC: a couple of our
kernel engineers, and if they're bored or curious enough, or happen to
know the answer off the top of their collective head, maybe they'll get
back to us and let us know what the hell is going on... :)
To restate the problem succinctly:
When one runs the following command sequence:
$ echo j > junk; cat junk | sed "s/j/p/" > junk
$ cat junk
One gets the answer 'p' which is what you would expect, were it not for
the fact that the redirection SHOULD wipe out the input file, yeilding a
zero length file instead of 'p'.
However, when one runs something like:
cat file | sort > file
when file is sufficiently large (whatever that means) the file gets
truncated to 0 bytes.
To make matters worse, I just ran the example above with sed on my 2.2.15
machine here at home, and I got a truncated file. I wonder if this wasn't
a result of the bounds-checking socket bug in pre-2.2.15 kernels...
I'm gonna have some rum and go to bed. If I'm gonna kill some brain
cells, I might as well at least enjoy it.
--
Derek Martin
System Administrator
Mission Critical Linux
[EMAIL PROTECTED]
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
