Skip to main content
Unix & Linux

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

5
  • Yuck, that will copy the whole file instead of truncating it in place. Commented Feb 23, 2020 at 12:08
  • 2
    @mosvy "yuck" is a severe over-reaction. Every UNIX tool that does "inplace" editing (perl -i, sed -i, awk -i inplace, ruby -i, etc.) does that (except ed which makes a copy of the whole file in a buffer!) and it's what the standard advice for every other UNIX tool to modify the original file does (tool file > tmp && mv tmp file). The vast (and I mean vast) majority of people wanting to modify the original file are absolutely fine with it, it's a very, VERY rare occasion when someone actually needs the file truncated instead. Commented Feb 23, 2020 at 14:31
  • Except that you don't need any -i feature to truncate a file at some offset and write something there. The OP said "minimising write access to the disk", and your solution simply fails to do that. Whether it's really warranted to take the OP at their word is a completely different matter ;-) But people do have to deal with huge files, and simply copying them through each time they're modified is not practical, so this doesn't look like a made-up problem. Commented Feb 24, 2020 at 5:37
  • This is offtopic, but FYI some of the tools mentioned by you use different strategies to implement the -i feature, all bad, and not always similar to tool file > tmp && mv tmp file (with tmp on the same fs as file). For instance, ruby will open the file, unlink it and then open as output a new file with the same name. About perl see the links and notes here. Commented Feb 24, 2020 at 12:27
  • 1
    @mosvy I'm not saying it's a made up problem, just that it's an extremely rare problem that should be only be addressed when it proves to be a problem in a specific case, just like anything else performance related that requires complicating a solution that's extremely common, simple and perfectly fine in the vast majority of cases. Commented Feb 24, 2020 at 14:47