john13@garfield.UUCP (John Russell) (03/21/88)
[Peter Schachte says assign should be extended to paths]
Since assign gets a lock on the directory it uses, there are two possibilities
for having multi-dir assigns.
1. You get 10 requesters in a row asking for different volumes so it can get
locks on each different directory, for widely scattered fonts for instance.
2. The programmer turns off the requesters with pr_windowptr and so any disks
that aren't mounted aren't affected by the assign.
Same thing goes if you enter a filename, say for includes... "please insert
volume WorkDisk15" CANCEL! CANCEL! CANCEL!
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...
BTW, if you want to make your own path right now (I did for my 'colour'
program, current directory + S:) you can specify something like
if (! (fp = fopen("myfile","r") || fp = fopen("dir:anotherfile","r")))
<couldn't open file>
You can include strcats and strcpy's as parameters if you will only use them
once.
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.
John
PS I would like to see the ENV: device from Bill Hawes though... that sounds
like just what I was advocating in the way of device drivers that tackle
tasks we always used programs for in the past.jdh@bsu-cs.UUCP (John Hiday) (03/24/88)
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