Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I thought that sed may have a "high" overhead, and that's why it took so long.

YMMV, but I just reproduced this on my machine, and the tail command took 3 minutes. Maybe you are limited by disk IO?

What was the sed command you used?

EDIT: sed was even a bit faster with:

  sed -i '4s/^.*$/your line four/' sqldump
Took 20s less than my tail solution, and does not occupy duplicated disk space.


I deleted the line with `sed -i "4d" sqldump`. The duplicated disk space comes from sed writing a temporary file out to the current directory, it does this in chunks as the command runs.

It makes sense for sed to write a temp file even with `-i` because what happens if your power goes out mid-way through the command without the temp file? You'd have data loss. To combat that sed will write a temp file out and when the operation is completed the last step is to move the temp file to the original file to overwrite it. You might not notice this unless you monitor the directory for changes while sed runs. You can spam `ls -la` as sed runs on a decently sized file to see the temp file.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: