On Thu, January 13, 2005 12:25 pm, Matthew Gregan said: > At 2005-01-13T12:12:19+1300, Rik Tindall wrote: >> - probably better to have been running this: sed -e 's/few/two/' < >> sedsort.txt > sedsort.txt > > Only if you want to turn sedsort.txt into an empty file... > >> [EMAIL PROTECTED] rik $ sed -e 's/figner/finger/' -e 's/few/two/' < >> sedsort.txt >> > sedsort.txt >> [EMAIL PROTECTED] rik $ cat sedsort.txt >> [is now empty :-/] > > ...as you've just discovered. > > The reason this happens is that the shell opens the files for > redirection before executing the new process (sed, in this case). The > '>' redirection is telling the shell to create a new file, or truncate > an existing one, and begin writing to the start of the file. By the > time the sed process runs, it's going to be reading input from an empty > file and writing it's output (none) to the same empty file. > > Assuming you're using a Bourne-like shell (I'd guess you're using bash), > you can avoid this by enabling the 'noclobber' shell option, i.e. 'set > -o noclobber'. > > Cheers, > -mjg > -- > Matthew Gregan |/ > /| [EMAIL PROTECTED] > Another good reason I would have written the command cat sedsort.txt | sed -e 's/figner/finger/' -e 's/few/two/' > sedsort.txt
( well, I'd have preserved the old file by writing to a new file actually, 'cas I've been there soooo often! ) I do it mainly as the left to right flow along the command line makes more sense to me, but it has the added advantage that sed is processing stdin, not the input file directly. Steve Now, if we'd all have been using VMS... this wouldn't be a problem (: -- Artificial Intelligence is no match for natural stupidity.
