It will be no easy task to find "historic documents" about this decision, but quoting another answer from the StackExchange umbrella, you will find what I also think is the most appropriate answer to your question: to avoid "sh## happens" scenario:
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?
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.
And on this link, you can find an additional example why is dangerous to put the dot on your
An extreme example would be the situation in which an ordinary user
created a shell script such as
rm -r /, which would delete all files
and directories in the system for which the user had writing
permission, and named this script
ls. Were the system administrator to
navigate to the directory in which this script was located and attempt
to run the standard
ls command in order to view the contents of that
directory, the shell would instead run the script with the same name
and thereby remove the contents of all currently mounted partitions on
Also, the purpose of PATH is to complete the path of a command in such way you don't need to remember or type the full path of your binaries. There is no need to index commands of a directory you are in. It's not useful at all if you know where these programs are stored.
However, after some research, I found that the idea behind the search path came from Multics, but the limitation was that it only searched inside
/bin. Unix v3 was the first to implement it without this one-directory limitation. And taking a look at the security pages of the following manual, they already have shown what are the issues while using
. in a PATH variable. This applies not only to
su and it reinforces the security matter of injecting malicious code on the environment.
Quoting page 13:
Trojan Horse tricks and countermeasures were discovered in an ongoing
game that has been recounted by Morris and Fred Grampp. Notice, for
example, the removal of
login(1) to chapter 8 and the intrusion of
/etc/ into the synopsis for
su (Grampp, v8). These fillips defeated
the old chestnut of leaving programs named
su lying around in
hopes of capturing a password typed by an unwary system administrator.
Other subtle features of the modern
su: dot is excluded from the shell
search path and the burglars’ favorite shell variable
IFS is reset.
Since its conception, this feature has proved dangerous if using dot as part of the
/bindirectory, and the
PATHconcept came from Multics only because the development team's
/binbecame too large. It doesn't mention anything about
.. I don't think it has much significance. It's likely that it was experimented with and then it occurred to someone that it was a security hole.