Article 15: AmigaDOS and the Shell in Depth 

How Commands, Processes and the DOS Environment Work In the previous article, we explored the modular architecture of AmigaOS and saw how libraries, devices, resources and handlers work together. 

One particularly important component was:
dos.library 

DOS provides many of the services applications use for working with files, directories and processes. But users also encounter DOS through another important part of the system: The Amiga Shell The Shell is much more than a place where commands can be typed. It is an interface to many of the services provided by AmigaDOS. In this article, we will look at how the Shell, commands, processes, DOS and the filesystem work together. 

1. What Is AmigaDOS? 

AmigaDOS is the part of AmigaOS responsible for many services involving:
files
directories
volumes
processes
command execution
input and output
filesystem access
path handling
DOS devices
environment variables

Applications normally access these services through:
dos.library 

A simplified architecture looks like this:

                 Applications
                      |
                      v
                 dos.library
                      |
        +-------------+-------------+
        |             |             |
      Files       Processes      Handlers
        |                           |
        +-------------+-------------+
                      |
                      v
                  Filesystem
                      |
                      v
                   Device 

The Shell is another client of these DOS services. 

2. What Is the Amiga Shell? 

The Shell is a command-line interface. Instead of controlling the system by clicking icons, the user types commands. 

For example:
1> DIR or:
1> COPY Work:Test.txt RAM: or:
1> INFO The Shell interprets the command line and starts the appropriate command. 

Conceptually:

User
 |
 | command
 v
Shell
 |
 | start command
 v
AmigaDOS
 |
 v
Command process 

The important point is that the Shell itself does not contain all these commands. Many commands are separate programs. 

3. Shell Commands Are Often Programs 

If you enter:
DIR 

it may look as though DIR is simply a built-in feature of the Shell. But many AmigaDOS commands are separate executable programs. 

They are commonly stored in:
C: For example:
C:Dir
C:Copy
C:Delete
C:List
C:Assign 

This is why the C: assignment is so important to AmigaDOS. 

Conceptually:

Shell
  |
  | "DIR"
  v
Find command
  |
  v
C:Dir
  |
  v
Execute program 

This keeps the command environment highly modular. 

4. C: Is an Assignment 

One important characteristic of AmigaDOS is that names such as:
C:
S:
L:
LIBS:
DEVS:
T:
ENV: are not necessarily physical disk drives. 

They are usually assignments. 

For example:
C: refers to the location containing system commands. 

Typical assignments include: 

C:Commands
S:Scripts and startup files
L:Handlers and filesystem modules
LIBS:Libraries
DEVS:Devices and system files
FONTS:Fonts
T:Temporary files
ENV:Environment variables 

This is one of the most flexible parts of AmigaDOS. 

5. Assignments 

Versus Physical Volumes 

Consider a hard disk called:
Workbench: 

The system may contain:
Workbench:C
Workbench:S
Workbench:Libs
Workbench:Devs 

AmigaDOS can create assignments such as:
C:     -> Workbench:C
S:     -> Workbench:S
LIBS:  -> Workbench:Libs
DEVS:  -> Workbench:Devs 

Applications do not necessarily need to know where the directories physically reside. 

They can simply access:
LIBS: 

This creates a useful abstraction. If the physical location changes, the assignment can be changed while applications continue using the same logical name. 

6. The Assign Command 

Assignments can be managed with the Assign command. 

For example:
Assign Tools: 
Work:Utilities 

Afterward:
Tools: refers to:
Work:Utilities 

You could then enter:
CD Tools: 

without needing to know the actual physical location. This mechanism became extremely useful for applications and games. Many programs expect their files under a specific logical name. 

7. Volumes 

AmigaDOS also understands volume names. 

A floppy disk might be called:
Workbench: or:
Games: 

A hard-disk partition might be:
System: 

These names refer to actual mounted volumes. 

This gives us an important distinction:
DF0: represents a DOS device name.
Workbench: may represent the volume currently inserted or mounted there.
C: normally represents an assignment. 

All three use the colon syntax, but they do not represent exactly the same thing. 

8. Paths in AmigaDOS 

AmigaDOS paths differ somewhat from modern Windows and Unix paths. 

For example:
Work:Documents/Text.txt 

means:
Volume/Assign
     |
     v
Work:
     |
     +-- Documents
            |
            +-- Text.txt 

The colon separates the device, volume or assignment from the rest of the path. 

Subdirectories use:
/ 

Therefore:
DH0:Utilities/Graphics/Viewer refers to a program called Viewer inside the directory structure. 

9. The Current Directory 

Like other command-line environments, the Amiga Shell has a current directory. 

You can change it using:
CD 

For example:
1> CD Work:Documents Commands can then operate relative to this location. 

Instead of:
TYPE Work:Documents/Notes.txt you may be able to enter:
TYPE Notes.txt This makes interactive work significantly easier. 

10. The Shell Prompt 

A typical Shell prompt might look like:
1> The number identifies the Shell process. Opening additional Shells may produce prompts such as:
2> or:
3> This immediately reveals something important about AmigaOS. You can have multiple Shells running simultaneously. 

For example:

Shell 1
   |
   +--> copying files

Shell 2
   |
   +--> examining directories

Shell 3
   |
   +--> running another program 

This is possible because the Amiga is a multitasking system. 

11. CLI and Shell 

In Amiga terminology you may also encounter the term:
CLI meaning: Command Line Interface Historically, CLI and Shell are closely related but should not always be treated as completely identical concepts. The Shell developed into a more capable command-line environment. For everyday Amiga use, however, the important practical idea is that the command-line environment allows programs and commands to be launched without Workbench. 

12. Starting a Program 

Suppose you enter:
1> MyProgram Several things need to happen. Very roughly:
User enters command
        |
        v
Shell interprets command
        |
        v
Locate executable
        |
        v
Load executable
        |
        v
Create execution context
        |
        v
Program runs 

The program does not become part of the Shell itself. It executes as a distinct program under AmigaOS. 

13. AmigaDOS Processes 

Earlier in this series we discussed Exec tasks. AmigaDOS introduces the concept of a:
Process A DOS process is based upon an Exec task but includes additional DOS-related information. 

Conceptually:
Exec Task
    +
DOS information
    =
DOS Process 

The extra information can include concepts related to: 
file handles
input
output
current directory
CLI information
DOS environment
This is how DOS builds higher-level functionality on top of Exec. 

14. Task Versus Process 

This distinction is important. An:
Exec Task is fundamentally an entity scheduled by Exec. 

A:
DOS Process adds the DOS environment required by programs interacting with AmigaDOS. 

We can visualize it as:
             Exec
              |
             Task
              |
        +-----+-----+
        |           |
   Basic Task    DOS Process
                     |
             DOS-specific state 

Not every task needs to be a DOS process. This reflects the layered architecture of AmigaOS. 

15. Standard Input and Output 

Shell commands usually have input and output streams. 

Conceptually:
Input
  |
  v
Command
  |
  v
Output 

Normally these may be connected to the Shell window. For example:
DIR writes directory information to standard output. But AmigaDOS allows these streams to be redirected. 16. Output Redirection Suppose we want to save the output of a command instead of displaying it on the screen. 

Conceptually:
Command
   |
   v
Output
   |
   v
File 

For example, depending on the command and Shell environment, redirection makes it possible to send textual output into a file rather than the console. This is a powerful idea because programs do not necessarily need to know where their output ultimately goes. They simply write to their output stream. 

17. NIL: 

AmigaDOS includes a special destination called:
NIL: 

Data written to NIL: is effectively discarded. 

Conceptually:
Program output
      |
      v
     NIL:
      |
      v
  disappears

This is similar in purpose to:
/dev/null on Unix-like systems. It is useful when a program produces output that you deliberately do not want to see or store. 

18. CON: 

Another interesting DOS entity is:
CON: 

This refers to console functionality. A program can use a console specification to create or access a console window. This demonstrates again that AmigaDOS names do not necessarily correspond directly to physical storage devices. The DOS namespace can represent services. 19. Scripts The Amiga Shell can also execute command scripts. A script contains a sequence of AmigaDOS commands. 

For example, conceptually:
Echo "Starting program..."
Assign Data: Work:MyProgram/Data
CD Work:MyProgram
MyProgram 

Instead of typing these commands manually every time, they can be stored in a script. The system can then execute them in sequence. 20. The S: Directory Scripts are often associated with:
S: 

One particularly important file is:
S:Startup-Sequence 

As we saw in the article about the Amiga boot process, this file plays an important role during system startup. AmigaDOS executes commands from the Startup-Sequence to configure and start much of the operating environment. 

For example, startup scripts may: 
create assignments
mount filesystems
start system utilities
configure paths
prepare the Workbench environment

The Amiga boot process therefore makes extensive use of the same command infrastructure available interactively through the Shell. 

21. Execute 

A script can traditionally be run using the Execute command. 

Conceptually:
1> Execute MyScript The system reads commands from the script and processes them. This means AmigaDOS itself provides a simple form of automation. Users can build their own system-management procedures without writing a compiled program. 

22. Command Arguments 

Commands can receive arguments. 

For example:
COPY SourceFile Destination 

contains:
Command
  |
  +-- COPY

Argument 1
  |
  +-- SourceFile

Argument 2
  |
  +-- Destination 

More sophisticated AmigaDOS commands can support numerous switches and options. 

For example:
COPY Work:Documents RAM: ALL Here ALL modifies the behavior of the command. 

23. Command Templates 

Many traditional AmigaDOS commands describe their parameters through a template. A template might contain markers describing whether arguments are: 
required
optional
keywords
switches
numeric arguments
multiple arguments

This makes command argument parsing more consistent. For programmers, AmigaOS provides mechanisms such as ReadArgs() for interpreting arguments according to such templates. Instead of every program inventing its own completely different parser, applications can use standard DOS functionality. 

24. Environment Variables 

AmigaDOS also supports environment variables. These allow information to be stored under symbolic names. 

Conceptually:
Variable name
     |
     v
   Value 

These values can be used by scripts and programs for configuration. 

Two names frequently encountered are:
ENV: and:
ENVARC: 

25. ENV: and ENVARC: 

These two concepts are related but serve different purposes. ENV: generally represents the active environment used by the running system. ENVARC: is traditionally used for persistent environment settings. 

Conceptually:
ENVARC:
 persistent configuration
         |
         | during startup
         v
       ENV:
 active environment 

This arrangement allows configuration to remain available after reboot while still providing fast access to the active environment. 

26. Command Search Paths 

Typing:
DIR
is obviously easier than typing:
C:Dir every time. 

AmigaDOS can search appropriate command locations when looking for executables. This separates the name used by the user from the exact physical location of the executable. Again we encounter the same design philosophy: Programs and users should not need to know every physical detail of the system layout. Assignments and command paths provide abstraction. 

27. Why the Shell Fits AmigaOS 

So Well At first sight, Workbench and the Shell appear to be two very different worlds. 

Workbench:
Icons
Windows
Menus
Mouse Shell:
Commands
Arguments
Scripts
Text 

But underneath, both environments use AmigaOS services. 

Conceptually:
         User
        /    </span>
       /      </span>
Workbench    Shell
    |          |
    +----+-----+
         |
       AmigaOS
         |
        Exec 

The graphical and command-line environments are therefore different interfaces to the same operating system. 

28. Shell Versus Workbench Startup 

There is an important practical difference between starting programs from the Shell and starting them from Workbench. From the Shell, a program receives a command-line style startup environment. 

Conceptually:
Shell
  |
arguments
  |
  v
Program A program started from Workbench receives startup information through the Workbench environment instead. Conceptually:
Workbench
    |
Workbench startup message
    |
    v
 Program 

Amiga programs can therefore distinguish between command-line startup and Workbench startup. Many applications support both. 

29. AmigaDOS and Message Passing 

As we learned in the previous article, DOS handlers communicate using messages. Therefore even a simple file operation can involve several layers. 

Conceptually:
Application
     |
     v
dos.library
     |
     v
DOS system
     |
   message
     |
     v
Filesystem Handler
     |
     v
Device
     |
     v
Hardware 

This is a good example of how deeply message passing is integrated into AmigaOS. 

30. Why This Architecture Matters 

Imagine that every application had to understand: floppy controller registers
hard-disk sectors
directory structures
filesystem layouts
serial hardware
console handling
Software would become enormously complicated. 

Instead:
Application
      |
      v
    AmigaDOS
      |
      v
Filesystem / Handler
      |
      v
    Device
      |
      v
   Hardware 

Each layer has a specific responsibility. This is the essence of operating-system abstraction. 

31. A Practical Example 

Suppose you enter:
1> COPY Work:Text.txt RAM: From the user's perspective, this is extremely simple. 

But conceptually many components may participate.
User
 |
 v
Shell
 |
 v
COPY command
 |
 v
dos.library
 |
 +------------------+
 |                  |
 v                  v
Work:              RAM:
filesystem         handler/filesystem
 |
 v
storage 

The COPY program does not need to understand the physical implementation of both storage systems. It works through AmigaDOS. That is an extremely powerful abstraction. 32. Shell Commands as Building Blocks One reason command-line systems remain useful is that small commands can be combined. Commands such as:
DIR
LIST
COPY
DELETE
TYPE
RENAME
ASSIGN
CD
MAKEDIR
INFO 

each perform relatively focused tasks. Scripts can then combine them into larger procedures. Instead of creating a special graphical tool for every administrative task, the user can assemble commands. 

This makes the Shell particularly useful for: 
system configuration
startup procedures
development
file management
troubleshooting
automation

33. Why Amiga 

Users Should Understand the Shell Even users who prefer Workbench benefit enormously from understanding basic AmigaDOS concepts. Many aspects of the system become clearer:
Why does LIBS: exist?
Why does DEVS: exist?
What is S:Startup-Sequence?
What does Assign do?
What is ENV:?
Why can programs use RAM:?
What is NIL:?
What is a volume?
What is a handler? 

Once these concepts are understood, AmigaOS stops looking like a mysterious collection of strangely named directories. Its internal structure begins to make sense. 

34. The Bigger Picture 

We can now extend our model of AmigaOS:
                    User
              /              </span>
             /                </span>
        Workbench             Shell
            |                  |
            |               Commands
            |                  |
            +--------+---------+
                     |
                  AmigaDOS
                     |
               dos.library
                     |
          +----------+----------+
          |                     |
      Processes              Handlers
          |                     |
          |                 Filesystems
          |                     |
          +----------+----------+
                     |
                    Exec
                     |
                  Devices
                     |
                  Hardware 

This diagram brings together many of the concepts from the previous articles. The Amiga Shell is not an isolated utility. It is another window into the architecture of AmigaOS. Conclusion The Amiga Shell reveals an important side of AmigaOS that is sometimes hidden behind the graphical Workbench environment. 

AmigaDOS provides a flexible infrastructure for: 
commands
processes
files
directories
volumes
assignments
scripts
environment variables
input and output
filesystem communication

The Shell provides an interactive way to use these facilities.

 Concepts such as:
C:
S:
LIBS:
DEVS:
L:
ENV:
ENVARC:
RAM:
NIL:
CON: 

are not arbitrary historical curiosities. They are parts of a carefully structured operating-system environment. Even more importantly, AmigaDOS demonstrates the same philosophy we have encountered throughout the Amiga: Complex functionality is divided into small, cooperating components. Exec provides the foundation. AmigaDOS builds processes and file services on top of it. Handlers provide filesystem and DOS services. Devices communicate with lower-level hardware. Commands provide focused tools. And the Shell brings all these pieces together for the user. Understanding the Shell therefore means understanding much more than a collection of commands. It provides another important view into how AmigaOS itself works.