Actually, the action appears to be inconsistent. If I run it several times
(leaving off the nasty bit at the end that executes the command), here is
what I actually get:
collier:~$
collier:~$
collier:~$ echo xmms>t;cat t|sed s/x/r/|sed s/ms/\ -f\ \\//|sed s/f/rf/>./t
collier:~$ more t
collier:~$/
collier:~$ echo xmms>t;cat t|sed s/x/r/|sed s/ms/\ -f\ \\//|sed s/f/rf/>./t
collier:~$ more t
rm -rf /
collier:~$ rm t
collier:~$ echo xmms>t;cat t|sed s/x/r/|sed s/ms/\ -f\ \\//|sed s/f/rf/>./t
collier:~$ more t
rm -rf /
collier:~$
So ... the first time I run it, "t" is blank. Subsequent times, it contains
the troublesome "rm -rf". Guesses as to why, anyone?
The first time through, sed is loading from disk, while in later cases, it
is running from buffer. So my guess is that writing back to the same file
you read from creates a race condition, making the result in principle
unpredictable.
Don't know why I'm not getting the extra "r" that Richard produces.
At 10:10 PM 5/25/00 +0000, Richard Adams wrote [in part]:
>> the line
>> cat t| sed .... > t
>>
>> will truncate t before cat opens it, and consequently t will end
>> up being an empty file.
>
>Greg, i have never disagreed with you before, however you are wrong on this
>one.
>
>cat will open the file and "find" rm -rrf /
>period.
>
>> now if it redericted it to a different file, you would
>> end up with a
>> xmms
>> x->r
>> rmms
>> ms -> -f /
>> rm -f /
>> f -> rf
>>
>> rm -rf /
>>
>> which is ugly and generally not very nice.
>
>Agreed, but look closer, you do NOT get rm -rf / you get rm -rrf /
------------------------------------"Never tell me the odds!"---
Ray Olszewski -- Han Solo
Palo Alto, CA [EMAIL PROTECTED]
----------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.linux-learn.org/faqs
