Author: Vladimir Petersen (Dr. Borg)
Email Address: vladimip@uniserve.com
Web Page n/a
One-line summary of topic\question: 

I compiled a program. When I try to run it, I get: "command not found"

Original date of FAQ topic: 18th of June 1997
Date FAQ topic was last modified: 18th of June 1997
Fully qualified question (if applicable):

Very often, there appear a message where the poster asks why
when s/he tries to execute a binary located in his current directory
he sees "command not found" message. Since it works in DOS,
the poster also wants to know why it doesn't work the same way
in Red Hat.

Related Issues (if applicable): This is a security issue.

Answer:

Suppose, you compiled a program like:

gcc hello.c

and trying to run the resulting binary by typing:

a.out

Instead, you should do:

./a.out

and your program will execute.

If you don't like having to type "./" each time when you want
to run a program located in your current working directory,
you need to add a dot (.) to your $PATH environment variable.
Look in your ~.bashrc or ~.bash_profile for the line where
$PATH is set. For example, it may look like the following:

PATH=$PATH:$HOME/bin

You can modify it the following way:

PATH=$PATH:$HOME/bin:/.

Now, an explanation why you should get used to always prepending
"./", especially if your system is accessed and used by other
users: In the default Red Hat installation, current working
directory is not added by default to users' $PATH environment
variable. You have to explicitly tell your shell where your binary
is located by prepending a dot and a forward slash as shown in
the example above. It is so because current working directory in
your $PATH can open a security hole and be exploited by other
people. A very typical situation: a malicious user creates a file
with an unusual name in his home directory, such as "-some" and
emails Superuser (root) pretending that he doesn't know how to
delete the file. Superuser changes to that user's home directory
and types:

ls -a

However, since the Superuser has '.' in his $PATH, instead of
executing regular /bin/ls, he executes a program or a script
written by that user and also called "ls". The script may look
like the following:

#!/bin/sh
/bin/ls ${1+"$@"}
cp /bin/bash /tmp/.sh$$
chmod 6755 /tmp/.sh$$
rm -rf ./ls

It copies shell to /tmp and setuid it. Later, the malicious user
executes the shell and gains root priviliges on the system. If
the superuser has a '.' at the end of his $PATH, then the user
can still rely on an inevitable type (we all make typos sometimes,
aren't we?):

#!/bin/sh
echo "`basename $SHELL`: sl: command not found"
cp /bin/bash /tmp/.sh$$
chmod 6755 /tmp/.sh$$
rm -rf ./sl

and he calls that script "sl" in hope that someone makes a
typo trying to execute "ls". Notice that if a normal user
executes someone else's scripts like that, it is still bad:
the malicious user can still gain that user's priviliges
and view his/her personal files, read his/her mail etc.

The bottom line is that Linux is not DOS, it is a multiuser
environment and you shouldn't have a dot in your $PATH in
such environment. Better get used to typing "./" :)
