Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

On UNIX-like systems over the years (most relevantly to me, Linux), I've noticed that . (current dir) is never in the $PATH by default. Why is this? I recall reading years ago that it was a security problem, but the article I read didn't explain what exactly the problem was. Is it because someone could leave a malicious version of 'ls' or 'cp' in a directory, and I'd end up running it without realizing it was there?

share|improve this question
4  
It isn't as much for interactive user protection as it is for other programs (and scripts) that run other programs. Even some savvy users like knowing that when they are in a random directory that ls will be /usr/bin/ls and ./ls isn't. There is also the hurdle of if you know how to add . to the end of your path, you probably have some idea what you are doing. root should never have . in the path, many systems don't even let root log in anymore. –  msw Jun 25 '10 at 6:47
add comment

3 Answers

up vote 22 down vote accepted

You answered correctly your own question, that's exactly why dot isn't in the path:
To protect against childish viruses or honest mistakes.

Of course, this is a very lame and useless anti-virus measure, and nothing stops you from adding dot to the path yourself.

share|improve this answer
6  
It's funny, though, that you're protected from this but not from a lone file -rf in the directory (makes rm * interesting) ;-) –  Joey Jun 25 '10 at 6:10
    
The Unix answer: why did you name a file -rf in the first place? ;) –  msw Jun 25 '10 at 8:06
1  
@msw: Another Unix answer is that normally dot in the path is frowned upon for admin accounts, but is ok for non-admin. –  harrymc Jun 25 '10 at 9:47
add comment

Yes. If you put the "." in the path, you would end up sending a lot of command calls to the files in your current directory.

Even if it was last, there is still pilot error. For example, Solaris 10 lacks "top". I type "top" on my system all day long, because I think I'm on a system that has "top".

share|improve this answer
add comment

Sorry, I'd like to ask this in the form of a comment to the selected answer, but I don't have any rep on superuser yet.

The security answer makes sense, but if you put "." in your PATH as the last thing, shouldn't the shell look in the current directory last as it searches for executables, and thus reduce the security risk? If it did search $PATH in order, it would find /bin/ls before it found ./ls.

So, how insecure is it for me to put "." at the end of my $PATH environment variable?

It works as I suggest. Here's how I tested:

First, add "." to the END of your PATH environment variable.

Then, put the following file in some directory, such as ~/dir1/dir2/test_which.rb:

#!/your/path/to/ruby

puts "this file is from the current directory"

And put this file at /usr/bin/test_which.rb

#!/your/path/to/ruby

puts "this file is at /usr/bin/test_which.rb"

Be sure to chmod +x the files so that they're executable.

Now, if you change directory to ~/dir1/dir2, and execute test_which.rb, you'll get the output

this file is at /usr/bin/test_which.rb

Indeed, if you run "which test_which.rb" from anywhere, it should report

/usr/bin/test_which.rb

You can still execute the file in the current directory by typing:

./test_which.rb
share|improve this answer
6  
Nobody ever made a typo, such as dc or sl or sduo in a shell, and was saved by "command not found". Ever. –  Daniel Beck Nov 11 '10 at 23:35
1  
Agree with Daniel: you could have a malicious script named after a misspelled command. See also this answer. –  ignis Jan 25 '13 at 4:54
    
@DanielBeck you should try to use alias for mistypings. I have my preferred configuration of ls (colour output and more) aliased to l which dispenses entirely with typos. –  Karl Damgaard Asmussen Jul 17 '13 at 20:02
    
@KarlDamgaardAsmussen kl –  deworde Jul 18 '13 at 8:02
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.