Continuing our look at the Workbench, we dealt with all the
majority of the visible icons last month. Now we'll take a
look at those files which don't have icons: they are all
hidden until you get down to Shell level or use the "Show...
All Files" Workbench menu option.

By the way, a program such as Directory Opus is particularly
useful when it comes to exploring Workbench like this, as it
allows you to move from directory to directory and examine
the contents with only one or two clicks of the mouse.

 C
---

(m1.iff)


The C directory is very important, as this is where all the
AmigaDOS commands hang out. Most of the commands you can
type at the Shell are really unique programs, and this is
where they are stored. If you open a Shell window and enter:

cd c:

then you'll have moved from the default directory to the C
directory. You can then type:

dir

to see a list of all the files present. (m2.iff) On older Workbench
systems, the command "cd" was itself stored in this
directory. Newer versions of the operating system, as used
in Amiga 1200s for example, have this command -- and others
-- built in to the OS Kickstart ROM. These commands are
referred to as "resident". You can get a list of these
resident commands by opening a shell and entering:

resident

The command will return a list of the built-in commands.
It's also possible to temporarily make other commands
resident too. You do this by including their full path and
name after the command, like this:

resident c:list



Be Pure, Be Vigilent, Behave
----------------------------

Except this won't work and will return an error message --
because the List command isn't totally "pure". Yes, another
complication. A pure command is defined as one which is
re-entrant and re-executable: in other words, it can be used
again and again and several times at once without going
wrong. In Workbench 3 almost all the commands which are Pure
have already been made resident. You can check by using the
list command, and watching out for the "p" flag appearing
next to any filenames.

However, you can force a command to be made resident. In
most cases this won't be a dangerous thing, but be aware of
the potential for crashing if you multitask or run critical
software: a bulletin board for example.

To force a command to become resident, no matter what, use
the option Pure, like this:

resident c:list pure

This makes a command resident, and states that you are
prepared to risk the consequences.

But why make a command resident in the first place? Speed is
the answer: it can make long AmigaDOS scripts a lot faster
if the Operating System doesn't need to spend most of the
time tracking down the commands themselves. A good example
is the startup-sequence. This script even forces several
non-Pure commands resident in the quest for more speed. Look
out for the line:

Resident >NIL: C:Assign PURE

and look out to see why the command doesn't remain resident
after the script has ended. Resident commands also take up
less memory that commands held, for example, in RAM disk. No
matter how many times the command is executed only one
instance of it is used at a time.

Here's a neat little trick. As resident needs the full path
to a command, you can make use of the "which" command to
discover it. At last! A use for "which"!

You can combine the "which" command with the resident
operating using the "tick" (press the ordinary ' key whilst
holding down ALT) to get something like this:

resident `which list` pure

Of course when you switch off the Amiga, the resident
commands which you have created will all be lost.

(m3.iff)



 S
---

(m4.iff)


The s directory is where Scripts are kept, or at least that
was the intention. It's where you will find the
startup-sequence file, and also the user-startup script too.
After many years of use, my Amiga has amassed a staggering
collection of junk in this directory as many programs have
kindly installed useful scripts here for me.

The Art Department has left many files -- mostly in the form
of ARexx programs -- and so have Spot, Mosaic and Cygnus Ed.
Scripts don't take up a great deal of space, and so on a
hard drive system these is little to be gained by deleting
them. Some day they might be needed.

A script, by the way, is simply a text file containing
AmigaDOS commands. You can write your own script using an
text editor, including Ed the standard AmigaDOS editor.
Simply add a list of the commands you wish to be used.

Using the script can be done in two ways. You can either use
the "execute" AmigaDOS command like this:

execute s:my-script

Or you can alter one of the file's flags (special switches
to tell the OS how to deal with the file -- like "Pure" for
example) to define it as a script. If it's defined as a
script, you only need to enter the name by itself, like
this:

my-script

Here is how you would alter the flag to make an ordinary
text file into a script:

protect s:my-script +S


An ARexx script is slightly different in that it cannot be
executed with the Execute command. It's not a list of
AmigaDOS commands, but a program written in the ARexx
language. We dealt with ARexx in some detail in previous
Masterclass tutorials.


(m5.iff) Using List you can check on the various flags
associated with each file. You will probably has less files
than I have: you will probably take more care to keep your
hard disk tidy than I do!



libs
----

(m6.iff)


The libs drawer is the default location for any Amiga
libraries. A library in this sense is a file which contains
various sub-routines. By storing the routines in a library,
they are available to other programs and other multitasking
copies of the same program.

Even the libs drawer of a new Amiga will contain a selection
of libraries, including maths routines and ARexx code. After
a while the directory will be stuffed with libraries as
program after program adds it own routines to the list.

If you have deleted an unwanted application, have a quick
look here to see if it has left a libary. Before you delete
it for good, rename it and check if any other programs are
making use of it.





box out: How does it do that?

You might be wondering how a command like "dir" can be
executed when you aren't already in the directory in which
it is stored.

For example, how come when you open a shell you can enter
"dir" no matter if the default directory is Workbench or
Ram:. You might have thought it would be necessary to
include a full path, like  this:

cd ram:
c:dir

However, a full path to the command is not needed, so this
will work just as well:

cd ram:
dir

A special command called "Path" makes this possible. If you
look in the startup-sequence, you'll spot the rather heavy
duty line:

Path >NIL: RAM: C: SYS:Utilities SYS:Rexxc SYS:System S:
SYS:Prefs SYS:WBStartup SYS:Tools SYS:Tools/Commodities

This command sets up the paths which the operating system
follows when it ecounters a command. When you enter an
instruction such as "dir", the operating system first looks
in the current directory (this is the default action). It
then looks in "RAM:" then "C:" then "sys:utilities" and so on.

Before you ask, the Path command itself is a resident
command and so it doesn't matter where it is stored!

-- end --