Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!sun-barr!newstop!sun!pepper!cmcmanis
From: cmcmanis%pepper@Sun.COM (Chuck McManis)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Anybody know how to do this stuff?
Message-ID: <129263@sun.Eng.Sun.COM>
Date: 14 Dec 89 22:02:35 GMT
References: <13920020@hpfelg.HP.COM> <13920033@hpfelg.HP.COM>
Sender: news@sun.Eng.Sun.COM
Reply-To: cmcmanis@sun.UUCP (Chuck McManis)
Organization: Sun Microsystems, Mountain View
Lines: 55

In article <13920033@hpfelg.HP.COM> koren@hpfelg.HP.COM (Steve Koren) writes:
>             ... I disagree with your comment about the status of df0:
>being useless info.  If the user has included 'df0:c' in his path, I
>need to bypass df0: if there is no disk inserted.  The user might well
>do this instead of using the volume name to access the files in the 'c'
>directory of whatever disk happens to be in df0: at the time, while c:
>might point to the 'c' directory on his hard disk.

This is an interesting semantic for path searching that I don't suspect
is intuitive. When I read this originally, I thought what you might want
to do is find out what volume was in df0:c, and store that so that if
the user had made their path df0:c;df0:tools;sys:lc;Utilities: you could
note the volume that was on df0: and not search df0:c or df0:tools when
it wasn't mounted. However, on rereading it I suspect you really want
the behaviour to be 
	if there is *any* disk in df0: and it has a c directory
	search it at this point in the path. 

At first this sounds kind of nifty since you don't care what the volume
is you can just change your path by swapping the disk in df0:. And yet,
on closer inspection, it seems that there might be massive user confusion
if they had only floppy drives and were trying to run a script that 
involved more disks then they had floppies. Let's say they have one floppy
and their script is a usenet news unpacker. Now they have a disk full of
Usenet news, and a "usenet" system disk which has on it compress, rnews
etc. Now if their path was df0:c, when they start up the script, everything
works until they have to swap the system disk with the data disk. The next
command that runs (let's further assume the script is in ram: so that they
don't have to go back to the system disk to read it.) the next command it
searches for df0:c, finds it isn't there and the script exits with command
not found. Not to friendly, and not to useful either. Something that happens
to me all of the time is that I've renamed my EMACs "ed" because I just type
ed and it gives me whatever editor I use on the system I type it on. This
works because I've deleted the CBM ed from all of my system disks. Now
if I suddenly put a fresher copy of a workbench into my drive, I would
wind up with the wrong editor. 

As I see it the Volume concept makes single drive machines possible because
you can specify the volume name and the machine will always ask you to insert
the disk if it isn't available.

This all brings up another interesting idea. Lets say you cached the names
of all the executables in a path. Now searching the path would be really
fast, and you would never look at a disk unless you needed a command from
it, and you could request disks that weren't in a drive currently to be 
loaded if you needed a command from them. Of course when the contents of 
the directories changed you would have to type rehash or something similar
to get them back into your path but csh users live with that today and it
doesn't seem to bother them.


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@Eng.Sun.COM
These opinions are my own and no one elses, but you knew that didn't you.
"If it didn't have bones in it, it wouldn't be crunchy now would it?!"