At the lowest level, from a command-line point of view, just about everything in a UNIX
environment is treated as a file – even hardware entities, eg. printers, disks and DAT drives. Such
items might be described as ’devices’ or with other terms, but at the lowest level they are visible to
the admin and user as files somewhere in the UNIX file system (under /dev in the case of hardware
devices). Though this structure may seem a little odd at first, it means that system commands can
use a common processing and communication interface no matter what type of file they’re dealing
with, eg. text, pipes, data redirection, etc. (these concepts are explained in more detail later).
The UNIX file system can be regarded as a top-down tree of files and directories, starting with the
top-most ’root’ directory. A directory can be visualised as a filing cabinet, other directories as
folders within the cabinet, and individual files as the pieces of paper within folders. It’s a useful
analogy if one isn’t familiar with file system concepts, but somewhat inaccurate since a directory in
a computer file system can contain files on their own as well as other directories, ie. most office
filing cabinets don’t have loose pieces of paper outside of folders.
UNIX file systems can also have ’hidden’ files and directories. In DOS, a hidden file is just a file
with a special attribute set so that ’dir’ and other commands do not show the file; by contrast, a
hidden file in UNIX is any file which begins with a dot ’.’ (period) character, ie. the hidden status is
a result of an aspect of the file’s name, not an attribute that is bolted onto the file’s general
existence. Further, whether or not a user can access a hidden file or look inside a hidden directory
has nothing to do with the fact that the file or directory is hidden from normal view (a hidden file in
DOS cannot be written to). Access permissions are a separate aspect of the fundamental nature of a
UNIX file and are dealt with later.