In Unix certain environment variables, such as $PATH
are special in the sense that they're a list of items, not just a single item. With these types of lists, a colon (:
) separates the items in the list.
For $PATH
you can see this if you merely print it:
$ printenv PATH
/sbin:/bin:/usr/sbin:/usr/bin
If you want to add additional items to this, you have to include the previous list plus the new item. That's effectively what you're doing when you say PATH=$PATH:<new item>
.
$ PATH=$PATH:/path/to/some/dir
$ printenv PATH
/sbin:/bin:/usr/sbin:/usr/bin:/path/to/some/dir
Keep in mind that these changes are local only to the shell where you ran them. If you want your changes to $PATH
to persist between reboots, or show up in other instances of your shell, you need to add them to a configuration file so that they'll get setup as part of your defaults.
Typically for user's this is what you'd do to these files ~/.bashrc
& ~/.bash_profile
:
export PATH=$PATH:$HOME/bin:$HOME/somedir
Adding a line such as this will modify your $PATH
.
Alternative to $PATH
usage
If you'd simply like to be able to run scripts and executables that are not in your $PATH
that can be easily solved by using this method instead of adding to $PATH
.
Here's a scenario, lets say we have an executable such as this:
$ ls -l helloexec.bash
-rwxr-xr-x 1 user1 user1 31 Aug 12 07:45 helloexec.bash
But it's not on the $PATH
so we cannot run it:
$ helloexec.bash
bash: helloexec.bash: command not found...
So you're thinking, oh, I have to add it to my $PATH
to be able to run it. But instead, you can run any executable that's in the current directory like so:
$ ./helloexec.bash
hello bash
In Unix type operating systems, it's imperative that you internalize this method of interacting with your scripts and executables, rather than insist that they all be on the $PATH
.
Dangers of adding to $PATH
In your examples you show that you'd like to add ~
to your $PATH
. I've seen many users do this over the years, or want to, thinking that it'll be a huge convenience & time saver to just put this directory, directly on their $PATH
.
This is typically not a good approach to things. Rather, you should think long and hard about where you want to store executables in Linux/Unix, and only add directories that are critically necessary to have such a prominent place such as being on $PATH
.
Most will typically add the system directories, and then add a $HOME/bin
to the $PATH
and leave it at that. Putting more things on the $PATH
can lead to unintended consequences such as commands not working as expected or even worse, creating a situation that allows a system to be more easily compromised.
For example, say you downloaded some script from a website, and hadn't realized that your web browser was changed to save files to $HOME
. This downloaded file, is now in a position that it can be invoked by a would be attacker.
Alternatively if you have the order of your $PATH
in such a state that ~
comes before other directories, such as something like this:
$ printenv PATH
/home/vagrant:/sbin:/bin:/usr/sbin:/usr/bin
And we accidentally downloaded an executable such as this:
$ cat ps
#!/bin/bash
/bin/ps -eaf | grep -v "spyware"
Now when someone runs ps
, they're using this version and not the intended /bin/ps
.
i=3
would not add to the original value ofi
. The same is true for strings when "add" means "append to". – Kusalananda Aug 12 '18 at 14:42