Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!van-bc!
From: lphillips@lpami.wimsey.bc.ca (Larry Phillips)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Want multiple default directories
Message-ID: <780@lpami.wimsey.bc.ca>
Date: 24 Sep 89 11:41:42 GMT
Lines: 84
Return-Path: 
To: van-bc!rnews

[Devil's Avocado for the line eater]

In <624@tardis.Tymnet.COM>, jms@tardis.Tymnet.COM (Joe Smith) writes:
>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.)

Is this A Good Thing or has April Fool's day come twice this year? 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'? If an explicit path is
given as a file name, wheter it be absolute or relative, by physical or logical
device, does it really make sense to assume that a file found via a path can be
written over or appended to? Yow!

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

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 can't see this as being something the OS
should get involved with.  File names tend to be hard coded into programs, and
unless there is some sort of 'registration' for them, you are bound to run
across conflicts, which on the Amiga can be handled quite nicely, with less
chance of losing that config file you just spent an hour setting up.

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

Wouldn't this be best implemented in the icon's INFO fields? I have always
wanted to have icons point anywhere I want them to point, for tools and
projects alike, but I want to be the one to point them there. When I click on
an icon for a doc file, I don't want it to find the first README it comes
across if I have deleted or renamed the README I really wanted, by accident or
otherwise. I want it to tell me the file isn't there. Always.

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

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. Sort of an 'alternate current dir'... can't
see much wrong with it, and it would provide a nice way to keep things
separated without having to CD to a particular directory, and to reduce
problems of naming conflicts.

>Ending on a humorous note, I can say "the other guys have it, we want it too!"

In that same spirit, I will ask you the same question my mother used to when I
said something like that. "If the other guys jumped off a cliff, would you want
to jump off it too?"

-larry

--
The Mac? Oh, that's just like a computer, only slower.
+-----------------------------------------------------------------------+ 
|   //   Larry Phillips                                                 |
| \X/    lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips |
|        COMPUSERVE: 76703,4322  -or-  76703.4322@compuserve.com        |
+-----------------------------------------------------------------------+