I kind of wonder whether an open_via( path_string, file_name, mode) kind of routine would be worth sneaking into the stdio (libc.a) library making fopen_via() a slam-dunk. I don't see it becoming a syscall since the shell doesn't do that, but this would make the use of a path variable overt rather than covert.
The key, of course, is that the shell, Perl, Java (and likely a couple of others) aren't using syscalls to do these opens, they are using their own code to handle the path-scanning. Path management is, to my eye, almost as frightening as the early years of "DLL Hell" as well as Java's "Write Once, Debug Everywhere"... and, for the latter, I recall one app I supported that had to have THREE DIFFERENT versions of JAVA running at one time. This is one of those trade-offs, y'know? But, in any case, you DO NOT want open() or fopen() walking a path tree to get at a file. As it is, you want to manage this carefully because open() time (performance!) is impacted, linearly, by the size of a directory, since a search is linear, just to find the inode number. Add pathing to that and open() times won't be predictable. Having a "standard API" layer to support this for Perl, Shell, Java, etc, might not be quite so terrible. (laughs) I once suggested, in comp.lang.c, that "long int" and "long long int" needed a little bit of help so I suggested that a 1024bit integer be considered a "ludicrous long int". (smirks) - soup On Thu, Mar 18, 2010 at 5:25 AM, Roger Evans <[email protected]> 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. >> >> 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 > -- > Roger Evans, http://www.autodata.no tel: +47 23 17 20 46 GSM: 93 25 92 > 36 > > ---------------------------------------------------------------------- > 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 > -- John R. Campbell Speaker to Machines souperb at gmail dot com MacOS X proved it was easier to make Unix user-friendly than to fix Windows ---------------------------------------------------------------------- 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
