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!"