Roger Evans wrote:
And the biggest reason: there are maybe millions of programs and scripts
that are written to assume that fopen DOESN'T search a path variable,
and might break if the behavior were changed. Users are also
'programmed' to assume that commands will look where they're told to
look and nowhere else. It's bad enough having to 'reprogram' when
switching from an MSDOS command line (which has '.' implicitly in its
PATH) and linux, which doesn't.
You could even be able to make a case for dropping this behavior on the
part of exec and ld, and forcing the user/programmer to specify where
the files are. But that would break a lot of things, too.
Roger
On Thu, 2010-03-18 at 09:36 +0100, Rob van der Heij wrote:
On Thu, Mar 18, 2010 at 5:39 AM, William D Carroll
<[email protected]> wrote:
Biggest reason I can think against it (just devil's advocate) is performance
if you had a search path that fopen/fdopen used then for every call of
fopen/fdopen
they would search the path (or could potentially search they path)
this could cause excessive overhead on the lpar.
think of the extra IO that would be occurring performing searches
"When other things equal, performance rules. Otherwise often too" :-)
I think you're right that the cost of searching other directories is
is to be avoided. And just like with $PATH there is a trojan horse
around the corner...
The idea smells like the CMS "file mode extension" where you want to
fake things and allow the program to think the file is somewhere else.
With CMS mini disks you have no other options but copying the files
when the program was not prepared to look on other file modes. The
mechanisms in Unix are a bit different. I don't think I've seen a
program that took a file name as an argument but could not handle a
path. But if it really happens you do tricks with links.
Really just command line. I see an analogy with "address command"
religion in CMS. When you write a program in Linux you should not rely
on the path but state which program you run and what files you use. I
would not like to see "sshd" pick up a different config file because I
installed some Java stuff that injected some directories (at the
start) of my $DATAPATH environment variable.
The PATH environment variable satisfies a pretty similar to that
provided by concatenated system/job/set/task libraries on MVS. One has a
defined way of specifying "my program is in one of these locations."
Some programs, java, perl, python and many more use a defined
environment variable to locate their libraries.
Applying a similar scheme to just any open sounds to me like a disaster
waiting to happen. Imagine a user doing this, as root:
cd /tmp
echo someting | bash
if open searched some path that happened to include /bin
--
Cheers
John
-- spambait
[email protected] [email protected]
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375
You cannot reply off-list:-)
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
