Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!jade!topaz.berkeley.edu!pete
From: pete@topaz.berkeley.edu
Newsgroups: comp.sys.amiga
Subject: Re: ASSIGN T: RAM:T, and write-protect you boot disk
Message-ID: <3562@jade.BERKELEY.EDU>
Date: Fri, 15-May-87 03:55:11 EDT
Article-I.D.: jade.3562
Posted: Fri May 15 03:55:11 1987
Date-Received: Tue, 19-May-87 01:29:21 EDT
References: <0174526P@NAVPGS> <1819@cbmvax.cbmvax.cbm.UUCP>
Sender: usenet@jade.BERKELEY.EDU
Reply-To: pete@topaz.berkeley.edu (Pete Goodeve)
Distribution: world
Organization: University of California, Berkeley
Lines: 28
Keywords: ASSIGN, RAM:, T:, EXECUTE
Summary: It never worked for me!

Carolyn Scheppner replies to an earlier query [from Scott Norton] as follows:

  >>.... Just ASSSIGN T: RAM: in the startup, and I can write
  >>protect my Workbench disk....

>...I always have T: assigned to a T directory in RAM:  Haven't had any
>problems...

Hunh??  Hold on there!!  Are we talking about the same system?  I've always
been bugged by the fact that EXECUTE wants to write to ':T'  (NOT 'T:'!)
on the CURRENT device (and so does ED, but I don't use that much any more..).
In fact it annoyed be so much -- especially because my "Sili(Con:)" CLI
enhancer is liable to make heavy use of command scripts -- that I went in
with FileZap and changed the offending string from ":T/Command-..." to
"T:_Command-...", so I COULD assign T: in RAM:.

I was just about to post this hack to the net when I saw your note.  All
confused, I dug back into my system, checked that I WAS using the EXECUTE
from the 1.2 release, and that it did what I thought it did..

With total certainty, I can now say that the 1.2 EXECUTE will NOT
recognize 'T:'.  I also double-checked ED, and it just seems to throw
away the backup if ':T' doesn't exist.

So where's the discrepancy...?  Elucidate, please!  I would love a standard
version of EXECUTE that does what the "Enhancer" docs say it ought to...

-- Pete Goodeve --