Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!ginosko!brutus.cs.uiuc.edu!apple!oliveb!tymix!tardis!jms From: jms@tardis.Tymnet.COM (Joe Smith) Newsgroups: comp.sys.amiga.tech Subject: Re: Want multiple default directories Message-ID: <640@tardis.Tymnet.COM> Date: 26 Sep 89 23:20:53 GMT References: <780@lpami.wimsey.bc.ca> Reply-To: jms@tardis.Tymnet.COM (Joe Smith) Organization: McDonnell Douglas Field Service Co, San Jose CA Lines: 54 In article <780@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >Is this A Good Thing or has April Fool's day come twice this year? No, it is a serious suggestion. The feature of having an 'alternate current directory' for finding files is something I use all the time on TOPS-10. >Aren't naming conflicts a problem if for no other reason than that your >data file names must then be unique within any given 'LIB PATH'? No. The place where I used this feature the most was in creating test versions of software. All the production sources were in one directory, and the test directory had only the files that had been modified. By setting the default directory to the test directory and the alternate directory to the production directory, unchanged files would not have to be duplicated into the test directory. When doing a "make", only the changed sources would be recompiled. The new object files are created in the default (test) directory, and never overwrote the old object files in the production directory. When the linker, compiler, or make programs ran, the OS acted as if all the appropriate input files were in the current directory. All this was done without having to create a symbolic link for each and every unchanged file. >does it really make sense to assume that a file found via a path can be >written over or appended to? Yow! The path is searched only for input files, not output files. >We have much the same functionality now, with the system-assigned directories. >Libraries are searched for in LIBS:, handlers in L:, environment files in >ENV:,and so forth. For general data files, programs can pretty well count on >the existence of S:, T:, and so on. Programs that are interested in a file >can look in currentdir and in any system-supplied directory, leaving the >choice up to the user as to where it is. I agree with everything above, but that doesn't help for locating *.c and *.o when compiling. (*.h and *.lib are already handled OK.) >>And, since a program could be loaded from >>any one of many directories, the OS would need to provide a call that would >>return the full path name of where the executable was really found. > Aha! A glimmer of hope here.... in this, you seem to be saying that one > of the directories in the LIB PATH would be the directory the application > resides in. I think this might be A Good Thing. Actually, I was talking about static lists of LIB PATH directories. But it would be nice to have the OS automatically include the tool's directory in the list of automatically searched alternate directories. -- Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@tymix.tymnet.com McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P," San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"