************************************************ * * * COMMAND PROCESSES * * ----------------- * * by Paul Mclachlan * * * ************************************************  ## 26 ## 26 ## 26 ## 26 ## 26 ## 26 ## 26 ## 26 ## 26 ## 26 ## 26 ## After reading all the manuals that you got with your Amiga, and still ending up confused, you get frustrated. Why? Because the manual doesn't explain commands expecting you to be a beginner. It explains commands expecting you to be an expert, having read every piece of documentation ever produced on Workbench 1.2, and so it feels it could just mention the CHANGES in the 1.3 manual. Well, I never. Anyhow, here I will begin to fix this problem by explaining two of the more harder to grasp commands in your standard C directory, and also the RUN command. Which is related, sort of, to the other two I will explain. All of these commands are explained poorly in the 1.3 enhanced manual. Firstly, however, I will explain some about these processes.  PROCESSES The Amiga is a multitasking machine. I'm sure you have all heard or read this term somewhere. This means that the Amiga can do several things at once. On the Amiga, you can use a word processor, while your spreadsheet is crunching numbers, and so on. This is limited by the available memory of your computer. That is, you can only have as many programs running as you have memory for. If you had 2 megabytes (gee, wish I did) then you could run two programs requiring 1 megabyte of memory. Although a lot of programs require less than 100k, and even an unexpanded 500 could run a few of them. Each program that you have running is given a process number. When you start your computer, you have only one thing running, that is the initial CLI (a window with AmigaDOS written in its title). This window displays some text, like the Commodore copyright message, and so forth. It is given the process number one. Once workbench is loaded, this process ends, and there are no CLI windows. There is only the workbench process left. This was created by CLI process one. If you open a CLI from workbench, then this CLI will be process 1. If, now, you open another one, then this one will be process 2. From your two windows, you can type commands, as usual. You can make as many CLI processes as you have memory for. From each CLI process, you can load and run a program. Notice, that when you run, for example, the clock, in your utilities drawer, that you can no longer enter commands in the CLI that started it. This is because the CLI that started its process was taken from it, and used for clock. When clock is closed, that CLI will become active again, enabling you to enter commands once more. A CLI's process number can be read as the number at the beginning of the prompt. eg, "1.>" THE RUN COMMAND The 'run' command, when used from CLI creates what is known as a BACKGROUND PROCESS. A background process is like a new CLI, but it works without the CLI window appearing. Entering: run command does the equivalent of the following. It opens a new CLI window, creating a new process. This new process then runs the program command, therefore leaving the first CLI window free to use more commands. Do you understand that? I hope so. Now, the run command is a little more refined than what I actually told you above. I confess, I told a white lie to enable you to understand this better. The run command does do the above, but it doesn't open the window. It simply creates the process. That is why it is called a background process. This background process disappears once the program it was running ends. There is no indicator that a process was opened, except for a little message in the CLI window. (Even that can be suppressed, but that is more advanced than I will go into in this tutorial.) This message will look something like: [CLI 3] This indicates to the user that a background process has be created, and it is process three. THE STATUS COMMAND This command, simply shows what every CLI process is doing. If you entered this command in CLI window 1, and had run clock also from this window, you would see output something like this: 1> status Process 1: Loaded as command: status Process 2: Loaded as command: df0:utilities/clock 1> This means, that when status was run, process 1 was running status. (Obvious, you just told it to.) And also that process two was running clock, on the disk that was in the internal drive, and in the utilities directory. Even though there is no window for CLI process 2, there is a command loaded into it, thanks to the run command, above. THE BREAK COMMAND Okay, so we have got to grips with processes fairly well, and we know how to list what's in each process. But consider this problem. You decide you want to listen to some music, while you work away at the CLI. You go and get your trusty MED disk, and run the medplayer. It prints a message up, telling you to hit Control-C to stop the music. Everything appears to have worked fine. You listen to the tune, and finish of your work in the CLI. Now you want to exit the MedPlayer. You hit control-c, but the music continues. Why? because it is a background process, and you can't enter any commands into that process. It's a lot like having the window unselected, and then typing a comand. How do we solve this problem? Well, reboot would be a good guess, although not quite correct. AmigaDOS has the answer once more, with the break command. The BREAK command allows you to send a control character to any process. Such as control-c to stop Med, or control-D to stop a script file. (For an example of use, see the standard workbench startupII script. The first process executes the startupII file, and then waits for five minutes, to avoid disk thrashing. This five minute break is much longer than is needed, and so when the startupII file reaches the end, it executes a Break 1 C, sending a control-c combination, exiting the wait command, an the original startup-sequence continues as normal.) The format of this command is: break can be replaced by a number corresponding to the number of the process you want to send the control character to. can be replaced a C, a D, an E or a F. The final code that you can use here is all, which sends a C, a D an E and an F to the process number specified. Little end bit: For future use, here are the descriptions provided by Commodore for these commands: BREAK: BREAK [ALL|C|D|E|F] To set attention flags in the specified process. STATUS: STATUS [FULL] [TCB] [CLI|ALL] [COMMAND] To list information about the CLI/SHELL processes. RUN: RUN [+ ] To execute commands as background processes. I was perhaps a little unknowing when I picked on MEDPlayer. I do believe it automatically detaches itself from the CLI, and therefore wouldn't need a break to use a control-C. This was only an example of the possible use of the command outside of script file use. The command break often comes in useful if a CLI process locks up.  ## 26 ## 26 ## 26 ## 26 ## 26 ## 26 ## 26 ## 26 ## 26 ## 26 ## 26 ##