Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!apple!oliveb!tymix!tardis!jms
From: jms@tardis.Tymnet.COM (Joe Smith)
Newsgroups: comp.sys.amiga.tech
Subject: Want multiple default directories
Summary: Search other directories when Open() for reading fails
Message-ID: <624@tardis.Tymnet.COM>
Date: 25 Sep 89 05:06:03 GMT
Reply-To: jms@tardis.Tymnet.COM (Joe Smith)
Organization: McDonnell Douglas Field Service Co, San Jose CA
Lines: 40

Here's a suggestion that would make toolpath unnecessary.  It's an idea that
is at least 12 years old on TOPS-10 that MS-DOS has only recently
implemented.  (And Unix doesn't have yet, as far as I know.)

The idea is to have a directory (or list of directories) to be searched
if a file is openned for input and not found in the current default
directory.  TOPS-10 called this the LIB PPN and/or the LIB: pathological
device.  MS-DOS 3.20 calls it the APPEND command.  (I don't like that name.)

The major difference between this idea and the current PATH is that PATH is
for command/script files only, implemented in the CLI/SHELL, whereas the
extended default directory would be implemented in the OS, available to
all programs for any type of file.

TOPS-10 has options as to what to do if the file is not found in the current
directory but does exist in one of the alternate directories. They are:
        Open for        Default              Alternate
        -------      -------------        ----------------
        reading      return file found    return "file not found"
        writing      create new file      supersede existing file
        update       return error         update file in other directory
The other directories were searched whenever an attempt to lookup a file
failed, even when an explicit directory path was provided on the open call.
In Amiga terms, this would include attempts to find files in L:, DEVS:, and
FONTS:, if desired.

Workbench would benefit from this, by having a list of directories to search
when locating the default tool when double-clicking an icon.

What I am asking for would need to be integrated into the OS, not tacked on
like the PATH: pseudo device.  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.

Ending on a humorous note, I can say "the other guys have it, we want it too!"
-- 
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!"