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.
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?
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.
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.
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.
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
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:
But, just for the sake of it... here's how wildcards work:
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.
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:outputand 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.
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.
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.
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.