Subject: Re: . in path
To: None <email@example.com>
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
Date: 12/12/1994 12:16:43
>> Since when has it been the shell's duty to warn of possible security
> For the same reason that gets() does, I daresay.
Except that gets() produces one message, at link time, and that's it.
(Mercifully. The previous complaint at runtime was quite obnoxious.)
> I like to consider it out friendly little quick-and-dirty check; it's
> easy to do, so why not?
Because it isn't always a security risk, and you as the shell author
are not in a position to tell when it is and when it isn't, and you
don't provide any way to disable the check. I may have a machine for
which for any of many reasons I want . in my path as root and due to
the lack of other users it's no less secure than any other way...but
that silly check means automated rsh to the machine is borderline
> I would STILL like to know why dot is in the default PATH for sh, as
> set in var.c; this seems like very broken behavior to me...
I don't know. As far as I'm concerned you are welcome to change the
defaults. But please give me a way to configure away what is in my
environment a useless noise complaint! (And no, commenting out the
check in the source doesn't count, though that's probably what I'll end
up doing for the time being.)