No, they don't - but they have other problems which is why their usage is discouraged anyway:

What sed -i does is in fact opening a second file, write to it and then deleting the original and moving its temporary file where the original one was - BEHIND YOUR BACK!

The "advantage" is manifold: first you have no control over this. If something happens (crash, aborted task, ...) then the temporary file remains and clutters up space. That might happen to you with writing to a target file "manually" too, but in this case you are aware of the fact and might take cleaning actions. In case of sed -i you are probably not aware of this temporary file because you have been lied to by the program about its existence.

Second, even if you are aware of that: where would start searching for it? If i have some code like this:

Code:

if sed '<something>' /path/to/input > /some/output
     mv /some/output > /path/to/input
else
     print -u2 "Error executing sed ..."
fi

I have control over where the temporary file goes. And because of that i know where to look at to clean up. Do you know where sed -i puts its temporary file? i don't and the man page is busy telling you lies about the non-existence of the file, so it won't tell you either.

Third, and worst, IMHO: because of the mechanism you are most probably not aware that the files inode changes! This does not only mean the inode number but it may also mean that the ownership and/or the filemode may change (in case of a directory with SUID bits set). If one uses an explicit temporary file one is perhaps aware of this and does (from the example above:

Code:

if sed '<something>' /path/to/input > /some/output
     mv /some/output > /path/to/input
     chown someuser:somegroup /path/to/input
     chmod ....
else
     print -u2 "Error executing sed ..."
fi

But with the original file still in place (wink wink) why should one do that?

Finally, and perhaps most importantly: scripts should make as few assumptions about their surroundings as possible. Only GNU-sed understands the -i-option, but POSIX does not. Should i willingly limit my script to systems with a GNU-sed available? I don't think so.

All these reasons are why i strongly suggest not to use the -i option even if the sed in question supports it.

I hope this helps.

bakunin