Article 10: AmigaDOS in Depth – Scripts, Redirection, Pipes, Patterns and Command Templates 

In Article 9, we introduced the Amiga Shell and some of the most important AmigaDOS commands. 

We used commands such as:
Dir
List
Copy
Delete
Assign
Type

Execute But AmigaDOS becomes much more interesting when we move beyond individual commands. Commands can receive parameters, operate on groups of files, redirect their output, communicate through pipes and be combined into scripts. In this article, we will look more closely at these features and see how the Amiga Shell can be used as a powerful working environment. 

1. Commands and Arguments 

Most AmigaDOS commands consist of the command name followed by one or more arguments. 

For example:
Copy oldfile newfile 
The first word:
Copy identifies the command. 

The remaining words are arguments telling the command what it should do. 

Another example is:
Dir SYS:C 
Here: Dir
is the command and:
SYS:C is the directory we want to examine. More complicated commands can accept several arguments and options. This is where command templates become important. 

2. Understanding Command Templates 

Many AmigaDOS commands describe their arguments using a template. For example, a simplified template might look like:
FROM/M,TO/A,ALL/S,QUIET/S 

At first sight, this looks rather mysterious. It becomes much easier when we divide it into parts:
FROM/M
TO/A
ALL/S
QUIET/S 

Each entry represents an argument that the command understands. 

3. Required Arguments with /A 

The modifier:
/A 

means that an argument is required. 

For example:
TO/A 

means that the command requires a destination. If an essential argument is missing, the command cannot perform the requested operation. This provides AmigaDOS commands with a standardized way of describing their parameters. 4. Switches with /S A switch enables or disables an option. 

For example:
QUIET/S means that QUIET behaves as a switch. You do not normally supply another value after it. 

You simply specify:
QUIET or omit it. 

Conceptually:
Command means normal operation, while:
Command QUIET means run the command with the QUIET option enabled. 

Another commonly encountered switch is:
ALL 

which, depending on the command, can tell it to process directories recursively or operate on a broader set of objects. 

5. Keyword Arguments with /K 

A keyword argument requires you to specify the corresponding keyword. 

Imagine a command template containing:
NAME/K 

You would then use something conceptually like:
NAME value 

rather than relying only on the position of the argument. This makes complex command lines easier to understand. 

Compare:
Command data 20 anothervalue with:
Command NAME data SIZE 20 

The second form makes the role of each value much clearer. 

6. Numeric Arguments with /N 

The modifier:
/N 

indicates a numeric argument. 

For example:
COUNT/N 

tells the command parser that the corresponding value should represent a number. This is useful because commands do not have to interpret every argument simply as arbitrary text. 

7. Multiple Arguments with /M 

The /M modifier indicates that more than one value can be provided for an argument. 

For example:
FILES/M 

could represent a list of files.

 Conceptually:
file1 file2 file3 can be treated as multiple values belonging to the same argument. This becomes particularly useful for file-oriented commands. 

8. Asking a Command for Its Template 

One useful feature of the Amiga Shell is the ability to inspect the argument structure expected by many commands. 

For example, try:
Copy ? or:
List ? or:
Delete ? 

The command can show its argument template. This means you do not always need to remember every option. If you forget how a command is structured, the template gives you an immediate clue. Learning to read templates is therefore one of the most useful AmigaDOS Shell skills.

9. Filename Patterns 

Operating on one file at a time would quickly become tedious. 

Suppose a directory contains:
article.txt
notes.txt
commands.txt
picture.iff
logo.iff
program 

You may want to select only certain files. This is where AmigaDOS pattern matching becomes useful. One of the most important Amiga patterns is: #? 

For beginners, it is useful to think of it as: Match any sequence of characters. 

For example:
#?.txt can match names such as:
article.txt
notes.txt
commands.txt 

while excluding:
picture.iff
logo.iff 

10. Amiga Patterns Are More Than Simple Wildcards 

It is tempting to think of:
#? 

as simply the Amiga equivalent of * on many other systems. For basic usage this mental shortcut can help, but technically AmigaDOS uses a pattern-matching system rather than merely a simple wildcard character. The two symbols have their own meanings. ? represents a single arbitrary character in a pattern. The # operator represents repetition of the following pattern element. 

Together:
#? 

therefore produce the familiar "match arbitrary text" behaviour. This distinction becomes useful once you begin writing more sophisticated AmigaDOS patterns. 

11. Using Patterns with Files 

Imagine that RAM: contains:
file1.txt
file2.txt
file3.txt
picture.iff
program 

A pattern such as:
#?.txt 

can identify the text files. This makes it possible for commands that support pattern matching to work with groups of related filenames rather than requiring every filename to be entered manually. 

Patterns are especially useful when working with:
file extensions
numbered files
groups of related files
Workbench .info files
large directories

12. Why .info Files Often Appear in Shell 

Work Workbench icons normally use files ending with:
.info 

For example, you might see:
MyProgram
MyProgram.info The first file could be the actual program. The second contains information associated with its Workbench icon. 

A pattern such as:
#?.info 

therefore becomes particularly useful when examining Workbench directories from the Shell. The Shell exposes files that Workbench normally presents through its graphical interface. 

13. Input and Output 

Every Shell command can potentially interact with three important concepts:
Input
Output
Error output Normally, the Shell provides input and displays output in its window. 

Conceptually:

Keyboard
   |
   v
Command
   |
   v
Shell window 

But AmigaDOS allows these data streams to be redirected. That opens up many possibilities. 

14. Redirecting Output to a File 

Suppose you execute:
List SYS:C 

Normally the result appears in the Shell window. But sometimes we want to save the result. Output redirection allows us to send command output somewhere else. 

A typical operation can look like:
List SYS:C >RAM:commands.txt 

The idea is:
List SYS:C
     |
     | output
     v
RAM:commands.txt 

Instead of using the screen as its destination, the command output is written to the file. You can then examine it using:
Type RAM:commands.txt 

15. NIL: – The Amiga's Data Sink 

Sometimes we want the opposite. We do not want to save the output and we do not want to see it. AmigaDOS provides:
NIL: for this purpose. For example, you may encounter:
>NIL: inside startup scripts. 

Conceptually:
Command
   |
   | unwanted output
   v
NIL:
   |
   X The output is discarded. 

NIL: is particularly useful in scripts where informational messages would otherwise clutter the screen. 

16. Redirecting Input 

Redirection can also work in the other direction. Instead of receiving its input interactively, a suitable command can receive input from another source, such as a file. 

Conceptually:
File
 |
 v
Command 

This allows Shell commands to operate non-interactively and is especially useful in scripts. The important idea is that input and output do not always have to involve the keyboard and Shell window. They can be redirected to other AmigaDOS resources. 17. PIPE: – Connecting Commands Another interesting AmigaDOS concept is:
PIPE:

 A pipe allows output produced by one process to become input for another. 

The concept looks like this:
Command A
    |
    | output
    v
  PIPE:
    |
    | input
    v
Command B

 Instead of first writing intermediate information to a normal disk file, a pipe provides a communication path between processes. Depending on the AmigaOS version and configuration, pipe support and syntax can differ, so it is important to check the environment you are using. But conceptually, the idea is simple: The output of one process can become the input of another. 

18. What Is a Shell Script? 

Typing commands manually is useful for interactive work. But imagine that every time your Amiga starts you want to perform the same ten commands. Typing them repeatedly would make little sense. 

Instead, we can store commands in a text file:
Echo "Preparing the system"
Assign DATA: Work:Data
Dir DATA:
Echo "Ready" 

This text file becomes a command script. It contains a sequence of Shell commands that can be executed automatically. 19. Execute The AmigaDOS command:
Execute is used to execute command files. 

For example, suppose we create:
S:MyStartup 

The file might contain:
Echo "Starting my setup"
Assign DOCS: Work:Documents
Echo "Setup finished" 

It could then be executed with:
Execute 

S:MyStartup AmigaDOS reads the script and interprets its commands. 

20. Startup-Sequence Is a Script 

We already encountered the most important real-world example:
S:Startup-Sequence 

During boot, AmigaDOS executes a series of commands that establish the operating-system environment. The Startup-Sequence is therefore not merely some mysterious configuration file. It is fundamentally a command script. 

This is why it can contain commands such as:
Assign
SetPatch
Mount
LoadWB 

and other operations required by the installed version of AmigaOS. Once you understand Shell scripts, reading Startup-Sequence becomes far less intimidating. 21. User-Startup Another startup-related file often encountered on classic AmigaOS installations is:
S:User-Startup This provides a convenient location for additional startup commands. Software installers have historically used it to add things such as assigns required by applications. 

For example, an application might require a logical name such as:
MYPROGRAM: 

pointing to its installation directory. A startup script can create that assign whenever the system boots. 

Conceptually:
Boot
 |
 v
Startup-Sequence
 |
 v
User-Startup
 |
 v
Application-specific configuration 

The exact startup arrangement depends on the AmigaOS version and configuration, but the general idea is important. 

22. Echo 

When writing scripts, one of the simplest useful commands is:
Echo 

For example:
Echo "Starting configuration..." 

It can display information to the user. 

A script might therefore look like:
Echo "Creating assigns..."
Assign DOCS: Work:Documents
Assign DATA: Work:Data
Echo "Done." 

Messages like these become particularly useful when troubleshooting. You can see how far the script progressed before a problem occurred. 

23. Variables 

Shell scripts become more useful when information can be stored in variables. Conceptually, we might want to associate a name with a value:
NAME = value AmigaDOS provides commands and environment mechanisms for working with variables. 

This also connects to the system we discussed earlier:
ENV: and:
ENVARC: 

The distinction remains important:
ENV: current environment
ENVARC: persistent environment 

A value intended only for the current session does not necessarily need to survive a reboot. A persistent setting must be stored appropriately. 24. Script Arguments Scripts do not always have to perform exactly the same operation. They can also work with arguments supplied when the script is executed. 

Conceptually, instead of having:
Execute MyScript a script could be designed to work with something like:
Execute MyScript Work:Documents 

Now the same script can operate with different input. This turns scripts from simple lists of commands into reusable tools. 

25. Conditional Execution 

More sophisticated scripts can make decisions. 

Conceptually:
IF something is true
    perform command A
ELSE
    perform command B
ENDIF 

This can be used to let a script react to different situations. For example, a script might check whether a directory or file exists before attempting another operation. This turns AmigaDOS scripting into a basic programming environment. 

26. Why Error Handling Matters 

Imagine a script that assumes:
Work:Data always exists. 

If it does not, later commands could fail. Good scripts therefore need to consider what happens when: 
a file does not exist
a disk is missing
an assign has not been created
a command cannot be found
an operation returns an error

When reading more sophisticated Amiga scripts, you may therefore encounter commands and constructs concerned with return codes and execution control. This is one of the points where the Shell starts moving beyond simple command execution into actual scripting. 27. Commands Return Results When a command executes, there is more happening than simply printing text. Commands can also report whether an operation succeeded or failed. 

Conceptually:
Command
   |
   +---- output
   |
   +---- return status 

Scripts can use the return status to decide what should happen next. This is extremely important for automation. A script should not merely execute commands blindly. It can respond differently depending on whether earlier operations succeeded. 

28. A Practical Script 

Let's create a simple example using the safe RAM: environment. Imagine the following script:
Echo "Creating test environment"
MakeDir RAM:AmigaTest
Copy S:Startup-Sequence RAM:AmigaTest/
Echo "Directory contains:"
Dir RAM:AmigaTest
Echo "Test completed" 

The sequence is straightforward. 

Step 1
MakeDir RAM:AmigaTest creates a directory.

 Step 2
Copy S:Startup-Sequence RAM:AmigaTest/ copies a file into it. 

Step 3
Dir RAM:AmigaTest shows the result. 

Step 4 Echo commands explain what the script is doing. 

Even this simple example demonstrates an important idea: Several manual Shell operations can be packaged into one repeatable process. That is the foundation of automation. 

29. Why RAM: Is Excellent for Experiments 

While learning AmigaDOS, RAM: is an excellent place to experiment. You can create:
RAM:Test copy files there, rename them, generate temporary output and experiment with scripts. Because RAM: resides in memory, its normal contents are temporary. 

That greatly reduces the temptation to experiment directly with important system directories such as:
SYS:
C:
DEVS:
LIBS:
S: 

When learning, it is always better to understand a command before applying it to important system files. 

30. The AmigaDOS Toolbox 

We can now expand the collection of concepts introduced in Article 9:

Commands
    |
    +-- Arguments
    |
    +-- Templates
    |
    +-- Patterns
    |
    +-- Redirection
    |
    +-- Pipes
    |
    +-- Variables
    |
    +-- Scripts
    |
    +-- Conditions
    |
    +-- Return codes 

At this level, the Shell is no longer merely an alternative to Workbench. It becomes a tool for automation and system control. 31. Workbench vs Shell Workbench and the Shell provide two different ways of looking at the system. 

Workbench emphasizes:
Icons
Drawers
Drag and drop
Graphical applications The Shell emphasizes:
Commands
Paths
Patterns
Streams
Variables
Scripts
Automation 

Neither approach makes the other unnecessary. In fact, experienced Amiga users often combine them. You might use Workbench to organize files visually and then open a Shell to perform a repetitive operation much more efficiently. 32. What We Have Learned So Far Our journey through AmigaOS now connects several layers of the system. 

We started with the hardware:
CPU
Chip RAM
Fast RAM
Custom chips
Bus
DMA 

Then we followed the machine through the boot process:

Kickstart
      ↓
Exec
      ↓
Hardware initialization
      ↓
AmigaDOS
      ↓
Startup-Sequence
      ↓
Workbench 

We then explored the operating-system structure:
Libraries
Devices
Handlers
Assigns
System directories 

And finally we reached the command environment:

AmigaDOS
   |
   v
Shell
   |
   +-- commands
   +-- patterns
   +-- redirection
   +-- scripts 

This means we now have a reasonably complete picture of how the major parts of a classic Amiga system fit together. Conclusion AmigaDOS becomes much more powerful when we move beyond individual commands. Command templates describe how commands accept arguments. Patterns allow groups of files to be selected. Redirection allows input and output to be routed to files or special resources such as:
NIL: Pipes allow data to move between processes. And scripts combine commands into repeatable procedures. Perhaps the most important lesson is that many of these mechanisms are not isolated Shell tricks. 

They reflect the architecture of AmigaOS itself. Names such as:
RAM:
NIL:
PIPE:
ENV: 

show how AmigaDOS can present very different resources through a common naming environment. The Shell therefore gives us something Workbench cannot provide quite as directly: a view into the logical structure of AmigaOS. Next: Article 11 – Amiga Multitasking: Tasks, Processes, Signals and Message Ports The next logical step is to go deeper into Exec itself. We can examine how the Amiga performs preemptive multitasking, what the difference between a task and a process is, how signals work, and why message ports and message passing are so fundamental to the design of AmigaOS.