Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ames!pacbell!att-ih!ihnp4!inuxc!iuvax!bsu-cs!jdh
From: jdh@bsu-cs.UUCP (John Hiday)
Newsgroups: comp.sys.amiga
Subject: Re: More on Paths - Why Assign isn't the Answer
Message-ID: <2452@bsu-cs.UUCP>
Date: 24 Mar 88 02:52:07 GMT
References: <4608@garfield.UUCP>
Reply-To: jdh@bsu-cs.UUCP (John Hiday)
Organization: Ball State University UCS, Muncie, IN
Lines: 58
Summary:


In article <4608@garfield.UUCP> john13@garfield.UUCP (John Russell) writes:
>[Peter Schachte says assign should be extended to paths]

IMHO he is right.  Having path support in the dev/file system is a much
more elegant solution than the environtment variables approach.  That's
not saying that it could just be grafted onto "Assign" as is.

> [description of the problem where a user has to pop in 10 disks to
> Assign a path to several disks deleted]
>

Yes this is a problem that must be overcome, but the current Path command
has the same problem, so why shoot down pathed assigns just because of it?

Maybe we need another kind of Assign which wouldn't grab any locks ahead
of time.  The equivalence (or list of them) wouldn't get parsed until
someone tickles the logical name, then the file system would go out
and hunt down the destination.  You could even tell it in the command
line whether or not to put up a requestor when it comes a accross a
volume that is not mounted.  (like maybe LAssign -yell or LAssign -quiet)

>As for standardizing it, let's have someone make up a library of all these
>really useful DOS calls and include in it "ParsePathName" to return a filelock
>given a filename and a path like sys1:include!sys2:include. This is only a
>few lines to write...
>

No.  That would mean modifying programs to be aware of search paths.  It
should be totally transparent, and should not require any recoding.  If
you put it in the file system, only Open() and/or Lock() would need to
be changed (maybe some others, but at least no user code).

> [...]
>Just one more thing, to Peter: the "set" command behaves exactly like the
>extended assign format you want, only with greater generality so it isn't
>limited to files. It was _created_ by a compiler author specifically so he
>could make a path for libraries, include files, etc. Any changes made to
>the structures used by assign will break things left and right.
>

Suppose your "include" search path is sys:aa!sys:bb!sys:cc!sys:dd.  The
pathed assign equivalent of the above env variable would be something
like:
       LAssign include: sys:aa sys:bb sys:cc sys:dd

The compiler may be smart enough to parse the include variable, but 
what about copy, type, dir, etc.?  With pathed assigns you could just
type in "copy include:xyz.h prt:" and the file system will look
down all those directories until it finds xyz.h.  If it finds one it'll
return a lock on it and copy procedes normally, without ever knowing
that it just used a search path.

Let's leave environment variables for plain old text strings.

-- 
== John Hiday                UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!jdh
== Ball State University / University Computing Services        GEnie: JDHIDAY
== Muncie, IN 47306