Amiga stuff for newbies

NB: The Amigados Online Reference Manual is much better than my page!

Last changed 18 April 1998.

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:

  1. 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.
  2. 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:

    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.

  3. The instructions in the script s:startup-sequence are executed - this makes various vital things happen.
  4. 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.)
  5. 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.

here's my s:shell-startup:

execute s:netcommands
; $VER: shell-startup 38.13 (13.2.92)
echo noline "*e[1;1H*e[J*e[6x*e[15y"
prompt "*e[1;31;43m%n*e[0m*e[31;43m.%s*e[0;31;40m>*e[0m "
Alias Clear "Echo *"*E[0;0H*E[J*" "
Alias Copy "Copy [] CLONE "
cd scratch:
set _pchar "|"
set _mchar "\"
alias play play16 >nil: [] fast output paula14c
alias mm muchmore
alias dirid copy env:sys/def_drawer.info to [].info
alias nuke xpack method nuke []
alias shrink xpack method shri []
alias detar tar -xvpf []
alias detgz tar -xvzpf []
alias dviprint dviprint -d=generic 
alias tex tex:bin/virtex-big-20 &plain
alias latex tex:bin/virtex-big-20 &latex
alias gs ghostscript:gs -sDEVICE=bjc600 -r360x360 -sPAPERSIZE=a4 -dNOPAUSE -sOutputFile=PAR:
alias ghostview ghostscript:gs -sDEVICE=amiga_custom "-sDisplayMode=DBLPAL:High Res No Flicker" -r100x100 -dNOPAUSE
alias dvips dvips -D 360
alias uudecode uuxt x []
alias qt qt [] ham8 dither wcenter

which I think should give you some idea of what it's useful for

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:

delete
Deletes files. e.g. delete uglyfile.txt. You can also delete whole directories. delete horribledirectory all.

rename
renames things. rename thisfile as thatfile

dir
shows you what is in a directory.

list
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

[]
put this round a letter range. e.g. [a-d].txt will match a.txt, b.txt, c.txt and d.txt

%
matches the null string. useful in cases like a(b|c|%)d.

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

avail >ram:output
info >>ram:output
dir >>ram:output libs:
path >>ram:output
version >>ram:output
and then insert ram:output into an email message.

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:

if exists scratch:recent
copy scratch:recent to ram:
rx s:de-mod.rexx ram:recent ram:doofus
delete ram:recent
rename ram:doofus as ram:recent
copy work:internet/index to ram:
mergerec ram:recent ram:index rep
delete scratch:recent
delete ram:recent
copy ram:index to work:internet
delete ram:index
endif

which is part of my Miami "post-login" script. The file scratch:recent is created by Thor whenever an Aminet mailing-list message arrives.

Another minimalist rexx script is:

/* newname.rexx - ask for new name for file */
addlib('rexxreqtools.library',0,-30)
parse arg oldname
newname=rtgetstring(oldname, "New name for this file?","New name")
address command "rename " oldname "as " newname

which I used in this context:

(this file is called s:tweak)

.key filename/A
.bra {
.ket }
play16 {filename}
rx newname.rexx {filename}

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.


ghira@mistral.co.uk