The basic concept to grasp here is that PATH can be defined in many places. As @demure explains in his answer, PATH=$PATH:/new/dir
means add /new_dir
to $PATH
, it will not clear the original $PATH
.
Now, one reason there are many files is intimately connected with the concept of login
and non-login
shells. See here for a nice summary. The following is from the bash man page (emphasis mine):
When bash is invoked as an interactive login shell, or as a
non-interactive shell with the --login option, it first reads and
executes commands from the file /etc/profile, if that file exists.
After reading that file, it looks for ~/.bash_profile,
~/.bash_login, and ~/.profile, in that order, and reads and executes
commands from the first one that exists and is readable. The
--noprofile option may be used when the shell is started to inhibit this behavior.
When you first log into your system, you start a login shell so bash will read the files listed above. Most distributions set a system-wide $PATH
(which applies to all users) at /etc/profile
and this is where you should make any changes that you want applied to all users. This is what I have on my Debian:
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
Once you have logged in, when you open a terminal you start an interactive, non-login shell. This is what man bash
has to say about those:
When an interactive shell that is not a login shell
is started, bash reads and executes commands from
/etc/bash.bashrc and ~/.bashrc, if these files exist.
So, those files are read every time you open a new terminal. Your filnal $PATH is the combination of the values in all files. In a typical situation, you log in using a graphical log in manager and start a new session. At this pòint your $PATH
is whatever was defined in the various profile
files. If you open a terminal, then you are in an interactive shell and the different bashrc
files are read which may append things to the $PATH
.
To summarize, all you really need to know is that you can make changes to your user's $PATH
by editing $HOME/.profile
.
Adding a directory to PATH
only makes the executables in this directory available as bare command names. This does not extend to subdirectories.
You can put a loop in your .profile
(not .bashrc
) to add multiple directories, for example:
for d in ~/tools/*/bin; do
PATH="$PATH:$d"
done
(You don't need to repeat export
: when a variable is exported, it stays exported, and modifications are reflected in the environment).
If you create new directories under tools
, this will not be reflected in your ongoing session, only the next time .profile
is read. If this is not satisfactory, you can use a different approach: put a single directory such as ~/bin
in your PATH, and when you install software, create symbolic links in ~/bin
. Stow (or its alternative XStow) is a good way of doing this; see Keeping track of programs for an overview of how this works.
Best Answer
The simple stuff
or
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 putexport
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 asPATH
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 thatPATH
is non-empty and exported: ifPATH
is still unset, then something likePATH=$PATH:/some/directory
would setPATH
to:/some/directory
, and the empty component at the beginning means the current directory (like.:/some/directory
).Notes on shells other than bash
In bash, ksh and zsh,
export
is special syntax, and bothPATH=~/opt/bin:$PATH
andexport 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,
setsexport PATH=~/opt/bin:$PATH
PATH
to the literal string~/opt/bin/:
followed by the value ofPATH
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 useexport
in a portable script, you need to writeexport PATH="$HOME/opt/bin:$PATH"
, orPATH=~/opt/bin:$PATH; export PATH
(orPATH=$HOME/opt/bin:$PATH; export PATH
for portability to even the Bourne shell that didn't acceptexport 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.