PATH under Linux: adding a command without breaking your shell

You have just installed a Linux tool, you type its command, and the shell responds command not foundIn many cases, the tool is indeed present. It is simply stored in a folder that your variable PATH does not travel.

I advise you to handle this properly. Adding a folder to the PATH can fix things in thirty seconds, but a bad line in .bashrcA dubious folder placed at the top, or a duplicated PATH every time the terminal is opened, can quickly make the session unpleasant.

We’ll see how to read your PATH, test a temporary addition, and make it permanent with .bashrc Or .profile, then verify that the correct command is called.

Start by looking at the current PATH

The PATH is a list of folders separated by colons. When you type a command, the shell searches these folders, in order.

echo "$PATH"

The output is often long. To read it more easily, display one folder per line:

OLDIFS=$IFS
IFS=:
for dir in $PATH; do
  echo "$dir"
done
IFS=$OLDIFS

On a standard computer, you will find folders like /usr/local/bin, /usr/bin, /bin, Sometimes $HOME/.local/binIf the folder containing your script does not appear, the shell will not find it without the full path.

Before making any changes, also check where the command is located:

command -v mytool
type -a mytool

command -v indicates the path actually used. type -a This is useful when several commands have the same name. It’s exactly the kind of check that prevents you from unknowingly running an old binary.

Add a folder to the PATH for the session only

To test without breaking anything, first add the folder only to the current terminal. For example, if you place your small scripts in ~/.local/bin :

mkdir -p "$HOME/.local/bin"
export PATH="$HOME/.local/bin:$PATH"

The folder is located at the beginning of the PATH. Your shell will therefore consult it before /usr/bin Or /binThis is useful for testing a personal script, but it is not a neutral detail: if a command has the same name as a system tool, it is your version that will be called.

Check it out right now:

echo "$PATH"
command -v mytool

If your script is in this folder but won’t run, also check the execution permissions:

ls -l "$HOME/.local/bin/mytool"
chmod +x "$HOME/.local/bin/mytool"

If you need to review permissions on multiple files, see the article on recursive chmod under Linux This can prevent you from using an overly broad command. Here, we simply grant execute permissions to the file in question.

Make the addition persistent in .bashrc

If the test works, you can make the addition permanent. For an interactive Bash terminal, the most common file is ~/.bashrc.

nano ~/.bashrc

Add this logic to the bottom of the file:

case ":$PATH:" in
  *":$HOME/.local/bin:"*) ;;
  *) export PATH="$HOME/.local/bin:$PATH" ;;
esac

This version avoids re-injecting the same folder with each load. It’s cleaner than a simple export PATH="$HOME/.local/bin:$PATH" repeated in several files.

Then reload the file without closing your session:

source ~/.bashrc

Also open a new terminal to confirm that the addition is indeed returning automatically:

OLDIFS=$IFS
IFS=:
for dir in $PATH; do
  echo "$dir"
done
IFS=$OLDIFS
command -v mytool

.bashrc, .profile or /etc/profile.d: which one to choose?

The right file depends on your use case. On a workstation or server where you mainly open interactive Bash shells, ~/.bashrc is often enough.

For a login session, especially when you want the variable to be more widely available after login, look instead at ~/.profileSome distributions already add to this. $HOME/bin Or $HOME/.local/bin if the file exists.

For a system configuration intended for all users, avoid piling changes into each account. Instead, use a dedicated file in /etc/profile.d/with caution:

sudo nano /etc/profile.d/local-tools.sh

Simple example for an administered file:

export PATH="/opt/tools/bin:$PATH"

I reserve this type of addition for controlled paths with specific permissions. If any user can write to the folder, it shouldn’t be at the top of the global PATH. The Bash documentation lists the variables used by the shell, and the page PATH from the Bash manual recalls the role of this variable.

Avoid dangerous paths at the head of the PATH

The classic pitfall is adding a useful but overly broad folder. For example, putting . In the PATH, it is possible to launch a command from the current directory without writing ./scriptI advise against it.

Imagine a download folder that contains a fake ls, ssh Or sudoIf the current directory takes precedence over system paths, you might launch the wrong program without realizing it. On a server, this is a bad habit to avoid.

A few simple rules:

• do not put . in the PATH;
• avoid folders where other users can write;
• place the personal scripts in $HOME/.local/bin rather than in a download folder;
• check with type -a if an order exists in multiple places;
• Keep the classic system paths in the PATH.

The page approximately(7) It also details the role of environment variables on the Linux side. While not essential reading for adding a personal script, it helps in understanding what is passed to processes.

Verify that the shell is using the correct command

After making the modification, don’t just ensure the command runs. Verify its exact path:

command -v mytool
type -a mytool

If you have just moved or replaced a command, Bash may also keep a cached version of the old path. In this case:

hash -r
command -v mytool

You can then run a version or help command, if the tool offers one:

montool --version
mytool --help

If you are looking for the exact file before deciding where to store it, you can also use find on LinuxThis is often cleaner than randomly modifying the PATH to compensate for a misplaced file.

My own method for adding a personal command

On a personal machine or a small server, I generally keep it simple:

• I place my scripts in $HOME/.local/bin ;
• I only grant execution rights to the necessary files;
• I add the folder to ~/.bashrc with an anti-duplicate test;
• I check with command -v And type -a ;
• I keep system paths and sensitive folders under control.

If you manage multiple accounts or a shared server, be more rigorous. A poorly designed global PATH can produce behaviors that are difficult to diagnose, especially when a script works over SSH but not in an interactive session, or vice versa. In this case, document the added path and test with a new user before considering the change valid.

sudo apt update && sudo apt upgrade