How to correctly add a path to PATH?
Solution 1
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.
Solution 2
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.)
Solution 3
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}}
...
Solution 4
I'm confused by question 2 (since removed from the question since it was due to an unrelated issue):
What's a workable way to append more paths on different lines? Initially I thought this could do the trick:
export PATH=$PATH:~/opt/bin export PATH=$PATH:~/opt/node/bin
but it doesn't because the second assignment doesn't only append
~/opt/node/bin
, but also the wholePATH
previously assigned.This is a possible workaround:
export PATH=$PATH:~/opt/bin:~/opt/node/bin
but for readability I'd prefer to have one assignment for one path.
If you say
PATH=~/opt/bin
that's all that will be in your PATH. PATH is just an environment variable, and if you want to add to the PATH, you have to rebuild the variable with exactly the contents you want. That is, what you give as an example to question 2 is exactly what you want to do, unless I'm totally missing the point of the question.
I use both forms in my code. I have a generic profile that I install on every machine I work on that looks like this, to accommodate for potentially-missing directories:
export PATH=/opt/bin:/usr/local/bin:/usr/contrib/bin:/bin:/usr/bin:/usr/sbin:/usr/bin/X11
# add optional items to the path
for bindir in $HOME/local/bin $HOME/bin; do
if [ -d $bindir ]; then
PATH=$PATH:${bindir}
fi
done
Solution 5
Linux determines the executable search path with the $PATH
environment variable. To add directory /data/myscripts to the beginning of the $PATH
environment variable, use the following:
PATH=/data/myscripts:$PATH
To add that directory to the end of the path, use the following command:
PATH=$PATH:/data/myscripts
But the preceding are not sufficient because when you set an environment variable inside a script, that change is effective only within the script. There are only two ways around this limitation:
- If within the script, you export the environment variable it is effective within any programs called by the script. Note that it is not effective within the program that called the script.
- If the program that calls the script does so by inclusion instead of calling, any environment changes in the script are effective within the calling program. Such inclusion can be done with the dot command or the source command.
Examples:
$HOME/myscript.sh
source $HOME/myscript.sh
Inclusion basically incorporates the "called" script in the "calling" script. It's like a #include in C. So it's effective inside the "calling" script or program. But of course, it's not effective in any programs or scripts called by the calling program. To make it effective all the way down the call chain, you must follow the setting of the environment variable with an export command.
As an example, the bash shell program incorporates the contents of file .bash_profile by inclusion. Place the following 2 lines in .bash_profile:
PATH=$PATH:/data/myscripts
export PATH
effectively puts those 2 lines of code in the bash program. So within bash, the $PATH variable includes $HOME/myscript.sh
, and because of the export statement, any programs called by bash have the altered $PATH
variable. And because any programs you run from a bash prompt are called by bash, the new path is in force for anything you run from the bash prompt.
The bottom line is that to add a new directory to the path, you must append or prepend the directory to the $PATH environment variable within a script included in the shell, and you must export the $PATH
environment variable.
More information here
Related videos on Youtube
Paolo
Please forgive my ignorance. Self reminders I'm here to learn. Learning is an experience, everything else is just information. (A.Einstein)
Updated on September 18, 2022Comments
-
Paolo over 1 year
I'm wondering where a new path has to be added to the
PATH
environment variable. I know this can be accomplished by editing.bashrc
(for example), but it's not clear how to do this.This way:
export PATH=~/opt/bin:$PATH
or this?
export PATH=$PATH:~/opt/bin
-
Microsoft Linux TM over 9 yearsprintf '\nPATH=$PATH:"path-to-add"\nexport PATH\n' >> ~/.bashrc
-
Sildoreth about 9 years
-
Sandeepan Nath over 7 yearsIf there are already some paths added, e.g.
PATH=$PATH:$HOME/.local/bin:$HOME/bin
, another can be added by separating with a : e.g.PATH=$PATH:$HOME/.local/bin:$HOME/bin:/home/ec2-user/pear/bin
. -
Ungeheuer over 7 yearsDo these answers work for all flavors of linux?
-
Scott - Слава Україні almost 5 yearsRelated: Add directory to $PATH if it's not already there (on Super User).
-
axolotl about 4 yearswrote a little utility to help with exactly this. github.com/aalok-sathe/pathin
-
-
Paolo over 12 yearsYou are right about the example of question 2, it works. Another PATH related issue on my system confused me. Sorry for that.
-
waltinator over 8 yearsor alias ls=myls
-
ThaNyneTray over 7 yearsBetter to add a file to the /etc/paths.d directory than to edit the /etc/paths file itself.
-
davidcondrey over 7 years-bash: awk: No such file or directory -bash: sed: No such file or directory
-
sancho.s ReinstateMonicaCellio over 6 years@davidcondrey - awk and sed are very common external commands. This answer provides a pure-bash way of achieving the same, so it works even in cases when awk and/or sed are not present (or their respective directories are not in the path!)
-
Priyanshu Dhal almost 5 yearsregarding relative paths: what about having a '-r' switch, which would add the path without making it absolute first, and which would also look for it as absolute before adding it? If this were script, one could use it in other shells. Is there any benefit of having it as a function? nice code!
-
cjs almost 5 years@hoijui It has to be a function because it's modifying the current environment. If it were a script, it would modify the environment of the subprocess running the script and, when the script exited you'd have the same
$PATH
as you had before. As for-r
, no, I think that relative paths in$PATH
are just too unreliable and weird (your path changes every time youcd
!) to want to support something like that in a general tool. -
priojeet priyom almost 5 yearsStill not able to understand the complication with export. can you please simplify it?
-
Gilles 'SO- stop being evil' almost 5 years@priojeetpriyom Simple explanation: you don't need
export
. -
Wildcard almost 5 yearsRelated and cleaner approach to check for presence of a directory in your PATH: unix.stackexchange.com/a/32054/135943
-
icc97 almost 5 yearsThank you for this answer, perfectly detailed. You say "You should not define environment variables in ~/.bashrc", but unfortunately 100% of the programs that I have installed on my system that modify the path (FZF and Rust's Cargo) modify the path in
.bashrc
. I assume because FZF is written in Rust too it's following the pattern of Rust. -
therobyouknow over 4 yearscould it also be
export PATH
... -
AndrewS over 3 years
${PATH:+:${PATH}}
is confusing because the first:
is part of the syntax and the second:
is the list delimiter. -
sancho.s ReinstateMonicaCellio over 3 yearsWell, I guess you will have to get used to it.
-
AndrewS over 3 yearsI've found it useful to add to this a check that the path exists as well, and silently ignore the call if it doesn't.
-
Brett Ryan over 3 yearsThat check is already present @RogerDahl , the use of
-d
-
Tom Russell over 3 yearsWhat about when the element being added to $PATH is an environment variable set inside ~/.bashrc?
-
Tom Russell about 3 years
:
is context-sensitive. It's a rudimentary form of AI. :-) -
sancho.s ReinstateMonicaCellio about 3 yearsAs detailed here, this basic form of adding to path should likely be replaced by a more robust version.
-
G-Man Says 'Reinstate Monica' about 2 years(1)
echo $PATH
can mess up if$PATH
contains field separators or glob characters. Yeah, sure, you ‘‘shouldn’t’’ create directories with field separators or glob characters in their names, but why not handle that case correctly, when it’s so easy to do? (2) Why the silent failure if the directory doesn’t exist? If you typepathadd "/opt/newprogran/bin"
and thennewprogram
, and you get a “command not found” error, how long will you scratch your head before you notice that you misspelled the directory in thepathadd
command? … (Cont’d) -
G-Man Says 'Reinstate Monica' about 2 years(Cont’d) … (3) Your
pathrm
will fail if the argument contains;
. Again, you ‘‘shouldn’t’’ create directories with semicolons in their names, but you should try harder to handle it (or at least document it as a weakness of your code). (4) And;::;:;
is fun to read … NOT! (5) Yourpathrm
also fails silently if you mistype the argument. -
iconoclast about 2 years@TomRussell: you shouldn't be setting your environment variables in .bashrc, since that is specifically for interactive shells and you want your variables available to non-interactive shells too.
-
iconoclast about 2 years@G-ManSays'ReinstateMonica': why won't the
[ -d "$1" ]
catch the case of a non-existent directory? I haven't tested the code (because I have more own function which I prefer) but it seems like it should.... -
G-Man Says 'Reinstate Monica' about 2 years@iconoclast: We’re not understanding each other. Including: I don’t understand your question. But I guess your question is founded on a misunderstanding of what I said. To clarify,
[ -d "$1" ]
certainly will fail (i.e., evaluate to false) if the directory doesn’t exist. But look at the big picture:if [ -d "$1" ] … ; then
(add to PATH)
fi
— there’s noelse
clause. If the directory doesn’t exist, the function will not change thePATH
— but it won’t issue an error message, so the user doesn’t know that it failed, and doesn’t understand why their program is “not found”. -
iconoclast about 2 yearsahhh, I see what you mean... "fail silently" from the point of view of the person issuing the command at the moment, even though it succeeds at ignoring non-existent directories (and therefore succeeds from the original programmer's point of view)
-
Admin almost 2 years
-
Admin almost 2 yearsI'm on macOS in 2022, and the default shell is zsh. I put the path in
.profile
as suggested in this answer, but that didn't actually work, so I had to put it in.zprofile
instead.