Best alias method for .bashrc

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

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.

  1. Will EndeavourOS ever overwrite .bashrc on an update? and if so, what workarounds are in place? and…
  2. Has anyone found a better way to write aliases?
    Just curious

No. Package updates never touch files in your home directory.


Good to know. Thank you!

1 Like

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.


Why do you do this?

Why not simply

. ~/.bash_aliases

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).


I think this is a good coding habit to catch any possible errors. At least these few lines don’t hurt.

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. :frog:


That doesn’t catch errors. It ignores the potential error.


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:

  1. There is only one file to backup or transfer to other computers (assuming you’re using the similar Bash setup there).
  2. It is impossible to accidentally source the file multiple times.
  3. 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.

1 Like

Off topic

In fact, it is good readable for human.

However, I am not sure why there is a default config in ~/.bash_profile like:

[[ -f ~/.bashrc ]] && . ~/.bashrc

Why not source ~/.bashrc ?
This is in Arch Linux and also EOS.

1 Like

Difference between sh and bash shells.

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.

1 Like

Because ~/.bashrc is not mandatory in a login shell, I think.

I’m using zsh, but anyway, I prefer separate files for my aliases, functions, keybindings or prompts.

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.

Indeed, the output of $ pacman -Qo /bin/sh:

/usr/bin/sh is owned by bash 5.1.016-4