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!
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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 10: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.