I’ve revived my old Amiga computers and have been playing around with them.
The AmigaDOS is an interesting piece of history. It was based upon TRIPOS, which was initially released in 1978. UNIX was released initially in 1973ish, so it’s unclear to me how much influence UNIX had on TRIPOS and subsequently AmigaDOS.
I have a suspicion TRIPOS was relatively free of UNIX influence, based
on the absence of
.. for relative file access.
For the uninitiated,
.. are special files that occur in
every UNIX directory.
. refers to the current directory and
refers to the parent directory. The root directory, i.e.
/, is the
only special case. Since it has no parent, root’s
.. refers to
What this means is, if I have a tree like this:
$ tree test ├── a │ └── file1 ├── b │ └── sub │ ├── file2 │ └── subsub └── c └── sea_file
I can easily refer to files in OTHER directories than my current working directory.
### My current working directory is test. $ pwd /test ### To refer to a file under test I can use '.' to refer to '/path/to/test' $ cat ./a/file1 ^ +------------- The full for file is /test/. but it refers to /test ### If I change my working directory to b/sub $ cd b/sub ### I can still easily refer to files in other directories: $ cat ../../a/file1 ^ ^ | +----- .. of /test/b/, which refers to /test/ +-------- .. of /test/b/sub which refers to /test/b/
This concept is so essential in UNIX/Linux that was at a bit of a loss when I started using the AmigaDOS shell again.
In UNIX, I’m very used to doing this:
cp -r /path/to/some/dir/* .
To copy everything in
/path/to/some/dir/ to the current directory.
In AmigaDOS, I reflexively ran a similar command (note:
5.Ram Disk:> copy work:test/#? . . [created] a..copied. b..copied.
This created a directory called
. and copied my files into it!
NOT WHAT I WANTED!
5.Ram Disk:> dir . (dir)
This leads me to wonder….how does one do relative pathing in the Amiga Shell? If I used to know years ago, I’ve forgotten.
There are basically three characters that end up providing similar
.. in UNIX:
Rather than having a unified file tree, AmigaOS has volumes each with their own name (similar to CP/M or VMS and derivative operating systems).
Volumes names come from three sources:
File system labels, e.g.
Workbench:, the normal volume name of the bootable AmigaOS partition.
Device names, e.g.
DF0:for the first floppy disk.
Assigns which map to directories in volumes to volume names, e.g.
C:which normally goes to
SYS:which maps to the boot volume.
There’s only one name space for volumes, so multiple names could map to the exact same storage location. However, generally, the AmigaDOS Shell will show the file system label.
For example, the first floppy disk has a device name of
never changes no matter which disk is inserted. A disk will have a
file system label like
Workbench: and if that disk is booted from,
SYS: is also assigned to the disk. All three of these volume names
point to the same storage.
Additionally, Assigns do not work the same when they point to sub directories of other volumes. If I do this:
5.Ram Disk:> cd c: 5.Workbench:C>
Notice my current working directory changes to what
rather than have it appear as if it were an actual volume.
With that in mind, let’s return to my example and assume I have a
test: with the following tree:
test: ├── a │ └── file1 ├── b │ └── sub │ ├── file2 │ └── subsub └── c └── sea_file
So long as my current working directory is somewhere under
can can list the files in the root of
test: like this:
5.TEST:c> dir : a (dir) b (dir) c (dir)
If my current working directory is
test:b/sub, I can copy
test:c/sea_file to there like so:
5.TEST:b/sub> dir file2 subsub 5.TEST:b/sub> copy //c/sea_file "" 5.TEST:b/sub> dir file2 sea_file subsub
In this case,
"" acts just like
. in UNIX, and
// acts just like
This doesn’t seem as elegant as UNIX, but it is functional. However, I’m sometimes unable to tell if I actually find UNIX design to be good or if I’m just used to it.
Originally, I was going to write that I couldn’t find this information in the AmigaOS documentation, but as I was finishing up this blog post, I found basically my exact description under the Command Line Characters section (sorry it’s not a direct link). No mention of “relative path” references, though…so it is a bit hard to find.