Path: utzoo!utgpu!water!watmath!garfield!john13
From: john13@garfield.UUCP (John Russell)
Newsgroups: comp.sys.amiga
Subject: More on Paths - Why Assign isn't the Answer
Keywords: paths set assign
Message-ID: <4608@garfield.UUCP>
Date: 21 Mar 88 07:17:32 GMT
Organization: CS Dept., Memorial U. of Newfoundland, St. John's
Lines: 39

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