$ PATH is one of the silent manipulators in the background of your Linux computer. It quietly affects your user experience, but there is nothing gray about it. We will explain what it does and how you can adjust it.
What is $ PATH on Linux and how does it work?
When you type a command in a terminal window and press Enter, you start a lot of activities before your command is even executed.
Hit is the default shell on most Linux distributions. It interprets the line of text you entered and identifies the command names interspersed with the parameters, pipes, redirectsand anything else. It then locates the executable files for these commands and launches them with the parameters you provided.
The first step the shell takes to locate the executable is to identify if a binary is even involved. If the command you are using is in the shell itself (a “Integrated shell”) No further research is required.
Internal shell commands are the easiest to find because they are part of the shell. It’s like having them in a tool belt – they’re always with you.
If you need one of your other tools, you have to search the workshop to find it. Is it on your workbench or on a wall mount? This is what the $ PATH environment variable does. It contains a list of where the shell searches and the order in which they will be searched.
If you want to see if an order is a built-in shell, alias, function or standalone binary mv / work / unfile, you can use the type command as shown below:
This tells us that clear is a binary file, and the first one found in the path is in / usr / bin. You may have more than one version of clear installed on your computer, but that is the one the shell will try to use.
Unsurprisingly, cd is a built-in shell.
Display your $ PATH
It’s easy to see what’s on your way. Just type the following to use the echo command and print the value held in variable $ PATH:
echo $ PATH
The result is a list of file system locations delimited by a colon (:). The shell searches from left to right across the path, checking each location in the file system for a corresponding executable to execute your command.
We can choose our path through the list to see the file system locations that will be searched and the order in which they will be searched:
/ usr / local / sbin
/ usr / local / bin
/ usr / sbin
/ usr / bin
/ usr / games
/ usr / local / games
/ snap / bin
Something that may not be immediately obvious is that the search does not start in the current working directory. Rather, it makes its way through the listed directories and only the listed directories.
If the current working directory is not on your way, it will not be searched. Also, if you have commands stored in directories that are not in the path, the shell will not find them.
To demonstrate this, we created a small program called rf. Once executed, rf displays the name of the directory from which it was launched in the terminal window. It is located in / usr / local / bin. We also have a newer version in the / dave / work directory.
We type the following command to show us which version of our program the shell will find and use:
The shell reports that the version found is that of the directory located in the path.
We type the following to trigger it:
Version 1.0 of RF is running and confirms that our expectations were correct. The version found and executed is located in / usr / local / bin.
To run any other version of rf on this computer, we must use the path to the executable on the command line, as shown below:
Now that we’ve told the shell where to find the version of rf we want to run, it’s using version 1.1. If we prefer this version, we can copy it to the / usr / local / bin directory and overwrite the old one.
Suppose we are developing a new version of RF. We will have to run it frequently as we develop and test it, but we don’t want to copy a brand new development version to the live environment.
Or, we may have downloaded a new version of rf and want to do some verification testing on it before we make it public.
If we add our working directory to the path, we make the shell find our version. And this change will only affect us – others will still use the rf version in / usr / local / bin.
Adding a directory to your $ PATH
You can use the export command to add directory at $ PATH. The directory is then included in the list of file system locations that the shell searches for. When the shell finds a matching executable, it stops searching, so you need to make sure it searches in your directory first, before / usr / local / bin.
This is easy to do. For our example, we type the following to add our directory at the start of the path so that it is the first location sought:
export PATH = / home / dave / work: $ PATH
This command sets $ PATH to be equal to the directory we add, / home / dave / work, and then to the entire current path.
The first PATH has no dollar sign ($). We define the value of PATH. The last $ PATH has a dollar sign because we are referencing the content stored in the PATH variable. Also note the colon (:) between the new directory and the $ PATH variable name.
Now let’s see what the path looks like:
echo $ PATH
Our / home / dave / work directory is added at the start of the path. The colon we provided separates it from the rest of the way.
We type the following to verify that our version of rf is the first one found:
The proof in the pudding is running rf, as shown below:
The shell finds version 1.1 and runs it from / home / dave / work.
To add our directory at the end of the path, just move it to the end of the command, like this:
export PATH = $ PATH: / home / dave / work
Make changes permanent
As Beth Brooke-Marciniak said: “Success is good, but success is fleeting.” By the time you close the terminal window, any changes you made to the $ PATH are gone. To make them permanent, you must place your export order in a configuration file.
When you place the export command in your .bashrc file, it sets the path each time you open a terminal window. contrary to SSH sessions, for which you have to log in, they are called “interactive” sessions.
Previously, you put the export command in your .profile file to define the path to terminal sessions.
However, we have found that if we place the export command in the .bashrc or .profile files, it correctly sets the path for the interactive terminal and login sessions. Your experience may be different. To manage all eventualities, we will show you how to proceed in the two files.
Use the following command in your / home directory to modify the .bashrc file:
the gedit editor opens with the loaded .bashrc file.
Scroll to the bottom of the file, then add the following export command that we used previously:
export PATH = / home / dave / work: $ PATH
Save the file. Then close and reopen the terminal window or use the dot command to read the .bashrc file, as follows:
Then type the following echo command to check the path:
echo $ PATH
This adds the / home / dave / work directory to the start of the path.
The process for adding the command to the .profile file is the same. Type the following command:
The gedit editor starts with the loaded .profile file.
Add the export command to the bottom of the file, then save it. Closing and opening a new terminal window is insufficient to force the re-reading of the .profile file. For the new settings to take effect, you must log out and log in again, or use the point command as shown below:
Paving the way for everyone
To define the path for all those who use the system, you can modify the / etc / profile file.
You will need to use sudo, as follows:
sudo gedit / etc / profile
When the gedit editor starts, add the export command at the bottom of the file.
Save and close the file. The changes will take effect for others the next time they connect.
A note on security
Make sure you don’t accidentally add a colon “:” to the path, as shown below.
If you do, it will first search for the current directory, which poses a security risk. Suppose you downloaded an archive file and decompressed it to a directory. You look at the files and see another compressed file. You call decompress again to extract this archive.
If the first archive contained an executable file called decompress which was a malicious executable, you would accidentally trigger it instead of the real decompressed executable. This would happen because the shell would first look in the current directory.
So always be careful when entering export orders. Use echo $ PATH to review them and make sure they are the way you want them.