3 ms·
Wouldn't something like this, work for your specific use case: head -n4 sqldump > sqldump2 Then change the line 4 in sqldump2 to whatever you wanted to, and
by SushiHippie 3y ago
Wouldn't something like this, work for your specific use case:
head -n4 sqldump > sqldump2
Then change the line 4 in sqldump2 to whatever you wanted to, and after that:
tail -n+5 sqldump >> sqldump2
And now sqldump2 contains sqldump but with line 4 edited.
This still requires double the disk space, but at least shouldn't take 30 minutes.
- nickjj 3y agoThat would work but what would tail do different than sed here? Both would still need to read and write the full file (minus 4 lines for tail) which without testing indicates the time would be the same.
- SushiHippie 3y agoI 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.
- nickjj 3y agoI 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.