Path: utzoo!mnetor!uunet!husc6!think!ames!pasteur!agate!violet.berkeley.edu!pete
From: pete@violet.berkeley.edu
Newsgroups: comp.sys.amiga
Subject: Re: New Assigns.  CLI Paths and such.
Message-ID: <7447@agate.BERKELEY.EDU>
Date: 7 Mar 88 03:28:16 GMT
References: <8803032154.AA08656@cory.Berkeley.EDU>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: pete@violet.berkeley.edu.UUCP ()
Organization: University of California, Berkeley
Lines: 24

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