Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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
share|improve this question
printf '\nPATH=$PATH:"path-to-add"\nexport PATH\n' >> ~/.bashrc – Student Nov 7 '14 at 13:04
up vote 420 down vote accepted

The simple stuff


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.

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

If your PATH gets built in a 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.

Where to put it

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?

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:

So in shells like dash, export PATH=~/opt/bin:$PATH sets 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".

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

share|improve this answer
In exactly which shell does export var=~ not get expanded? Certainly this is not the case in bash which is the specifically tagged shell in the question. – mikeserv Jun 23 '14 at 1:29
Something to add is that if PATH is empty (unlikely, but it could happen), then PATH=some/path:$PATH will add the current directory to the PATH, which could potentially be exploited by an attacker. – aragilar Mar 17 '15 at 11:55
@Tim In an assignment, the quotes are optional. (They are necessary in some shells with export VAR=…, but never with a plain VAR=….) See unix.stackexchange.com/questions/68694/… for the gory details. You might want to always use quotes just to avoid remembering when they're necessary and when they aren't. – Gilles Apr 6 '15 at 21:48
@Naveen I have no idea what you're asking. Will what work and what “file system folder” are you talking about? Normally you can't edit files in /etc unless you're the administrator, but you can edit files in your home directory. – Gilles Aug 26 '15 at 18:50
@Startec A mistake, possibly due to joining two lines in a bad way. It doesn't hurt anything except performance in the case when an executable is not found. – Gilles Sep 25 '15 at 8:05

Either way works, but they don't do the same thing: the elements of PATHare 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.)

share|improve this answer
But if you want to have your own, customized version of ls, you need to put it in a directory ahead of /bin. – Barmar Sep 17 '15 at 20:20
or alias ls=myls – waltinator Sep 18 '15 at 1:27

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 whole PATH 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


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
share|improve this answer
You are right about the example of question 2, it works. Another PATH related issue on my system confused me. Sorry for that. – Paolo Dec 5 '11 at 0:59

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:


To add that directory to the end of the path, use the following command:


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.


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. So putting the following 2 lines in .bash_profile:

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

share|improve this answer

I can't speak for other distributions, but Ubuntu has a file, /etc/environment, that is the default search path for all users. Since my computer is only used by me, I put any directories that I want in my path there, unless it is a temporary addition that I put in a script.

share|improve this answer

Here is my solution: PATH=$(echo -n $PATH | awk -v RS=: -v ORS=: '!x[$0]++' | sed "s/\(.*\).\{1\}/\1/")

A nice easy one liner that does not leave a trailing :

share|improve this answer

For some time now I've kept with me two functions pathadd and pathrm that assist in adding elements to the path without the need to worry about duplications.

pathadd takes a single path argument and an optional after argument which if supplied will append to the PATH otherwise it prepends it.

In almost every situation if you're adding to the path then you're likely wanting to override anything already in the path, which is why I opt to prepend by default.

pathadd() {
    if [ -d "$1" ] && ! echo $PATH | grep -E -q "(^|:)$1($|:)" ; then
        if [ "$2" = "after" ] ; then

pathrm() {
    PATH="$(echo $PATH | sed -e "s;\(^\|:\)${1%/}\(:\|\$\);\1\2;g" -e 's;^:\|:$;;g' -e 's;::;:;g')"
share|improve this answer

For me (on Mac OS X 10.9.5), adding the path name (e.g. /mypathname) to the file /etc/paths worked very well.

Before editing, echo $PATH returns:


After editing /etc/paths and restarting the shell, the $PATH variable is appended with /pathname. Indeed, echo $PATH returns:


What happened is that /mypathname has been appended to the $PATH variable.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.