ASSIGN T: RAM:T, and write-protect you boot disk

[45...@navpgs.uucp]

I wanted to flip the write-protect tab on my workbench disk to
"protect" so I couldn't shoot myself in the foot. The disk is
just about full, so I can't write anything useful to it anyway.

Unfortunately, I EXECUTE some things in my startup-sequence, so I
need a T directory. A few days ago, I hit on the way out of the
trouble. Just ASSIGN T: RAM: in the startup, and I can write
protect my Workbench disk. A couple of questions for the net:

- Am I harming myself subtley by not having t/ on a non-volatile
device? I don't use ED, so I'm not worried about t/ed-backup

- Why does EXECUTE need a t/ directory?

- Why hasn't anyone mentioned this method before? Does everyone
work off of their workbench disk? Or is it so obvious that only
dolts like me can't think of it? :-b

Scott Norton 4526p.NavPGS.BITNET

[br...@cogsci.berkeley.edu.uucp]

In article 45...@NAVPGS.BITNET (LT Scott A. Norton, USN) writes:
>I wanted to [write-protect] my workbench disk [...]
>Unfortunately, I EXECUTE some things [...] so I need a T directory
>[I] Just ASSIGN T: RAM: in the startup, and I can write

>protect my Workbench disk. A couple of questions for the net:
>

>- Am I harming myself subtly by not having t/ on a non-volatile

>device? I don't use ED, so I'm not worried about t/ed-backup
>- Why does EXECUTE need a t/ directory?

1> EXECUTE uses the T directory to expand command lines with the arguments
given the command file.
This information is very small, usually <100 bytes and could be much
better served by just keeping it in RAM. It is deleted after the
EXECUTE finishes, so non-volatility is a non-issue. Feel free to
protect your workbench.

2> Not all EXECUTE scripts open temps, only those with parameter substitution:

--------:This one does:-----------

. ;Notice the period
echo "hello" ;This does an echo

--------:This one does not:-------

echo "hello" ;This does an echo

----------------------------------
The difference is the period. If this (or any of the 'DOT' commands)
are present then EXECUTE assumes parameter
substitution will be used, and opens the temp file. If parameter
substitution is not used in any of your scripts, remove the period from the
first line and things will go faster.

3> EXECUTE creates a T directory and temp file in the CURRENT directory.
If you CD RAM: the temp file will be built in RAM:. The name of the
file is of the format "Command-0-T02" if you can freeze a EXECUTE in
progress you can look at it from another CLI. With V1.2 the T directory
will be created if it does not already exists. With V1.1 T had to
already exist.
So best for your startup-sequence would probably be a CD RAM: at the
start. No floppy will be written to, and things will be much faster.

// BCPL - Badly Coded Programming Language :-)
// BPTR - Batty-Pointer _or_ Brain-Damaged PoinTeR :-)
\\// AMIGA - Great except for the above two diseases. :-|

[Carolyn Scheppner CATS]

In article <0174526P@NAVPGS> 45...@NAVPGS.BITNET (LT Scott A. Norton, USN) writes:
>[]
> ...Just ASSIGN T: RAM: in the startup, and I can write

>protect my Workbench disk. A couple of questions for the net:
>
>- Am I harming myself subtley by not having t/ on a non-volatile
>device? I don't use ED, so I'm not worried about t/ed-backup

I always have T: assigned to a T directory in RAM: Haven't had any
problems at all except for (as you mention) losing t/ed-backup if I crash.

>
>- Why does EXECUTE need a t/ directory?

I some cases when Execute is passed args, it needs to create a temp
file (I believe it's related to the substitution of those args into the
script).

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Carolyn Scheppner -- CBM >>Amiga Technical Support<<
UUCP ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn
PHONE 215-431-9180
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

[pe...@topaz.berkeley.edu]

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

[Carolyn Scheppner CATS]

In article <35...@jade.BERKELEY.EDU> pe...@topaz.berkeley.edu (Pete Goodeve) writes:
>
>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:'!)

You're right. It works for me because my T: is also always my :T.
I am always CD'd to RAM:.