Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Why do we use ./ before running a compiled code in linux? It does not seem to necessary if I am in a directory higher than the one having compiled code. Let me explain by example. If my code is in /home/uname/code, and I am also in the same directory, I have to use ./a.out. But if I am in /home/uname/ then I can use ./code/a.out. Here I am using ./ but I think it is more to navigate through the directories and not as an indication that it has to run a code. So why do I need to use ./ to run a compiled code if I am in same directory as the code?

share|improve this question
4  
Just because it doesn't seem that anyone has come out and said it directly - ./ doesn't mean run code. . is current directory, .. is parent directory. ./ is current directory, then slash for the directory separator. The program will only run if it is marked executable (chmod +x). –  Drake Clarris Mar 11 '13 at 18:46
add comment

3 Answers

up vote 4 down vote accepted

When you issue a command, your shell pulls a trick to make it seem like you can just call the command without specifying its full path. The shell looks for the command in each of the directories listed in the $PATH environment variable, and if it finds it, arranges for the command to be run.

If you want to run a command that is not in one of the directories in $PATH, you have to give the shell a hint where to find the file. In your example case, since /home/uname/code is not in $PATH, you need to give the shell enough path information to be able to find the file you want to execute. This is true whether your current working directory happens to be the directory where the file is located or in any other directory. If you happen to be in the same directory as the file you want to execute, the ./ before the filename is sufficient to tell the shell where to find the file.

share|improve this answer
1  
I am sorry I am probably asking you to repeat the same thing but can you please confirm that even if I am in the same directory as the compiled code I am trying to run, it still needs its path to be defined. I can understand necessity to define full path of a programme which is not in the $PATH as it does not know where it could be, but for a compiled code which is in the same directory from which the command is issued, there probably should not be any confusion and usernam@computername:~/code$ specifies the path anyway. –  kk_139 Mar 11 '13 at 17:28
2  
The shell looks in $PATH for commands you pass on the command line. If the current working directory is not in the $PATH, then the shell will never look in it to resolve a command name. The only way to persuade the shell to run a command in a directory not in $PATH is to provide it with enough path information to be able to locate the file. In the current directory, that is ./ The prompt is simply there as a convenience to you, and is not used by the shell to resolve unqualified command names. –  D_Bye Mar 11 '13 at 17:35
    
Ohh did not know about the prompt being there for convenience. Thankyou. –  kk_139 Mar 11 '13 at 17:46
1  
I should note that it's the presence of the slash that triggers a directory lookup instead of a PATH search. Any way you can insert a slash into the program's name is sufficient as long as it resolves to the correct program. –  Scott Severance Mar 14 '13 at 2:30
add comment

The input of the shell is always a path to an executable; either absolute or relative. This has to be composed of directory-path/filename. If you only specify an executable file name in your current directory the shell will automatically prefix that string you enter with each of the directories in the $PATH. That is why you always need to enter a path.

BTW, if your code is in /home/uname/code/ and you are in /home/uname/, you don't necessarily need to use

./code/a.out
you can also just use
code/a.out
because it is also a relative path.

share|improve this answer
add comment

If which can't find your executable, then your shell won't either.

which ./a.out works, as does which ./code/a.out - they print out the full path to the executable - but not which a.out.

As others have pointed out, it would work if you change your PATH environment variable before calling the relevant program.

e.g. In bash:

[uname@host:/home/uname/code]$ echo $PATH
/usr/bin:/bin
[uname@host:/home/uname/code]$ which a.out
which: no a.out in (/usr/bin:/bin)

[uname@host:/home/uname/code]$ which ./a.out
/home/uname/code/a.out

# add present directory to path
[uname@host:/home/uname/code]$ export PATH="${PWD}:${PATH}"

[uname@host:/home/uname/code]$ echo $PATH
/home/uname/code:/usr/bin:/bin

[uname@host:/home/uname/code]$ which a.out
/home/uname/code/a.out
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.