Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!quintus!pds
From: pds@quintus.UUCP (Peter Schachte)
Newsgroups: comp.sys.amiga
Subject: Re: Sys:System vs. System:
Message-ID: <685@sandino.quintus.UUCP>
Date: 22 Feb 88 22:20:38 GMT
References: <7025@agate.BERKELEY.EDU> <3343@cbmvax.UUCP>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 65
Summary: How about ASSIGNing to a PATH of directories?

In article <3343@cbmvax.UUCP>, andy@cbmvax.UUCP (Andy Finkel) writes:
> In article <7025@agate.BERKELEY.EDU> spencer@eris.berkeley.edu (Randal m. Spencer [RmS]) writes:
> >Ok, here is an interesting point.  Who out there is using sys:c or sys:l
> >or any variation on that in their programming.  I'll tell you who is
> 
> >But on top of
> >that it made me realize that the idea of workbench keeping its files
> >(diskcopy and format) in sys:system and not system: is also quite annoying.
> 
> Workbench keeps its files in the System drawer so a) it can
> find them, and b) so they don't clutter up the root directory.
> 
> Many other operating systems find the idea of splitting
> up the commands into different directories useful, as well.
> Among other things, it minimizes name collision.
> 
> >why do I have to create a directory in ram called system when I want to
> >run diskcopy and format out of ram?
> 
> Well, one more logical name wouldn't be too bad.

I haven't seen this topic beaten to death here, so I thought I'd try it.
Why not allow ASSIGNs to PATHs (lists) of directories?  You could do
something like

ASSIGN C:	., ram:c, sys:c, sys:system, sys:
ASSIGN S:	ram:s, sys:s
ASSIGN FONTS: 	sys:fonts, fontdisk:fonts
ASSIGN INCLUDE:	., ram:include, sys:include

You get the idea.  There are so many more things that one might want
search a path for than just executables.

Notes:  I don't know of any amigados way to say "the current directory,"
so I used "." above.  And in the FONTS:  example, the idea is that when
you ask for a font that isn't loaded, and isn't on the system disk, you
would be prompted to insert the "fontdisk" disk.  Of course, you would
also be prompted to insert it when the system is just trying to decide
what fonts you have available, so it had better cache this info once
computed.

This would also solve the problem of WB tools being unable to find their
programs (when, e.g., you try to move the program to your sys:c or dh0:c
directory, where you think it should be.  The problem is that paths are
local to a CLI (correct me if I'm wrong), so a WB tool can't count on a
path allowing it to find its program.  But ASSIGNs are global.  A tool
could always find C:program, if C: was a path ASSIGN including the sys:
directory.  I don't think having one's path be global is much of a
disadvantage, and it does have the mentioned advantage for WB tools.

There is also the issue of where to create a file in an ASSIGNed path.  One
could take the simple approach of creating it in the first directory
listed in the path.  Perhaps it would be better to extend the syntax for
ASSIGN to allow the specification of this information, e.g.,

ASSIGN C:	., ram:c, sys:c, sys:system, sys: CREATE sys:c

How about it?  I heard someone mention this at a recent BADGE meeting,
so I know it's not a new idea.  But it sure seems like a good one.
This is what I was hoping they would do in 1.2, rather than adding the
PATH command.
-- 
-Peter Schachte
pds@quintus.uucp
...!sun!quintus!pds