dan-hankins%cup.portal.com@UDEL.EDU (10/04/88)
Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 8081; Sat,
01 Oct 88 01:49:30 EDT
Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Sat, 01
Oct 88 01:49:26 EDT
Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id ab16415; 30 Sep 88 19:52 EDT
Received: by Louie.UDEL.EDU id ab16348; 30 Sep 88 19:47 EDT
Received: from USENET by Louie.UDEL.EDU id aa16120; 30 Sep 88 19:29 EDT
From: dan-hankins@cup.portal.com
Subject: Execute command bug with T: and :T/
Message-ID: <9550@cup.portal.com>
Date: 29 Sep 88 04:14:49 GMT
Organization: The Portal System (TM)
XPortal-User-Id: 1.1001.5361
To: amiga-relay@UDEL.EDU
Sender: amiga-relay-request@UDEL.EDU
HELP!!!!!!!
I am nesting Execute commands in my startup-sequence. Execute wants to
write to :T/Command-T-xx whenever I do. Creating RAM:T and assigning T:
to RAM:T doesn't work.
changing both references of :T in the Execute binaries to T: seems to help,
but for some reason the startup-sequence still complains (with a requester)
at some point about DF0: being read-only (namely the point at which I attempt
to execute the first nested Execute script). The relevant portions of my
startup-sequence look like this:
IF NOT EXISTS RAM:T
makedir RAM:T
ENDIF
Assign T: RAM:T
Execute Setup1 ;Requester is put up at this point. Clicking on CANCEL causes
;execution to continue normally
Execute Setup2 ;No requester asked for.
Dan Hankinsjdow@gryphon.CTS.COM (J. Dow) (10/06/88)
In article <4412@louie.udel.EDU> dan-hankins%cup.portal.com@UDEL.EDU writes: > >HELP!!!!!!! > >I am nesting Execute commands in my startup-sequence. Execute wants to >write to :T/Command-T-xx whenever I do. Creating RAM:T and assigning T: >to RAM:T doesn't work. > >IF NOT EXISTS RAM:T > makedir RAM:T >ENDIF >Assign T: RAM:T That "if" is your problem. During startup-sequence RAM: does NOT exist so 1) it is not needed and 2) it forces a command-t-xx file into the current sys:t or t: directory. The solution is pull the makedir ram:t outa the if clause and do it every startup near the beginning - before any if's. -- Sometimes a bird in the hand leaves a sticky deposit. Perhaps it were best it remain there in the bush with the other one. {@_@} jdow@bix (where else?) Sometimes the dragon wins. Sometimes jdow@gryphon.CTS.COM the knight. Does the fair maiden ever {backbone}!gryphon!jdow win? Surely both the knight and dragon stink. Maybe the maiden should suicide? Better yet - she should get an Amiga and quit playing with dragons and knights.
rap@ardent.UUCP (Rob Peck) (10/07/88)
In article <7519@gryphon.CTS.COM>, jdow@gryphon.CTS.COM (J. Dow) writes: > In article <4412@louie.udel.EDU> dan-hankins%cup.portal.com@UDEL.EDU writes: > >I am nesting Execute commands in my startup-sequence. Execute wants to > >write to :T/Command-T-xx whenever I do. Creating RAM:T and assigning T: > >to RAM:T doesn't work. > >IF NOT EXISTS RAM:T > > makedir RAM:T > >ENDIF > >Assign T: RAM:T > That "if" is your problem. During startup-sequence RAM: does NOT exist so > 1) it is not needed and 2) it forces a command-t-xx file into the current > sys:t or t: directory. The solution is pull the makedir ram:t outa the if > clause and do it every startup near the beginning - before any if's. If RAM:T already exists, there might be an error code generated by the MAKEDIR, potentially causing the script to fail unless FAILAT is set to a high enough value. One of the simplest ways of causing RAM: to exist at the start of the world is the following in the startup-sequence. The nice part about it is that it won't cause a script failure if RAM: does not exist: DIR > NIL: RAM: Rob Peck