/bin just links to /usr/bin so directly pointing to /usr/bin makes sense. There’s no reason to assume that /bin is going away anytime soon. But overall a better way to be prepared for any change is probably using #!/usr/bin/env bash.
2 Likes
is this something that can be automated? I feel like there could be a tool that will do this - make copies of each affected file, using versioning and history, show you a visual diff, do an online search for relevant hits, and allow you to accept changes or revert.
does something like this exist?
I have no idea if that exists. I frankly don’t care. I enjoy maintaining my systems, and as for me, I rarely bother to make a backup file as I’m pretty confident of what I’m doing.
2 Likes
Why trust a tool with the passwd file? Any tool that somebody else creates is not going to know your system. Just use your eyes and your brain. It ain’t that hard.
That isn’t what is happening. This change isn’t because it is being eliminated.
However, if you want to change your scripts you should make them portable.
Use:
#!/usr/bin/env bash
2 Likes
No, the whole point is that you shouldn’t automate it.
Honestly, it would be far better to ignore pacnew files than it would be to automate the process.
Far more people break their systems overwriting or merging pacnew files incorrectly than break them from ignoring them.
4 Likes
I agree with the OP, great advice.
I’d just like to point out that there is no need to make a backup copy of the .pacnew file, for two reasons:
- You should never be modifying it, because it has no effect on the installed packages. It’s only there to guide you about the changes you should make in your original config file. After you’re done modifying the original file, you’re probably going to delete the
.pacnewfile. - If you accidentally mess it up, you can recover it by reinstalling the package, there is nothing of value in there.
Of course, there is no harm in making a backup copy of it.
It’s a good idea to back up the original file, because that is the file you’ll be editing.
I agree that you should not use any specialised tools or automation for this. Just a text editor will work fine. You can also use the diff tool, if you have problems spotting the differences in a text editor.
5 Likes
We’re off topic here, but just to clarify:
On any sane system, /bin/bash ought to be a symlink pointing to the real bash executable (most likely /usr/bin/bash, but not necessarily).
Therefore, #!/bin/bash should be pretty portable. It will always work on Arch. I would argue it’s better than #!/usr/bin/bash. However, #!/usr/bin/env bash is probably the most portable option, but none of them are specified by the POSIX standard, so none of them are 100% portable. It’s extremely unlikely, but on some weird system /usr/bin/env might also not exist.
There is also a tiny security problem with #!/usr/bin/env bash, as it could allow privilege escalation for an arbitrary process when the script is run with sudo. A malicious program could modify the user’s PATH variable to trick the user into running some other program instead of bash, granting it root privileges. That’s one of the reasons, as a shell programmer, you should never write scripts that require the user to run them with sudo. Instead, use sudo inside the script, and only for commands that need root. Of course, for users who use doas instead of sudo, such scripts won’t be portable, so they are advised to make a root owned symlink for sudo. For a similar reason, we typically do not add . to the PATH variable, so we have to run executables in the current directory as ./program instead of just typing program.
What you should never, ever use for Bash scripts is #!/bin/sh. Those are only used for fully compliant POSIX scripts. For example, on Debian, /bin/sh is a symlink to Dash. Except that location /bin/sh for a shell is not required, nor specified by POSIX, so it might not exist on some systems. 
However, in the end, worrying about full portability is pretty much pointless. There is nothing wrong with the scripts being be tailored to a specific distro. For scripts that are going to be part of a repository for some GNU/Linux distribution, it’s best to use what actually works on that particular distro.
What is important, in my opinion, is to not be misleading in scripts: don’t write #!/bin/sh if your script contains Bash-specific commands (bashisms). #!/bin/bash is perfectly fine in my opinion for Bash scripts that you expect to run on Arch Linux, or any other sane GNU/Linux configuration.
So if you are not sure, use checkbashisms utility, to make sure your script is fully POSIX compliant if you expect it will run in some shell other than Bash.
4 Likes
I frequently find it faster and simpler to add my edit to the pacnew file; of course it varies depending upon the amount of change that has occurred.
True, but this is addressed to the noobs, and by having a copy of the pacnew, it saves time (plus several extra forum posts) if they screw something up.
4 Likes
Sure, that makes sense. 
I find Meld is an excellant tool for comparing files.
It will even highlight the differences. 