I just recently answered a similar question for someone in my Linux user
group -- namely, why is adding just "." in the PATH a "bad thing"?  [they
both have the same answer...]

[trotting down to the "sent items" archive...]

Here's the "long" answer.  Mind you, this is an answer to a Linux user
group, so there will be lots of "unix-ism's" throughout.  (actually, as I
re-read this, I realized I've glossed over the distinction between ".",
"..", and "the root directory" -- a single "." stands for "the current
directory", ".." means "the PARENT of this directory", and "/" [in unix
terms] is "the root directory, of which there is no parent")

> -----Original Message-----
> From: Don Gibbs [mailto:[log in to unmask]]
>
> Okay, I give up - why is bad to add "." to the end of the $PATH
> environmental variable?

The answer, like all good answers nowadays, is "it depends..."

First of all, nearly everyone who says "this is bad, don't do it" fails to
add the REALLY important clause of "this is bad IF YOU ARE LOGGED ON AS
ROOT, don't do it".  (OTOH, since a most of new-to-linux-users are usually
logged on as root, adding this caveat seems redundant.)  For your "everyday
user" userid, adding a "dot" entry to your path will not jeopordize your
system, BUT IT MAY HAVE UNDESIRABLE SIDE EFFECTS.

What are these side effects, you wonder?  Well, consider one of the
"siblings" of unix: CP/M.  Under CP/M, commands were classified as either
"internal" or "external" commands.  Getting a directory listing, being a
frequent and extremely BIOS/BDOS related function, would typically be
implemented as an "internal" function -- coded directly as part of the
kernel, so to speak.  PIP, on the other hand, was a less frequently used
utility and generally had several non-BIOS calls, so it made more sense to
include this as an "external" command that is loaded into memory "on demand"
[when you typed the command].

Under unix, there is no distinction between "internal" and "external"
commands -- they are ALL external.  This has good points [flexibility: you
don't like the format of the directory listing, you can change it relatively
easily -- you need not recompile "the kernel"] and bad [even something as
mundane as a directory listing requires searching the path for the
executable, loading it, "run-time" linking it, etc.]

Now, the "good" point of flexibility is a double-edged sword, and the crux
of the matter as to why "dot is bad".  BECAUSE the system will search the
"executable path" for an instance of the program to generate a directory
listing, AND because whatever one "appears first" will be used, placing a
PROGRAM WITH THE SAME NAME AS THE COMMAND 'EARLIER' IN THE PATH will cause
it to be executed instead of the program/command the user intended to
execute.  Notice throughout this dialog I've said "the program to generate a
directory listing" and not "sl" [whups -- that's a typo, it should be "ls"]
and THAT, my friends, is the REAL reason "dot is bad" -- if there HAPPENED
to be a file called "sl" IN YOUR CURRENT DIRECTORY and IT HAPPENS TO HAVE
THE EXECUTABLE FLAG SET, "mistyping" the directory command would cause this
"other" program to execute.

Now, what could this "other program" possibly be?  Here are some scenarios:

   1) in some "user" account, a user creates their own "sl" program that
creates the "expected" output of the "ls" command AND silently copies
"/etc/shadow" to a local [hidden or pseudo-randomly named] file.  As the
"normal" user, read access to "/etc/shadow" is, of course, disallowed.
However, THE ROOT USER HAS THE PRIVILEGE OF READING THIS FILE -- should the
"root" user (a) have "cd'd" to this user's "home" directory, and (b)
mistyped an "ls" command, then that user would get their own copy of the
encypted passwords to crack at their leisure...

   2) or better still, it attempts to COPY a new file to /bin/logon
[login?].  Again, the "normal" user would be denied, but the "root" user
"can do anything..."  As you would imagine, this "alternate" login program
would work "exactly" like the legit copy but with the added bonus of logging
each and every successful logon/password combination...

   3) it appears to "hang" the system while it performs an "rm -rF /"
command in the background.

   4) it places the calling user in a "new" shell that not only executes
everything the user requests, but also logs all the keystrokes/input to the
shell for later perusal. [and might even point out that the "sl" command is
"not found"...]

In other words, ALL of these examples are "trojan horse" programs that a
"normal" user manages to place in a location where a "root" user might
traverse and [eventually] inadvertantly execute.  (i.e., the "normal" user
is either an internal hacker or someone who has hacked a non-privileged
account)

Now, presumably, all of the "directories" on the ROOT user's path are
directories that "normal, non-privileged users" can NOT write to in any way.
(likewise for normal users, but that is "their choice", and obviously a
"normal user" will have write access to their own "/home/username/bin"
directory, should they be of the "developer" mindset...)  Since the "dot"
directory is never guaranteed to be "non-writable" by "normal" users, it's
inclusion on the root user's path is susceptible to this
misnamed-utility-trojan.

> -----Original Message-----
> From: Carl McNamee [mailto:[log in to unmask]]
> Sent: Friday, March 24, 2000 1:59 PM
> To: [log in to unmask]
> Subject: posix command question
>
>
> Pardon me, my posix ignorance it showing!
>
> I am curious about something that I have been running into in
> the posix
> shell.  Why do I have to qualify the name of a script to be
> run with "./"?
> If I have the script "test" in the directory "/SYS/CARL/" and
> I am in the
> CARL directory I have to run the test script by typing
> "./test".  Why can't
> I just type "test" and have it run?
>
>
>
> Carl McNamee
> Systems Administrator
> Billing Concepts
>