Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Thats a good one. I was originally going to do a "(echo "Put your text here"; cat file) > newfile"
Yours is much better.
Thanks jpollard. Even though all 3 codes will do the same task for OP, we can agree themanwhowas code is best as it doesn't create another file for the new changes.
Last edited by GaryWeaton; 04-20-2016 at 10:19 PM.
Thanks jpollard. Even though all 3 codes will do the same task for OP, we can agree themanwhowas code is best as it doesn't create another file for the new changes.
Internally, sed does the same... but with more work as it has to create the temporary file, then copy the result back into the original file.
The only advantage is that the inode number stays the same, as does any permissions on the file.
I prefer "post #4," but with the additional step of moving (renaming ...) the old-file to an alternate name before moving the new-file into its place.
The advantage of this strategy is that it can be restarted if something goes wrong along the way. You create a new versionof the output first, without altering any of the inputs, nor the existing version of the output. Briefly, the two exist side-by-side. Then, after moving the old-version out of the way (without destroying it ...), you finish the job. But, up to a point, if you then say " !!", your foot doesn't have a hole in it. You can compare the before-and-after files to make sure you didn't screw-up, and you can gracefully recover if when you do. (You can even archive the old versions, indefinitely, for statistical or auditing purposes.)
Last edited by sundialsvcs; 04-21-2016 at 09:08 AM.
Internally, sed does the same... but with more work as it has to create the temporary file, then copy the result back into the original file.
The only advantage is that the inode number stays the same, as does any permissions on the file.
No, the inode number does not stay the same. After sed creates the new file and sets its permissions, it simply renames it over the original. Unlike copying, renaming is an atomic operation and will never leave duplicate or partially copied files.
You can use the "--copy" option to preserve the inode number and its hard links.
Obviously, any "real" implementation of this idea would have to properly deal with concurrency, e.g. through a combination of exclusive file-locking [i](which Unix/Linux might not have ...) and sentinel-files. You would need to somehow know that someone was not already accessing the data, and that no one attempts to do so while the file-state is inconsistent. This is your responsibility to take care of, by whatever means are appropriate to your use-case. (It might be that there is no pragmatic need to do anything special at all.)
No, it is entirely possible for another process to make changes to the file between the time that sed reads it and the time it renames the new file over the old. In fact, if another process is holding that old file open, it will still be accessing the old, deleted file even after the rename. It's an issue that is nowhere near as easily solved as you seem to think.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.