3
echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

echo $PATH 
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:.

What is the difference between the above two path variables?

I found that this executes the executable files like a command but I am not sure with this.

Stephen Kitt
  • 434,908
Hema Krish
  • 131

2 Answers2

8

Adding . to the path means that executable files in the current directory are considered by the shell, with the result that you no longer need to type ./ as a prefix. In your case, since it’s the last entry, such commands will only be executed if nothing else matches before hand; so for example, ls will still run /bin/ls.

There are a few reasons why this is typically not recommended (see the link above):

  • it can be bad for security, since someone can leave a binary in a directory you commonly visit and hope that you’ll run it accidentally — although this is less of a risk with . as the last entry rather than the first;
  • running a command in the current directory without ./ means that the first matching command in the path will be used, not necessarily the one in the current directory.
Stephen Kitt
  • 434,908
1

A bit of background: the PATH environment variable is a list of directories separated by colons. When you type a command name without giving an explicit path (e.g. you type "ls", rather than "/bin/ls") your shell searches each directory in the PATH list in order, looking for an executable file by that name, and the shell will run the first matching program it finds.

One of the directories in the PATH list can be the current directory "." . It is also permissible to use an empty directory name in the PATH list to indicate the current directory. Both of these are equivalent

for csh users:

    setenv PATH :/usr/ucb:/bin:/usr/bin
    setenv PATH .:/usr/ucb:/bin:/usr/bin

for sh or ksh users

    PATH=:/usr/ucb:/bin:/usr/bin export PATH
    PATH=.:/usr/ucb:/bin:/usr/bin export PATH

Having "." somewhere in the PATH is convenient - you can type "a.out" instead of "./a.out" to run programs in the current directory. But there's a catch.

Consider what happens in the case where "." is the first entry in the PATH. Suppose your current directory is a publically-writable one, such as "/tmp". If there just happens to be a program named "/tmp/ls" left there by some other user, and you type "ls" (intending, of course, to run the normal "/bin/ls" program), your shell will instead run "./ls", the other user's program. Needless to say, the results of running an unknown program like this might surprise you.

It's slightly better to have "." at the end of the PATH:

    setenv PATH /usr/ucb:/bin:/usr/bin:.

Now if you're in /tmp and you type "ls", the shell will search /usr/ucb, /bin and /usr/bin for a program named "ls" before it gets around to looking in ".", and there is less risk of inadvertently running some other user's "ls" program. This isn't 100% secure though - if you're a clumsy typist and some day type "sl -l" instead of "ls -l", you run the risk of running "./sl", if there is one. Some "clever" programmer could anticipate common typing mistakes and leave programs by those names scattered throughout public directories. Beware.

Many seasoned Unix users get by just fine without having "." in the PATH at all:

    setenv PATH /usr/ucb:/bin:/usr/bin

If you do this, you'll need to type "./program" instead of "program" to run programs in the current directory, but the increase in security is probably worth it.

MP Creations
  • 335