Amiga stuff for newbies

Be warned that this page is changing quite fast at the moment - I have a long
list of things I want to add to it. It's likely to get into a bit of a mess from
time to time until I work out what order to say things in.

The Amiga Utilities page will tell you where to find a variety of fundamental
Amiga utilities. Some of them, such as lha and installer, are simply vital,
and a number of others have effectively become standard parts of the
operating system - I should think very few serious Amiga users don't have
reqtools.library

I'm not trying to compete with the Amiga FAQ that appears in Amiga newsgroups
periodically - it covers all kinds of things that I don't plan to mention at
all. I'm also not trying to compete with manuals - this page is mostly for
people whose Amiga didn't come with one. There will definitely be plenty of
things missing from this page - e.g. instructions for the text editors and
Arexx, detailed syntax of commands, description of Workbench preferences
programs.

Basic use of Amigados and Workbench

I'll assume you have 3.something. If you don't, then go and get 3.1 right
now. I'm also assuming you know how to use a mouse, and how to use menus. I'm
prepared to believe that there are people in the world that don't know these
things, but I don't think a web page is the ideal place to learn (or
explain!) them. Plus, they're not Amiga-specific ideas. I'm also assuming you
know what files and directories are - they aren't Amiga-specific concepts
either.

If it turns out that there are people reading this who are new to computers in
general, I might change my policy. It does seem unlikely that there are, though,
doesn't it?

Making things happen every time you boot your machine

Assuming your machine hasn't already been drastically personalised, this is what
happens just after you turn it on or reboot it:

If the machine notices that both mouse buttons are pressed down, the Early
Boot Menu appears. You can do various drastic things to your machine with this.
My advice to inexperienced users would be to leave this feature alone unless
told to use it. It's useful for running very very old games if you have
a modern processor and/or CPU, or for forcing the machine to boot from a disk it
wouldn't normally boot from.

The bootable device with highest boot priority will be used to boot the
machine. This will generally be your internal floppy drive if there's a
bootable floppy in it, or a bootable hard disk otherwise. However, it's
possible to set up a reset-resistant bootable RAM disk if that's your idea of
fun. The boot disk will be given the name SYS:, and the following will also
happen:

sys:c will be called c:

sys:l will be called l:

sys:libs will be called libs:

sys:s will be called s:

sys:devs will be called devs:

sys:prefs/env-archive will be called envarc:

sys:fonts will be called fonts:

The ram disk, ram:, comes into existence

Various other things involving devices happen, I think

I don't know what order the above things happen in. I can't see that it makes a
lot of difference, since it all happens before you're able to do anything.

The instructions in the script s:startup-sequence are executed - this
makes various vital things happen.

The script s:user-startup is executed, if it exists. (Well, actually, this
is done because one of the last lines in s:startup-sequence makes it happen.)

Workbench (the GUI) is loaded (by s:startup-sequence, again), and programs
in sys:wbstartup are run

So if you want to make your machine do something automatically every time you
turn it on, you need to add a few lines to s:user-startup
or put a program in sys:wbstartup.

s:user-startup is a good place to put assigns. sys:wbstartup is a good place for
commodities - things like clicktofront, cycletomenu, magicmenu.

On the whole, you should only change s:startup-sequence if it's absolutely
necessary to do so. The whole point of s:user-startup is that it's where
you, the user, should put stuff that needs to happen before Workbench opens.
Things that need to run after Workbench opens should be in sys:wbstartup.

Devs: and Sys:Storage.. oh, and datatypes

Devs: is where you store disk drivers, printers, monitors, keyboards etc. you
want to be loaded at startup. Sys:storage is laid out in the same way as devs:
but the contents don't do anything automatically. You can
mount/load/whatever them manually if you want to. Stuff you never want to use at
all (e.g. printers and keyboards you don't own) shouldn't even be in sys:storage
- leave it on your WB installation floppies.

Datatypes are quite a good idea... though I've heard it said that the
implementaion is not brilliant. (I should admit to not really understanding
the issues here). They are descriptions of types of file that enable some
programs (notably sys:utilities/multiview) to understand any kind of data you
have a datatype for. You might as well dig through aminet and install every
datatype you can find that you think you're ever likely to want. (There will be
some that are so obscure you won't want to bother). This makes it possible to
use multiview a bit like the Windows "Drag'n'View" program - use
something like Toolmanager to make a drag-and-drop Multiview icon or window, and
drop files into it to see what's in them. You can, say, list the contents of lha
files, play sounds, examine graphics files, read normal text or hypertext, and
so on, all with multiview. You can even use it as a drag-and-drop lha file
expander if you want to. It sometimes doesn't do as good a job as a specialist
program would, perhaps. A virgin Amiga will have very few datatypes.

Irritatingly, to install a new datatype you have to put some stuff in
devs:datatypes, and some other stuff in sys:classes/datatypes. Some of the
datatypes on aminet make you do this by hand, others have install scripts.

I should probably warn you that devs: worked very differently under older
(pre-3.0? Pre-2.1? I went from 2.05 to 3.0 - I'm a bit vague about what 2.1
had in it) versions of amigados. Instead of the devs:dosdrivers directory, there
was one big file called devs:mountlist. And the other directories weren't there
at all (as far as I recall.). Very old programs that don't know about the new
layout of devs: might get a bit confused.

This is an area I don't know as much about a perhaps I ought to. Note that mfs,
referred to on my utilties page, creates subdirectories within devs:dosdrivers
to work its special magic.

The dosdriver file for RAD should probably stay in sys:storage unless you really
want a reset-resistant ram disk. And even if you do, there are others on aminet.
In the days of floppy-only systems, RAD: as a boot device made sense. Even
today it can be useful for some special purposes, but I don't think most people
would want it present on every boot. Mount it manually if you need it. And type
remrad to kill it.

Other customizations

Well, obviously you can run the programs in sys:prefs to change all kinds of
settings on your machine, but less obvious if you don't have a manual is the
file s:shell-startup. This is a script that is run every time you open a shell.
This is where you should put stuff like aliases.

General layout of system, and some useful amigados commands

Files and directories can have names up to about 30 characters long. The names
cannot contain the characters : or /. They can contain ;*()?`#[]<>~|$"%
but it makes a lot life easier if they don't, so pretend all these characters
are forbidden. Spaces are also allowed in file/directory names, but are
similarly best avoided for practical reasons. Use an underscore instead.
Amigados is case-insensitive, but remembers which case was used when a file or
directory was created/renamed. So MyFiLe and myfile are
the same file, but if you call a file MyFiLe, that's exactly how it
will appear in directory listings. This case-insensitivity fails for accented
characters unless the disk involved has a filesystem with International mode
turned on. I would suggest that when you format disks you always use
International mode. Directory caching mode should only be used with floppies,
I'm told. Probably a reasonable idea for, say, Zip disks as well, but I'm just
guessing.

Files only show up in workbench if they have icons associated with them, or if
"show all files" is turned on. Most files in sys: have no icons.
Compare my sys: normally with
my sys: with show all files turned on. Since
the icon associated with a file has the same name but with .info on the end, any
file you want to attach an icon to can't have a name more than 25 characters
long. You can make Workbench remember the position of an icon or the
size/position of a directory window by using the "snapshot" commands
in the Workbench Windows and Icons menus. This won't work on the fake icons
used for iconless files in "show all files" mode. Also, Workbench
doesn't like icons to be very close together, so if you snapshot very closely
spaced icons it may not actually work. You can "leave out" files or
directories so that they will appear to be on the desktop.

Open a shell (e.g. by choosing "execute command" from the Workbench menu and
typing newshell)

In the shell, type info. This will tell you what disks your machine
thinks are connected to it.

VITAL: press the up arrow key and you'll see that the amigados shell has
a history feature. you can use the up and down arrows to cycle through previous
commands. you can then edit a command and press return to execute it. This is
something you can't afford to miss out on.

Now type avail. This will tell you how much memory there is, and how
much of it is in use.

You probably won't use these commands much for your own purposes, but if you
need to ask someone for help, they are likely to want to know things about your
machine...

Disks will have a device name and a personal name. The internal floppy drive is
df0:, your main hard disk is probably dh0:, and so on. But if you have a
floppy called Homework you can refer to it as Homework:
without caring which floppy drive (if any) it is in. This makes it very easy to
copy files between two floppy disks if you only have one floppy drive.

You can use the assign command to create pretend disks. The system
does this itself in a big way: look in s:startup-sequence and you will see that
a number of assigns happen automatically. Some happen even earlier than
s:startup-sequence, as I said earlier.

Note that floppy disk names override assigns... so if you accidentally call
a floppy disk l, c, libs, fonts, devs, or some other name which clashes with
an important system assign, your machine will start to misbehave.

Many programs, when you install them, will add their own assigns to
s:user-startup. You may even want to add assigns of your own there. Say,
assign projects: dh0:work/architecture/current/projects as this would
obviously make life a lot easier.

You can also make several directories correspond to the same assign. You might
want to leave the system fonts directory alone and have a second directory with
your own fonts in it. assign fonts: work:myfonts add would be the
way to do this. You'll probably find that libs: in particular has quite a few
things added to it in this way in s:user-startup.

A few commands you obviously need:

copy

Copies files. e.g. copy blank.html to index.html. You can also
copy whole directories. e.g. copy mydirectory all to df0:

lists files with additional information such as size, date. The output from
this can be heavily customised with the lformat option, making
list extremely useful for automatic generation of scripts. I might
explain lformat in greater detail later. For the moment, I'd say see a manual
:-). But consider list down:ak#?.lha since yesterday lformat="lha x
down:%s" | execute in:. This will extract all lha archives in
directory down: whose names begin with ak and which were
created/modified within the last day or so.

cd

changes directory. do cd / to go up directory, cd
wibble to change to directory wibble and cd dh0:wibble/wotsit
to change to directory wibble/wotsit on drive dh0:. (In MS-DOS, for reasons I
don't understand, you can't cd to a directory on a different drive...). Type
cd on its own to find out which directory you're in now. This is
clearly silly in a shell since you can probably just look at your prompt, but
it could be useful in a script. cd // takes you up two directories
(and so on), and cd : takes you up as far as it's possible to go.

makedir

creates a new directory in the current directory

run

runs the rest of the line in the background, so your shell isn't locked up.
For example, run memacs letter will allow you to start editing
a letter in memacs and still be able to use the shell to do other things at the
same time.

newshell

opens a new shell. Of course, you'll probably want to do run newshell
otherwise your old shell will be locked and you might as well not have
bothered.

Many commands on the Amiga accept wildcards. Mostly, you can get by with knowing
that #? matches everything. So delete #?.txt will delete
all files with names ending in .txt.

But, just for the sake of it... here's how wildcards work:

()

groups things together - useful in combination with | and ~

~

means NOT. so ~(#?.info) matches everything which doesn't end in .info

|

Use this for an either/or choice. e.g. a.(txt|doc) will find a.txt and
a.doc

When the next character is normally a wildcard, ` makes it act normally.
This is necessary if you have files with #, ? etc. in their names. But you
probably don't want files like that - they're more trouble than they're
worth.

?

matches any single character. so a? matches all 2-letter words
beginning with a.

#

matches zero or more copies of whatever follows it. So b#a
matches b, ba, baa, and so on. And #? means any quantity of
anything... and will match everything.

Actually, the backtick, `, has another use. It can be used to embed the
results of one command in another. For instance, date tells you the
date and echo prints strings (only useful in scripts, of course).
So you could put echo "The date and time are `date`" to put
the output of date in the middle of the string echo has to
print. Another example could be using the backtick to with break and
status to interrupt a program without having to find out what its
process number was. I do this in my Miami logoff script:
As well as other commands, there's break `status command=Amitcp:bin/httpproxy`
c

The version command tells you what version of a file you have. e.g.
version reqtools.library will tell you which version
of that library you have. People you ask for help may need to know this sort of
thing. Note that with most files, version needs the full path name. Libraries
and devices are exceptions.

I suppose it's time to mention the command path... If you type path
you will be shown a list of all the directories amigados looks to find commands.
On the whole, you shouldn't need to worry about this - if programs need
something added to the command path, they'll probably change s:user-startup
accordingly when you install them. Still, you might very well want to add
something to the command path yourself for reasons of your own...

This is how it works... if you type a command, glooble, amigados goes
looking for a program called glooble that it can run. Where does it look? Well,
as you can see from the output from path, it looks in the current
directory, then in RAM:, then in sys:c, and then in various other places. If it
finds a program called glooble, it runs it. If it can't find it anywhere in the
path, you'll see glooble: unknown command . You could have various
files called glooble in several directories in the path... and of course the one
that runs when you type glooble will be the first one found. If you
want to know which file would be run when you type a given command, use
which.
For example, I discover via which tar that instead of running a new
version of tar, my machine is really using an old one in a different directory
that I'd forgotten I had. Oops.

You can type, say, version `which glooble` to find out what version
of the glooble command you're using, without needing to know the path.

If you want more directories in the command path, use something like path
dh0:myprog add in s:user-startup

Now some slightly less fundamental commands than in the previous list:
Type dir c: to find out what's in your c: directory.

alias

Used in s:shell-startup, mostly. (Won't work if used in s:user-startup,
since aliases only live as long as they shell they are used in. So they need to
be in s:shell-startup to work all the time.) This defines a new name or
abbreviated name for another command. You can even have an alias with the
same name as a command, and the alias takes priority. Put [] in the alias to
show where the rest of the user's input should be treated as being. See my
s:shell-startup for examples. Aliases don't always work - I think this must be
because some ways of running commands bypass s:shell-startup. In this kind of
case, writing a script instead would be the thing to do, I guess.

spat

This is in s:. It allows programs that don't understand wildcards to act as
though they do. So if glooble #?.txt doesn't work, try
spat glooble #?.txt. Useful in aliases and scripts.

changetaskpri

changes the priority of a program so it gets more or less of the cpu's
attention in case of heavy system load. Don't bother with this: use Executive
instead and task priorities will be changed for you. Well, you could use
changetaskpri to move a task outside Executive's sphere of influence. Don't
use priorities above 4 unless you are absolutely sure you know what you're
doing. Workbench runs at priority 1, and the default priority for user tasks
is 0. The full range is -128 to 127.

echo

As seen earlier, makes a script produce output.

ed

A text editor. Get something else, like Golded, to replace it.

memacs

Another text editor. Get something else, like Golded, to replace it.
Still, I had many happy years with memacs, and have personalised my copy of
Golded to use many memacs-like function key settings

endcli or endshell

closes a shell

execute

executes the commands in a script. shouldn't be necessary: see below

protect

changes the status flags on a file. do protect myfile add s to
add the script flag to a file. This enables you to execute it just by typing
myfile rather than having to type execute myfile. The
other flags include the obvious enough read, write, execute and delete, and the
somewhat obscure pure.

iconx

You can't run scripts from workbench just by double-clicking them. You need
to give them a default tool of iconx

join

glue files together. join part1 part2 as wholedocument

relabel

change the name of a disk

setpatch

You'll never actually type this. It's most likely the first line in
s:startup-sequence. It fixes various bugs in the operating system. Almost
nothing should ever get put before setpatch in s:startup-sequence. The latest
version is 43.6

stack

changes the size of the stack. only do this if told to.

type

one way of reading the contents of a text file

more

probably a better way of reading the contents of a text file. muchmore (see
much earlier) is even nicer.

wait

waits for some period of time. e.g. wait 30 secs or wait
until 13:00

fixfonts

run this from time to time just for the hell of it, and any time you add or
remove fonts. It makes sure the system's idea of which fonts it has corresponds
to reality.

;

any line starting with this is a comment

Something else you should know about is redirection. You can copy text from the
shell into the clipboard (rightamiga-C) and paste the clipboard into another
application (rightamiga-V) but even better is redirection.

You type command >filename and the output of the command, instead
of being displayed in the shell, will go into a file.

And if you do command >>filename, the output will be appended
to the end of the file rather than replacing the current contents.

So if someone wants to know some details of your system, you could type:

You can also throw the output away completely by redirecting it to
NIL:. This is a good thing to do in s:startup-sequence, as otherwise
windows pop up before the screen resolution settings have been loaded, and then
life gets very boring.

See also the stuff about pipes near the top of the page.

Screens and Windows

Windows live on screens, and an Amiga may have several screens open at one time.
The screens may have different resolutions or numbers of colours. You can click
on the bar at the top of a screen and drag the screen down to see what, if
anything, is behind it. Or you can click on the gadget in the top right-hand
corner of a screen to move it behind any other screens you may have open.
Pressing leftamiga-M will also move a screen to the back. Pressing rightamiga-N
pops the Workbench screen to the front. (This is only true in recent versions of
the amiga OS)

Windows also have a depth gadget in their top right-hand corner. It will move a
window to the front if it isn't already, or to the back if it's already at the
front. By default, the depth gadget is the only way of doing this - you need to
run clicktofront in sys:wbstartup to make it possible to bring windows to the
front by double-clicking in them. By default, windows become active if clicked
on once, but do not come to the front. If you want windows to be activated by
having the mouse pointer move over them, you can use autopoint. If you want
active windows to pop to the front automatically, you probably need to use an
option in MCP. (I dislike this particular feature of MS Windows and can't
imagine why anyone would want it. Still, I'm sure it's possible on an Amiga if
you want it). Naturally, if you have such a feature active, you don't need
clicktofront any more.

The gadget in the top left corner of a window is the close gadget. Closing a
window may not shut down the associated program - commodities in particular
don't stop running just because their windows are all shut. Check with Exchange
to see if there are invisible programs running.

Immediately to the left of the depth gadget is the resize gadget, which makes a
window alternate between its normal and alternative sizes. Some windows may have
other gadgets - e.g. an iconify gadget or a MUI preferences gadget, or
others.

Wbstartup

Here's a snapshot of my workbench. One of the
windows you can see is the result of choosing "Information" on the
Icon menu in Workbench. This is where you tell the machine what program should
be used to open a given data file, and other such things. Programs in
sys:wbstartup should all have the tooltype DONOTWAIT.

What sorts of things might you want to put in Wbstartup? Well, things like
clicktofront, which makes it possible to bring windows to the front by
double-clicking anywhere in them. (Set QUALIFIER=NONE in the tooltypes). I open
a shell via Wbstartup - it's the shell occupying the bottom half of the screen
in the snapshot above, and you can see its tooltypes in the info window.

Typing accented characters

sys:tools/keyshow will show you a map of your keyboard. Press the alt, shift and
Control keys, and the map will show you what characters can be obtained by
pressing them in combination with other keys. If a letter appears italic on this
map, it means you can put an accent on top of it. Press the alt key to see which
keys can produce accents. The details will depend on what kind of keyboard you
have, but on mine, alt-f prepares to put an acute accent on the next letter, if
that letter can have accents. so alt-f followed by e produces é on my keyboard.
Not all combinations work: alt-j n produces ñ, but alt-f n just produces a
normal n. Of course, if you have a keyboard with accented letters present on the
keys, you don't need to do this.

Sys:prefs

In sys:prefs you'll find the standard preferences-editing programs. Most of them
do fairly obvious things. I'll probably say more about them later on.
Third-party applications often park their preferences programs here too.
Settings files, and a lot of other things, get saved in sys:prefs/envarc, and
copied to env: early in s:startup-sequence. env: is in ram: by default, but if
you can make it be somewhere else by editing s:startup-sequence. (yes, I know I
said not to do this...).

Arexx

The Amiga used to come with a very bad implementation of BASIC. This was
replaced, in version 2 of amigados, with Arexx, an Amiga implementation of the
REXX programming/scripting language. Sadly, the Arexx manual that comes with,
e.g., Amigados 3.1, is not much use for learning the language, although it's ok
as a reference for the amiga-specific extensions. Programming in
Rexx, by Charles Daney, published by McGraw-Hill, is much more use to
actually learn REXX, and it's fairly easy to find in bookshops, either in the
real world (I've seen it in Dillons in the UK), or via on-line bookshops such as
Amazon or the UK
Internet Bookshop.

Arexx is an interpreted language. It's not as easy as BASIC, but amigados is set
up to use Arexx as an interprocess communication tool - quite a few applications
are set up to be able to use Arexx to talk to each other and the operating
system. amigados scripts and Arexx programs can call each other very easily:
many of my scripts are a mixture of arexx and amigados. REXX is also used on
IBM mainframes and in OS/2, so learning Arexx could turn out to be a useful
thing to do.

No doubt true Arexx experts would regard this as a hideous piece of programming,
but it's an Arexx script I wrote just today (27 Jan 1998). Since I have no
interest in demos and mods on aminet, I don't want my copy of the aminet index
to contain any reference to them. Since I automatically mergerec aminet weekly
updates with my index file, it tends to get contaminated with mods and demos. I
decided today I would try to fix this... and this is what I did:

/* script to remove mods and demos from aminet recent files */
/* call it via rx de-mod.rexx input output */
parse upper arg input output .
if open('oldfile',input,'read') then do
if open('newfile',output,'write') then do
do while ~eof('oldfile')
line=readln('oldfile')
if pos('demo', line, 20)=20 then iterate
if pos('smpl', line, 24)~=24 & pos('mod', line, 20)=20 then iterate
writeln('newfile', line)
end
end
end
exit

You call this by typing rx de-mod.rexx oldfile newfile. It goes
through oldfile a line at a time, copying the lines to newfile. However, if a
line in oldfile has mod or demo 20 characters into it then
that line is skipped. (Actually, mod/smpl will be kept since I don't mind sound
samples.)

The context in which I use this is the following (extract from an) amigados
script:

because I had a lot of .WAV files which had been created on an MS-DOS machine
and thus had incomprehensible 8.3 filenames. This amigados script, called via,
say list #?.wav lformat="tweak %s" | execute in: will play me each
WAV, and then pop up a requester which will let me edit the old name into
something I think is more suitable. This uses the rexxreqtools library referred
to at the top of the page.