I like aliases and my method of creating them has been to create a file .bash_aliases and write them there. Then I add:
if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi
to .bashrc.
That way, if .bashrc were to somehow be overwritten, all I would have to do is add the above lines and not re-write the aliases. As an Arch Linux user I have never had this happen, but I have heard some distros do overwrite .bashrc when updating.
This isn’t an urgent question as everything is working fine, but I thought there could be some interesting discussion around this topic.
Will EndeavourOS ever overwrite .bashrc on an update? and if so, what workarounds are in place? and…
Has anyone found a better way to write aliases?
Just curious
Maybe somewhat off-topic, but although aliases are nice and easy to use, they also are rather limited in features.
So if you ever need more power than aliases can provide, you can create bash functions instead. Of course more learning is needed, but functions offer much more features and power.
or even better (same thing, but more idiomatic to Bash):
source ~/.bash_aliases
?
If you think about it, that if statement is completely superfluous. It checks whether the file .bash_aliases exists and if it does, it sources it. If it doesn’t exist, it does nothing.
Is this desired behaviour? Is there ever a situation where this file does not exist? If so, is that a normal situation? Or if this file suddenly disappeared, wouldn’t that mean that something extraordinary has happened, like filesystem corruption? Wouldn’t you like an error displayed if that happened?
Usually, a distro-default .bashrc file that ships with many distros has this if statement. The reason for that is because, in some installs, the file with aliases might not exist, and the distro maintainers want one .bashrc file to cover all cases. But if you are writing your .bashrc yourself for yourself, that is entirely pointless, you know whether .bash_aliases exists or not.
I pretty much do it the same way as you, except without that pointless if statement, and I keep this file with aliases in some other directory, and it is not a hidden file – the latter is just a personal preference: I prefer to have minimal dotfile clutter in my home directory. In fact, I don’t even have the actual file .bashrc in my home directory, but a symbolic link, the actual file is in some other directory and not hidden (so I can make backups more easily).
It’s exactly the opposite: it doesn’t catch any errors.
The way I suggested it, without the if statement, will actually display an error message:
bash: /home/username/.bash_aliases: No such file or directory
alerting you that something is wrong.
With the if statement, if the file does not exist, it won’t do anything, leaving you troubleshooting why your aliases stopped working.
Also, it makes your .bashrc some 40 bytes larger and wastes a few syscalls to do a filesystem read to check whether the file exists (twice), causing your terminal to start a few nanoseconds slower. While this is not something you would likely notice, the mere fact it is wasteful without doing anything useful bothers me as a matter of principle. It’s bloat.
I just have one file with everything. I’m the only user of my computer so i have a back up .bashrc file in another directory in my home folder. However my personal .bashrc file has never been written over by and update/grade.
I love learning new things, so this has been a feast. I think my questions have been answered. Most importantly, I know package updates don’t touch the home directory. That was a big worry. Kresimir’s suggestion is something I’m going to try to implement. In my own case, I’m not looking looking for the perfect personal solution as I install Endeavour for others interested and need something consistent, easy to troubleshoot, and enduring. I think
. ~/.bash_aliases
qualifies for that use case. And thanks to manual for suggesting functions. Definitely going to research that.
As @Kresimir suggested above, I’d also prefer using
source ~/.bash_aliases
instead of
. ~/.bash_aliases
simply because it is somewhat easier to search when troubleshooting.
In small scripts it doesn’t really matter, but consistency is still worth considering.
This is a good idea. There are several advantages to it:
There is only one file to backup or transfer to other computers (assuming you’re using the similar Bash setup there).
It is impossible to accidentally source the file multiple times.
It’s a tiny bit faster, because there is no need to read another file when starting the terminal session. Though this shouldn’t be perceptible.
And there aren’t any real disadvantages (as mentioned earlier, the fear of it being destroyed by an update is misplaced, and you should have it backed up anyway). The only reason why one wouldn’t do it like that is code organisation, having everything neatly in one place… I’ll give it some more thought, but I think I’m going to reorganise my aliases into the parent file.
Bash supports both ways, and (if I remember correctly) sh does not.
Also note that Arch makes sh the same as bash, so sh will not complain about such bashisms.
Program checkbashisms can check scipts for features supported only by bash and not “pure” sh.
It is the difference between what a distro should do and what you should do. The distro should make things work without an error since it isn’t mandatory to have a .bashrc.
However, if you expect to have a .bashrc and it is missing, it is better to get an error in that case.