How to correctly add a path to PATH?
The simple stuff
PATH=$PATH:~/opt/bin
or
PATH=~/opt/bin:$PATH
depending on whether you want to add ~/opt/bin
at the end (to be searched after all other directories, in case there is a program by the same name in multiple directories) or at the beginning (to be searched before all other directories).
You can add multiple entries at the same time. PATH=$PATH:~/opt/bin:~/opt/node/bin
or variations on the ordering work just fine. Don't put export
at the beginning of the line as it has additional complications (see below under “Notes on shells other than bash”).
If your PATH
gets built by many different components, you might end up with duplicate entries. See How to add home directory path to be discovered by Unix which command? and Remove duplicate $PATH entries with awk command to avoid adding duplicates or remove them.
Some distributions automatically put ~/bin
in your PATH if it exists, by the way.
Where to put it
Put the line to modify PATH
in ~/.profile
, or in ~/.bash_profile
if that's what you have.
Note that ~/.bash_rc
is not read by any program, and ~/.bashrc
is the configuration file of interactive instances of bash. You should not define environment variables in ~/.bashrc
. The right place to define environment variables such as PATH
is ~/.profile
(or ~/.bash_profile
if you don't care about shells other than bash). See What's the difference between them and which one should I use?
Don't put it in /etc/environment
or ~/.pam_environment
: these are not shell files, you can't use substitutions like $PATH
in there. In these files, you can only override a variable, not add to it.
Potential complications in some system scripts
You don't need export
if the variable is already in the environment: any change of the value of the variable is reflected in the environment.¹ PATH
is pretty much always in the environment; all unix systems set it very early on (usually in the very first process, in fact).
At login time, you can rely on PATH
being already in the environment, and already containing some system directories. If you're writing a script that may be executed early while setting up some kind of virtual environment, you may need to ensure that PATH
is non-empty and exported: if PATH
is still unset, then something like PATH=$PATH:/some/directory
would set PATH
to :/some/directory
, and the empty component at the beginning means the current directory (like .:/some/directory
).
if [ -z "${PATH-}" ]; then export PATH=/usr/local/bin:/usr/bin:/bin; fi
Notes on shells other than bash
In bash, ksh and zsh, export
is special syntax, and both PATH=~/opt/bin:$PATH
and export PATH=~/opt/bin:$PATH
do the right thing even. In other Bourne/POSIX-style shells such as dash (which is /bin/sh
on many systems), export
is parsed as an ordinary command, which implies two differences:
~
is only parsed at the beginning of a word, except in assignments (see How to add home directory path to be discovered by Unix which command? for details);$PATH
outside double quotes breaks ifPATH
contains whitespace or\[*?
.
So in shells like dash, sets export PATH=~/opt/bin:$PATH
PATH
to the literal string ~/opt/bin/:
followed by the value of PATH
up to the first space.
PATH=~/opt/bin:$PATH
(a bare assignment) doesn't require quotes and does the right thing. If you want to use export
in a portable script, you need to write export PATH="$HOME/opt/bin:$PATH"
, or PATH=~/opt/bin:$PATH; export PATH
(or PATH=$HOME/opt/bin:$PATH; export PATH
for portability to even the Bourne shell that didn't accept export var=value
and didn't do tilde expansion).
¹ This wasn't true in Bourne shells (as in the actual Bourne shell, not modern POSIX-style shells), but you're highly unlikely to encounter such old shells these days.
Either way works, but they don't do the same thing: the elements of PATH
are checked left to right. In your first example, executables in ~/opt/bin
will have precedence over those installed, for example, in /usr/bin
, which may or may not be what you want.
In particular, from a safety point of view, it is dangerous to add paths to the front, because if someone can gain write access to your ~/opt/bin
, they can put, for example, a different ls
in there, which you'd then probably use instead of /bin/ls
without noticing. Now imagine the same for ssh
or your browser or choice... (The same goes triply for putting . in your path.)
The bullet-proof way of Appending/Prepending
Try not using
PATH=$PATH:~/opt/bin
or
PATH=~/opt/bin:$PATH
Why? There are a lot of considerations involved in the choice of appending versus prepending. Many of them are covered in other answers, so I will not repeat them here.
An important point is that, even if system scripts do not use this (I wonder why)*1,
the bullet-proof way to add a path (e.g., ~/opt/bin
) to the PATH environment variable is
PATH="${PATH:+${PATH}:}~/opt/bin"
for appending (instead of PATH="$PATH:~/opt/bin"
)
and
PATH="~/opt/bin${PATH:+:${PATH}}"
for prepending (instead of PATH="~/opt/bin:$PATH"
)
This avoids the spurious leading/trailing colon when $PATH
is initially empty, which can have undesired side effects and can become a nightmare, elusive to find (this answer briefly deals with the case the awk
-way).
Explanation (from Shell Parameter Expansion):
${parameter:+word}
If
parameter
is null or unset, nothing is substituted, otherwise the expansion ofword
is substituted.
Thus, ${PATH:+${PATH}:}
is expanded to:
- nothing, if
PATH
is null or unset, ${PATH}:
, ifPATH
is set.
Note: This is for bash.
*1 I have just found that scripts like `devtoolset-6/enable` actually use this,
$ cat /opt/rh/devtoolset-6/enable
# General environment variables
export PATH=/opt/rh/devtoolset-6/root/usr/bin${PATH:+:${PATH}}
...