How to add a directory to the PATH?
help.ubuntu.com/community/EnvironmentVariables There is all you need to know. I found out that a lot of the input here was incorrect or at least the method was not suggested. This is a great piece of information that will let you figure out where to modify your environment variable based on the reason you are doing it and exactly how to do it without screwing everything up (like I did following some of the aforementioned bad advice). So long, and thanks for all the fish!
17 Answers 17
Using ~/.profile to set $PATH
A path set in .bash_profile will only be set in a bash login shell ( bash -l ). If you put your path in .profile it will be available to your complete desktop session. That means even metacity will use it.
if [ -d "$HOME/bin" ] ; then PATH="$PATH:$HOME/bin" fi Btw, you can check the PATH variable of a process by looking at its environment in /proc/[pid]/environ (replace [pid] with the number from ps axf ). E.g. use grep -z «^PATH» /proc/[pid]/environ
Note:
bash as a login shell doesn’t parse .profile if either .bash_profile or .bash_login exists. From man bash :
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.
See the answers below for information about .pam_environment , or .bashrc for interactive non-login shells, or set the value globally for all users by putting a script into /etc/profile.d/ or use /etc/X11/Xsession.d/ to affect the display managers session.
Cool, that worked. I saw where it will auto add the bin dir if I make it so I just used that instead of scripts. TY.
This piece of documentation is very well done: Official documentation about environment variable. Consider reading it (not to say that is updated to the last version of the rules to add values to environment variable).
I’ve still got no idea where to add my extra path part to. I need to add the android SDK to my path. PATH=»$HOME/bin:$PATH» So I add it to it?
Keep in mind .profile is used on login and thus you have to logout-login again for it to be used (closing and reopening the terminal is not enough). @JamieHutber the path is $WHERE_YOU_INSTALLED_THE_SDK/platform-tools and $WHERE_YOU_INSTALLED_THE_SDK/tools
Edit .bashrc in your home directory and add the following line:
You will need to source your .bashrc or logout/login (or restart the terminal) for the changes to take effect. To source your .bashrc , simply type
I was making the assumption that you were in your home directory. since that’s where the .bashrc you want to edit is.
.bashrc is not the right place for setting environment variables. They should go in .profile or .pam_environment . See mywiki.wooledge.org/DotFiles
The recommended place to define permanent, system-wide environment variables applying to all users is in:
(which is where the default PATH is defined)
This will work in desktop or console, gnome-terminal or TTY, rain or shine 😉
- To edit, open the terminal and type:
To make it work without rebooting, run . /etc/environment or source /etc/environment . Since this file is just a simple script it will run and assign the new path to the PATH environment variable. To check run env and see the PATH value in the listing.
This is exactly what I needed. Provisioning a throw-away vm image via vagrant and needed to add node and npm to the path.
To take changes in effect run . /etc/environement (yes, dot, a space and /etc/environment). Since this file is just a simple script it will run and assign the new path to the PATH environment variable. To check run env and see the PATH value in the listing.
@JohnnyAW: source is equivalent to the initial dot, see for example en.wikipedia.org/wiki/Source_(command).
I think the canonical way in Ubuntu is:
- create a new file under /etc/profile.d/
sudo vi /etc/profile.d/SCRIPT_NAME.sh export PATH="$PATH:YOUR_PATH_WITHOUT_TRAILING_SLASH" sudo chmod a+x /etc/profile.d/SCRIPT_NAME.sh It is usually safer to add your custom path to the end of PATH instead of the beginning. This avoids accidentally replacing system commands with your programs (or someone else’s malicious programs). This also avoids a lot of confusion when someone else works on your system (or gives you advice) and they get unexpected results from commands you have «replaced».
For complete newbies (like I am) who are more comfortable with GUI:
- Open your $HOME folder.
- Go to View → Show Hidden Files or press Ctrl + H .
- Right click on .profile and click on Open With Text Editor.
- Scroll to the bottom and add PATH=»$PATH:/my/path/foo» .
- Save.
- Log out and log back in to apply changes (let Ubuntu actually load .profile ).
Editing the .profile file is not recommended anymore.You can still use this method to edit the file .pam_environment see: help.ubuntu.com/community/EnvironmentVariables
Thank @PulsarBlow! I’m not really sure what’s exactly the difference and the benefit though. This is the direct URL to the relevant section: help.ubuntu.com/community/…
This answer caused my system to stop logging in due to all paths being overridden. Using Ubuntu 16.04.
@Frisbetarian you have to make sure to add the $PATH: bit which includes the existing PATH definition
For persistent environment variables available to particular users only. I highly recommend Ubuntu official documentation.
Referring to documentation above, I have setup my Android SDK path-tools by:
- creating ~/.pam_environment file in home directory.
- the content of which is PATH DEFAULT=$:~/android-sdk-linux/tools .
- additional custom user path can be added by separating paths with colon (:).
- this requires re-login, which means you need to log-out and log-in back to desktop environment.
Put that line in your ~/.bashrc file.
It gets sourced whenever you open a terminal
EDIT: Based on the comments below, for a more general setting that will apply to all shells (including when you hit Alt — F2 in Unity), add the line to your ~/.profile file. Probably shouldn’t do both however, as the path will be added twice to your PATH environment if you open a terminal.
Actually, I thought you set the path in either $HOME/.profile for personal settings, or /etc/profile for all users. But if it’s only needed for bash, I suppose either will work.
If you set it in ~/.bashrc , it’ll only be available in the terminals you open. E.g. if you hit Alt+F2 and try to run a command from that dir, it won’t find it. If you set it in ~/.profile or ~/.pam_environment , the gnome session (or whichever DE you use) will inherit it. Appending PATH in ~/.bashrc also has the drawback that if you open/exec bash interactively from another interactive bash shell, it’ll be appended multiple times.
I haven’t really looked into this for a while, so I did a search, and it seems that there are at least 95 different ways to set the path, most of which are discussed here. I never figured out which one is best. I think ~/.profile is correct for personal paths, though; that’s where Ubuntu adds the ~/bin directory. And I confess that I exaggerated a slight bit on the number of ways — just a little.
@MartyFried, yes, to quote the bot in #bash on freenode: «The overwhelming majority of bash scripts, code, tutorials, and guides on the Internet are crap. Sturgeon was an optimist.» Using google for bash problem, you’ll often find a lot of half-working solutions before you find a good one. Oh and I’d go with ~/.profile in this case too.
@geirha — I agree that most guides on the internet in general are probably crap, especially anything linux since different distros, or even different versions of the same one, do things differently. It usually boils down to what works, but most people don’t realize that what works is simply what works, not necessarily what’s right or even what will always work. I try to figure out which of the many ways is actually correct, because I hate doing things more than once — but it’s not always easy. 🙂
Adding it to .bashrc will work but I think the more traditional way of setting up your path variables is in .bash_profile by adding the following lines.
PATH=$PATH:/my/path/foo export PATH According to this thread it appears as though Ubuntu’s behavior is slightly different than RedHat and clones.
If you have .bashrc , stick it in .bashrc instead. GUI terminals in Ubuntu are not login shells, so .bash_profile will not be run.
I am not running a gui shell. But from the thread above it looks like the .bashrc will work just fine.
Both will work if your shell is a login shell. But I just tried the .bash_profile approach on one of my Ubuntu machines and even after restarting my gnome session it didn’t source my .bash_profile. So I would say that putting this in .bashrc is probably the way to go with Ubuntu.
@justingrif No, you don’t need .bash_profile . If bash doesn’t find a .bash_profile (when you log in interactively), it will look for .profile and use that instead. By default, you’ll have a .profile and .bashrc in Ubuntu. And .profile is the correct place to set environment variables if we disregard pam_env.
To set it system wide, append the line export PATH=/path/you’re/adding:$PATH to the end of /etc/profile .
To add the directory for only the logged-in user, append the same line to ~/.bash_profile .
In terminal, cd to the_directory_you_want_to_add_in_the_path
echo "export PATH=$(pwd):\$" >> ~/.bashrc This wasn’t my idea. I found this way to export path at this blog here.
sudo vi /etc/profile.d/SCRIPT_NAME.sh export PATH=YOUR_PATH_WITHOUT_TRAILING_SLASH:$PATH The recommended way to edit your PATH is from /etc/environment file
Example output of /etc/environment :
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games" For example, to add the new path of /home/username/mydir
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/username/mydir" System-wide environment variables
A suitable file for environment variable settings that affect the system as a whole (rather than just a particular user) is /etc/environment. An alternative is to create a file for the purpose in the /etc/profile.d directory.
/etc/environment
This file is specifically meant for system-wide environment variable settings. It is not a script file, but rather consists of assignment expressions, one per line.
Note: Variable expansion does not work in /etc/environment.
More info can be found here: EnvironmentVariables
What’s the purpose of $HOME/bin directory?
I have too little quality points to post it as a comment, so: @Terrance has answered the question but the following link adds to the ‘why so many’ part: lists.busybox.net/pipermail/busybox/2010-December/074114.html tldr; there is no need for so many. They are leftovers from hardware limitations from half a century ago.
2 Answers 2
The bin folders are used for executable programs.
Before Ubuntu 19.10 the folder of /bin itself was used for minimal functionality for the purposes of booting and repairing a system. The /usr/bin folder was used for most of the executable programs. Now /bin is symlinked to /usr/bin so they are now one and the same.
$ lsb_release -r Release: 20.04 $ ls -al / total 104 drwxr-xr-x 20 root root 4096 Apr 16 08:28 . drwxr-xr-x 20 root root 4096 Apr 16 08:28 .. lrwxrwxrwx 1 root root 7 Oct 2 2021 bin -> usr/bin $ lsb_release -r Release: 18.04 $ ls -al / total 1459924 drwxr-xr-x 24 root root 4096 Feb 24 07:36 . drwxr-xr-x 24 root root 4096 Feb 24 07:36 .. drwxr-xr-x 2 root root 4096 Feb 24 07:11 bin The /usr/local/bin is used for executable programs that are not managed by a distribution package.
The answer for your $HOME/bin folder is contained in the .profile in your home folder ( /home// ). It ( .profile ) is sourced automatically when you log in.
Contained in the .profile file in your home folder are the following sections (It is all about preference):
# set PATH so it includes user's private bin if it exists if [ -d "$HOME/bin" ] ; then PATH="$HOME/bin:$PATH" fi # set PATH so it includes user's private bin if it exists if [ -d "$HOME/.local/bin" ] ; then PATH="$HOME/.local/bin:$PATH" If either of those bin folders exist they are automatically added to the $PATH when the user logs into their account. It is used for the user’s own private executable programs and scripts. They are primarily used for the user or owner of those folders, keeping them private from other users.