dillon@CORY.BERKELEY.EDU (Matt Dillon) (03/04/88)
>The command path is meant to provide multiple lock style >capability. The major problem with the command path is that it doesn't allow you to make generic specifications. For instance, if you are on a one-drive system, and you want to switch from your workbench disk to a working disk (which happens to have many workbench and other commands in the C directory), you MUST MANUALLY re-assign C: to the new disk. What I want to see are SYMBOLIC paths. And I want to be able to specify that a path search NOT put up a requestor when a specified volume is not mounted. This is one of the major reasons I wrote the shell. But even the shell doesn't help when you RUN something or execute something (like make) which executes other things. For instance, in DME1.29, the referencing command searches S: AND all the floppies for df?:s/dme.refs , and does NOT put up a requestor if there is no floppy in the drive or if the floppy that was there has been changed. It means I can simply stick in the floppy which contains the proper reference material and immediate execute the DME command without having to reassign anything. Since a directory search for a specific file takes virtually no time, having 10 or even 15 symbolic paths takes very little time to search (consider also that these paths usually get cached by the DOS buffers), and some of those links do not have to be mounted. On an IBM PC, this is not the case. Although the paths are symbolic, the entire directory for each path must be searched even when looking for a specific file, causing all sorts of disk activity. -Matt
pete@violet.berkeley.edu (03/07/88)
In article <8803032154.AA08656@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > The major problem with the command path is that it doesn't > allow you to make generic specifications. For instance, if you are > on a one-drive system, and you want to switch from your workbench disk > to a working disk (which happens to have many workbench and other commands > in the C directory), you MUST MANUALLY re-assign C: to the new disk. No, Matt -- you don't have to do that... The path is intended for EXACTLY that purpose. I have a "utilities" disk, which I always keep in my path, even though it is hardly ever actually in the drive. I just pop it in when I happen to want to do a uudecode or something. > What I want to see are SYMBOLIC paths. And I want to be able > to specify that a path search NOT put up a requestor when a specified > volume is not mounted. ^^^^^^^^^^^^^^^^^^^^^^ ...it doesn't! At least not if the CLI (or RUN) is searching the path; asking for a display of the current path with the PATH command itself WILL put up a requestor if the volume isn't mounted, but that's probably a good idea. (This is probably the cause of the misunderstanding.) -- Pete --
dillon@CORY.BERKELEY.EDU (Matt Dillon) (03/07/88)
:> What I want to see are SYMBOLIC paths. And I want to be able :> to specify that a path search NOT put up a requestor when a specified :> volume is not mounted. ^^^^^^^^^^^^^^^^^^^^^^ : :....it doesn't! At least not if the CLI (or RUN) is searching the path; :asking for a display of the current path with the PATH command itself WILL :put up a requestor if the volume isn't mounted, but that's probably a good :idea. (This is probably the cause of the misunderstanding.) : : : -- Pete -- Yes, but I can't put all the assign's I want in my startup script because ASSIGN itself requires the destination be mounted before it adds it to my path. I want to put an arbitrary disk in an arbitrary drive and be able to run commands from that disk's c directory (read: whatever symbolic directory paths I choose) without having to do any kind of initialization. It gets even worse when you have several CLI's lying around. -Matt