8
When I compile e.g. x.c by:
GCC x.c -o x
To execute result I have to write:
./x
And just typing:
x
Fails with this message:
x: command not found
This means Linux does not search current directory for it! Is there (I'm sure there is) any reasonable issue behind this behaviour?
Yasser Zamani
Posted 2012-04-28T13:41:43.210
Reputation: 2 327
13
Because by default, the current working directory is not in the PATH variable.
This is a security/convenience measure. If you have binaries/scripts called e.g. cd, ls, etc. in your current working directory, it would be very annoying if they were run by default.
Oliver Charlesworth
Posted 2012-04-28T13:41:43.210
Reputation: 972
Thank you so much Oli. Now, I know why I should type two extra characters;) good design! – Yasser Zamani – 2012-04-28T13:52:58.340
4The answer is only partly correct. The problem could be surrounded if the current directory was only used as last option. Then standard tools would still be found first. – user unknown – 2012-04-28T16:05:59.830
1Also, shell builtins take precendence (i.e. when you type cd in bash, it executes a routine internal to bash and not /bin/cd) unless you prepend with .\ – LawrenceC – 2012-04-28T21:43:31.143
3One of the original *nix security measures, it forces system or admin compiled binaries that are in the system assigned path command to be executed. Nothing so bad as someone to log in as root on a help desk question, go to a user directory, type ls and find they loaded a bomb left by a user. – Fiasco Labs – 2012-04-28T22:03:13.317
7@userunknown: And the first time you typoed sl, you've got the same problem. Only trusted directories should be in $PATH and relative paths like . are never a trusted directory for an interactive shell. – None – 2012-04-28T22:35:04.773
@ultrasawblade: Bad example; cd is one of the few shell builtins that cannot be replaced by an external program. – None – 2012-04-28T22:40:00.117
@JoeWreschnig I take your point about typos but if you're building in typo protection to executing commands, why not do the same for rm -f vs rm -r? This seems like one of those things that makes people who like it feel safer, whereas those who don't just see it as an annoyance. – Basic – 2012-05-08T18:26:17.517
2@Basic: If I type rm -r target when I meant rm -f target there is usually no difference. If I type rm -f target when I meant rm -r target, either there's no difference or removal outright fails. Furthermore, I think every time before I type rm, especially if I'm adding -f or -r or a glob - it's a dangerous command by its nature. No one thinks before lsing. – None – 2012-05-08T18:30:16.253
1
It means that the current directory is not in the $PATH variable.
James
Posted 2012-04-28T13:41:43.210
Reputation: 119
1
You can fix this by adding the current directory (represented by a single dot) to the PATH environment variable.
The way to do it depends on the shell you are using.
if you are using bash, you can add the line export PATH=$PATH:. to the .bashrc file in your home directory.
if you are using csh or tcsh add the line
set PATH = ($PATH .) to the file .cshrc in your home directory.
IMHO, for a home desktop computer this is an acceptable thing to do - security wise.
kroiz
Posted 2012-04-28T13:41:43.210
Reputation: 223
I did not know we can add . to PATH, however, doing this will decrease security, right? – Yasser Zamani – 2012-04-29T06:04:51.800
Because it's the rules. – Daniel R Hicks – 2012-04-28T21:39:57.997
@DanH: Then explain "the rules" please. – Torben Gundtofte-Bruun – 2012-05-15T15:03:30.297