richc@madvax.UUCP (04/07/87)
Before I start, I would like to express my appreciation to all
the people on comp.sys.amiga for supporting the AMIGA and making it a
fantastic computer. The amount of work and effort put into this news
group is awesome. I've been with this group and the previous group
(net.micro.amiga) for about 5000 articles and have just learned that
I can post an article. Now I can contribute to the discussions and
pass along my experiences, so the next guy can come up to speed on this
great machine faster.
The PATH that was missing:
--------------------------
After booting up my system with V1.2, I noticed that the path
that was specified in the startup-sequence, was not active when I started
up a new CLI with POPCLI II or with the CLI ICON. In fact the path was
in the reset default mode. After an hour of modifying the startup-sequence,
I tracked down the cause. It seems, if the path command is issued after
POPCLI II, then a new CLI is started, the path is in the default condition.
It seems, when opening any CLI and modifying the path, then ending the CLI,
the additions to the path are lost when a new CLI is opened. The only path
that remains is the initial path at the beginning of the startup-sequence.
I thought a path command should specify a search path for the computer, not
just for the current CLI. Is this a bug with the path command or a feature.
I'm posting this in the hopes that the next guy who comes across this problem
(I think its a bug) won't have to spend time tracking it down. Could someone
confirm or comment on this?
Thanks in advance
--
--
Rich Commins (415)939-2400 \ /\
Varian Instruments, 2700 Mitchell Drive, Walnut Creek, CA 94598 \/--\
{ptsfa,lll-crg,zehntel,dual,amd,fortune,ista,rtech,csi,normac}varian!richcdillon@CORY.BERKELEY.EDU.UUCP (04/07/87)
The cli PATH is not a universal entity. That is, a NEWCLI inherits it's parent CLI's PATH. Thus, starting a NEWCLI before setting up your custom PATH in the old CLI means the NEWCLI contains the default path. -Matt
spencer@eris.BERKELEY.EDU (Randy Spencer) (04/07/87)
In article <536@madvax.UUCP> richc@madvax.UUCP (Rich Commins) writes: >The PATH that was missing: >-------------------------- > After booting up my system with V1.2, I noticed that the path >that was specified in the startup-sequence, was not active when I started >up a new CLI with POPCLI II or with the CLI ICON. > Is this a bug with the path command or a feature. >I'm posting this in the hopes that the next guy who comes across this problem >(I think its a bug) won't have to spend time tracking it down. Could someone >confirm or comment on this? >Rich Commins (415)939-2400 \ /\ What you have there is not a bug. You have to think about this a little I guess, but path sets the path for its CLI only! Any CLIs started from this CLI inherit its path, but Path is not global (Although Assign is global). If you want to set a path for all your CLIs do it in your startup-sequence. I set all my paths before I run PopCLI. Then any CLIs started from there have my desired path. You will never be able to set the Path for a CLI started from the workbench, because there is no CLI for it to inherit its Path from. Of course, everybody is going to answer this question, I don't know why I bothered... Another hint for all you Startup-Sequence writers out there. Anything that is global can be done in a second CLI. All Assigns can be done by a file that is "run execute"ed. Of course you have to get the timing down so that you don't get all the head seeking. I have mine do a newcli with the "from" argument. This CLI executes all the commands contained in the "from" file. Echo Statements let me know how far along it has gotten. While the new CLI is assigning and binddrivering and copy c:#? to vd0:c-ing, I have the main CLI to enter commands in. The second CLIs last command is EndCLI so that it goes away, and I can still get other ones from PopCLI. Although I am writing a tiny program using Commodities.Library that does the same thing without putting something else hanging on the input handler. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Randy Spencer P.O. Box 4542 Berkeley CA 94704 (415)284-4740 I N F I N I T Y BBS: (415)283-5469 Now working for |||||||||||::::... . . BUD-LINX But in no way |||||||||||||||::::.. .. . Officially representing ||||||||||||:::::... .. ....ucbvax!mica!spencer s o f t w a r e spencer@mica.berkeley.edu -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
feb@cblpe.UUCP (04/08/87)
In article <536@madvax.UUCP> richc@madvax.UUCP (Rich Commins) writes: > ...[edited]... >I thought a path command should specify a search path for the computer, not >just for the current CLI. Is this a bug with the path command or a feature. ...[edited]... > > Thanks in advance >-- >-- >Rich Commins (415)939-2400 \ /\ >Varian Instruments, 2700 Mitchell Drive, Walnut Creek, CA 94598 \/--\ >{ptsfa,lll-crg,zehntel,dual,amd,fortune,ista,rtech,csi,normac}varian!richc In my humble opinion, the PATH set in a certain CLI (shell) (Unix influence showing here) should be used by that CLI (shell) and any new CLIs (shells) run from that CLI (shell) only. The reason is that different tasks running in different CLIs (shells) should be able to get at the commands they need, in the order they need them, regardless of other tasks running on the machine. -- Franco Barber AT&T Bell Laboratories, Columbus, Ohio ..!cbatt!cbplf!cblpe!feb (614) 860-7803