UNIX for Dummies Questions & Answers

I am messing around with sed and I observed the following.

I have as test file a file named errors which contains:

I want to remove the > from the beginning of the lines. So I use the following command.

Code:

sed 's/^> //' errors

which apparently works. Then, I want to redirect the results back to the original file. So I tried this:

Code:

sed 's/^> //' errors > errors

but now the file errors contains nothing. Why?

When I redirect the output to another file it seems to work. For example the file asdf contains the results:

Code:

sed 's/^> //' errors > asdf

Furthermore, when I try:

Code:

echo `sed 's/^> //' errors` > errors

it seems to work but the characters of new line are replaced by spaces. I guess this is because of the usage of echo. But what is different now and the redirection works?
Is it because the output is guaranteed that will be redirected after it is completely calculated?
What's the difference?

I am looking forward to your replies.

Hi.

This is a succinct description of how the shell can destroy the file in your situation:
The problem is not with sed, it will be with any command because it's the result of the shell.

It's common to run across this apparently surprising outcome in early use of *nix -- best wishes ... cheers, drl

So, I guess this worked because the

Code:

sed 's/^> //' errors

was executed before anything else in the line and the result substitutes the contents of `...` before proceeding to the rest of the code?
So, it's a matter of priorities, right?

HI.
If we consider priorities as the predefined sequence of events that the shell goes through to process a command, yes.

I usually refer people to the O'Reilly book on the bash shell or the Korn shell. In the former, around page 178 is a flow-chart and explanation of the steps.

Step 7 is command substitution ( the back-quotes or the more modern $(...) ), and step 12 is the setup of I/O redirection, etc. ... cheers, drl