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. Rob ---------------------------------------------------------------------- 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
