What's wrong with having '.' in your $PATH?

This is more of a tip than a warning. This answer was clearly written when *nix systems were largely multi-user systems. The security reasoning doesn't hold at all on personal computers - in fact I'm going to add "." to my PATH for sure now, hadn't ever considered it. (I'm pretty sure I don't leave malicious executables "lying around" my mac, and if I somehow did that'd be my own dumb fault).

Having . in your $PATH isn't a major security issue on its own. I'd classify it at S3. The problem with S3s though, is that two separate S3s can combine to create an S1 or an S0, which can bite you.<p>If you've had . in your PATH for a long time and never had a problem with it, it's either because there isn't anything else open that makes this an issue (fairly likely), or that no one's really bothered to exploit your system (also fairly likely)

I never considered having "." in my $PATH because typing "./" is very convenient in the us keyboard layout.

I avoid adding '.' to my path because I work on a lot of different linux and unix systems as part of my job, and having a consistent command line I can use without having to remember where I am and how I set things up is more productive for me than saving a bit of time on my personal system.<p>For the same reason I don't use a custom .vimrc file; it's great when on a configured system but causes problems elsewhere.

I had tried this, and had makefiles fail because of this. It seems that if you insist on saving $PATH this way, you should NOT to `export` it.

'Have had "." in my $PATH for 20 years. It's never been a problem... and probably saved me several hundred thousand keystrokes.<p>Having to worry about there being an "ls" in the current dir is about the same as worrying whether or not there are multiple versions of _any_ binary elsewhere in $PATH.<p>This is a non-issue.

Fun corollary to this, having an empty element in your $PATH (for example, "/foo::/bar") is the same as having '.' in your $PATH, at least under bash.<p>This will usually happen when a login script puts the value of a variable in your $PATH without actually checking whether that variable has any contents.

<i>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"</i><p>If you're a clumsy typist, even if you don't have '.' in your $PATH, you might still type ./sl (instead of your intended ./ls) and get the "rogue" program to run.<p>I've had . in my $PATH for the last couple of decades. It's fine.

Makes me think: the exploit he describes is the UNIX-predecessor of today's web's XSS attacks ...

I'm really surprised over the complete lack of thought shown by people who spend time writing about this.<p>The problem isn't really about having . in your path, but the old mistake of having it <i>AS THE FIRST THING</i> in your path, before your shell has a chance to reach its usual important locations (/bin, /sbin, /usr/bin, /usr/local/bin and so forth). Put it as the last thing in your path variable and you won't be having any problems worth mentioning (hey, even the OpenBSD guys finally went with this solution after having banished . entirely for years).