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).
To be more concrete, imagine another user places a malicious script into the file "/tmp/ls". If later someone else wants to look what temporary files are there, typing "cd /tmp" and then "ls", that person would suddenly execute the malicious script without even noticing. This is even worse if that happens to root, which is why this advice is especially important for the root user.
Also, note that for often-used self compiled binaries, $HOME/bin is a good place. On some systems, $HOME/bin is already added to the user's PATH by default, so you just have to create that directory and put your favorite binaries or shell scripts into that.
While the security issues does not seem as high in "modern" environments (mostly single user systems), I think it is still a significant risk because of the surprise factor.
For example, on my mac, there are > 2000 binaries available in my PATH. I cannot possibly know all of them, and if one binary uses another underlying binary I don't know about, it can be quite surprising. I don't think it worths it (using ./ + tab for completion is faster than typing the name of the binary anyway)
A lot of the classic Unix security advice is pretty outdated. For example the idea that someone getting "root" access is worse than someone gaining "ssp" access. Everything interesting is already readable and writable by ssp. The only new thing root can do is destroy stuff that can pretty easily be recreated.
The root account is still useful to prevent ssp from accidentally screwing things up, but as a security measure it's pointless in many cases.
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.
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)
Slightly off-topic but it seems to me that most keyboard layouts but the US seem to be completely retarded—almost bordering a conspiracy—with regard to usability when coding, using emacs and using the unix shell.
When I see someone coding with a non-us layout I smell the humble inexperience and nod with compassion. The difference between layouts can be astonishing if you only bang a lots of []{}|/\?-=+_-*()@#$'s. For some reason, computer languages are full of those.
I use the us layout all the time except when I have to write something in my native language and need the umlauts more easily. I remember the killing pain of trying to write code in it until I realized I can just turn on the US keyboard. Luckily, that was before my career...
Actually QWERTY was created to slow typists down. Back in ye olde days, when typewriters were still around, there was the problem where people who typed to fast would jam the typewriters. Thus, QWERTY was invented to slow people down so the typewriters wouldn't jam. Then, when computers came along, everybody knew QWERTY, so they continued using it.
That's an apocryphal story, though. QWERTY was said to have been invented, actually, to make it easier for typewriter salesmen to type "TYPEWRITER", all from the top row.
Actually that's (and typing other frequent programming related stuff like the semicolon, or the brackets) one of the reasons I switched to 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.
For the same reason I don't use a custom .vimrc file; it's great when on a configured system but causes problems elsewhere.
For years I held a similar philosophy, then I decided, "Screw it, I can just copy .vimrc and .bashrc to whatever system I need, and if that's not possible, I can adapt to the defaults." I haven't done too much customization yet, but after seeing some example .vimrc and .bashrc files online, there's a lot of potential for improving productivity.
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.
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.
'Have had "." in my $PATH for 20 years. It's never been a problem... and probably saved me several hundred thousand keystrokes.
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.
before changing directories, it's less of an issue. And `rm -fr /' is less likely than `rm -fr ~', since most people don't need root access to call `ls'.
But still, I don't add '.' to my path because the only time I directly reference files in my current directory, it's because of a Zsh suffix alias.
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"
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.
I've had . in my $PATH for the last couple of decades. It's fine.
The point is that you would never tpye "./ls" when you meant to type "ls".
Or at least I wouldn't. I just grepped through (several years of) my bash logs and I have never once in my life typed "./ls", accidentally or otherwise. I consider this strong evidence.
1) that's a far less likely scenario
2) you shouldn't be running programs out of publicly writeable directories on hostile multiuser systems anyway.
3) (not directly related to your post) explicitly using ./ allows for more accurate completions, almost always making up for the two extra characters typed (particularly since ./ is so easy to type with a single motion).
I'm really surprised over the complete lack of thought shown by people who spend time writing about this.
The problem isn't really about having . in your path, but the old mistake of having it AS THE FIRST THING 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).
