Bash aliases should go in the
.bashrc files in individual home directories. If you must create global bash aliases, they can go in
/etc/bash.bashrc, but it is often best simply to add them to the
.bashrc files in
/etc/skel so they are inherited by newly created users.
It is virtually always wrong to define an alias in in
To understand why, one must understand under what circumstances commands from each of these files are run. There are misconceptions about this, which I address below.
Even though you want to define aliases for multiple users, you should be familiar with how they are defined for individual users, so that you can decide on the best method of doing what you need.
Aliases for Individual Users
Especially if you use a GUI, most of your interactive shells are probably non-login shells. Even if you never use a GUI, you probably still use non-login shells with some frequency. You'll want your aliases to work in these shells.
Especially if you ever log in on non-graphically in a virtual console or via SSH, you probably use login shells some of the time. So you'll want your aliases to work in interactive login shells also.
When an interactive, non-login shell starts, it sources
.bashrc in the user's home directory. By default in Ubuntu, each user's
.bashrc itself sources
.bash_aliases, if it exists.
- To source a file is to cause its contents to be run in the current shell. Changes to the shell environment made in a file that is sourced persist even after all the commands in the file have been run.
Reading the comments in Ubuntu's default
.bashrc reveals that it is officially intended that aliases go in
.bashrc already contains some alias definitions (run
grep '^[[:blank:]]*alias' ~/.bashrc to see them), and gives explicit advice about where to put new such definitions:
# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.
if [ -f ~/.bash_aliases ]; then
But what about interactive login shells? Instead of
.bashrc, login shells source
.bash_login exists, then it gets sourced instead.
.bash_profile exists, then it gets sourced instead.
However, the good news is that by default in Ubuntu, commands in
.bashrc will also run in interactive login shells because the default
.profile checks if the current shell is bash (and if
.bashrc exists), and if so, sources
# if running bash
if [ -n "$BASH_VERSION" ]; then
# include .bashrc if it exists
if [ -f "$HOME/.bashrc" ]; then
I suggest users define new bash aliases in
.bash_aliases in their home directories (creating it if it doesn't already exist). This is a particularly clean and simple way to make alias definitions permanent at the per-user level.
Aliases should not be defined in
.profile because they would remain undefined in non-login shells. Unlike much of a bash shell's environment, aliases are not exported to child shells:
ek@Io:~$ alias hi='echo "Greetings, $USER!"'
hi: command not found
In particular, by default most desktop environments cause
.profile to be sourced on graphical login, but:
- This is not necessarily done by a bash shell, so alias definitions may not even be processed, and more importantly
- even if alias definitions are processed, they are not passed on to child processes. Particularly, they are not passed on to shells created by opening a Terminal window!
Aliases should not be defined in
.bash_login) for the very same reason, but also for another reason. Naively creating one of these files and putting just alias definitions in it prevents any of the code in
.profile from running!
In situations where
.bash_login really is useful, typically one sources
.profile somewhere in them, which solves that problem. (Then the only remaining problem is that, like with
.profile, defining aliases in
.bash_login doesn't work right.)
Aliases for New Individual Users, Automatically
When a user account of the type intended to represent a real human being is created, a new directory is typically made to serve as their home directory. The contents of
/etc/skel are then copied to their home directory. This is how multiple users start out with some similar configuration files in their home directories. In Ubuntu, this includes
.bashrc, and some other files.
To change what aliases are defined for new users, you can simply put them in
/etc/skel/.bash_aliases (you will have to create it) or
If you edit an already-existing file in
/etc/skel you may want to back it up first--but you shouldn't put the backup in
/etc/skel, or it, too, will be copied into new users' home directories.
This is likely the best way for you to add new aliases for multiple users. Existing users can simply add the aliases themselves. If you define the aliases in
/etc/skel/.bash_aliases, you can simply direct them to that file, which they may choose to copy into their home directories (or add into their own custom
It's trivial for a user to undefine an alias. Additionally, aliases are not extremely robust; they work only in particular circumstances. If you need to create a new command that works all the time, for everyone, you should not implement that command as an alias. And you cannot successfully force aliases on users who don't want them--they can simply
Global Aliases, for All Users
Though I advise you to avoid this approach, you can define aliases in the the global
/etc/bash.bashrc file. They will then be defined both for interactive non-login shells and for interactive login shells. The reason is, before any of the files in the user's home directory are sourced:
- Login shells (and only login shells and other processes behaving like login shells) run commands from
- Only non-login shells run commands in
/etc/bash.bashrc automatically, but
- Ubuntu's default
/etc/profile checks if the running shell is bash (and if
/etc/bash.bashrc exists) and, if so, sources
This is analogous to how the default per-user
.profile sources the per-user
.bashrc if the shell is bash (as detailed above).
Here's what the actual code for this looks like in the default
if [ "$PS1" ]; then
if [ "$BASH" ] && [ "$BASH" != "/bin/sh" ]; then
# The file bash.bashrc already sets the default PS1.
# PS1='\h:\w\$ '
if [ -f /etc/bash.bashrc ]; then
if [ "`id -u`" -eq 0 ]; then
That block also performs other tasks. Specifically, the outer
if checks if the shell is likely to be interactive (by checking that the prompt text is non-empty), then checks if the current shell is bash and sources
/etc/bash.bashrc if it is, and if not does some work that, for bash, is already done in
You should not define global aliases in
/etc/profile for the same reason users should not define them in their local
.profiles: if you do, they will be defined only for login shells, and not for their child shells.
Finally, note that, unlike the default per-user
.bashrc, the default
/etc/bash.bashrc file does not contain anything about aliases. It is somewhat unusual to give users aliases in a file where they cannot edit or disable them. (Of course, they still can do that, by overriding their definitions in their own local
.bash_aliases, or elsewhere.)