Because the system is capable of supporting multiple users, everything the systems manages has a set of permissions governing who can read, write, and execute the resources. These permissions are stored as two octets broken into three pieces, one for the owner of the file, one for the group that the file belongs to, and one for everyone else. This numerical representation works like this:
You can use the -l command line argument to ls (list) to view a long directory listing that includes a column with information about a file's permissions for the owner, group, and everyone else. Here is how the first column of ls -l is broken up:
The first character, from left to right, is a special character that tells if this is a regular file, directory, a special character or block device, a socket, or any special pseudo-file device. The next three characters, designated as, rw-, gives the permissions for the owner of the file. The next three characters, r--, gives the permissions for the group that the file belongs to. The final three characters, r--, gives the permissions for the rest of the world. a dash means that the permission is turned off. In the case of this file, the permissions are set so the owner can read and write to the file, the group can read the file, and the rest of the world can only read the file. According to the table above, the permissions for this file would be 644, where each digit represents the three parts of the file's permission.
This is all well and good, but how does the system control permissions on devices? UNIX actually treats most hardware devices as a file that programs can open, read, and write data to just like any other file. These special device files are stored on the /dev directory.
Directories are also treated as files. They have read, write, and execute permissions. The executable bit for a directory has a slightly different meaning that that of files. When a directory is marked executable, it means it can be searched into, for example, a directory listing can be done in that directory.
There are more to permissions, but they are primarily used in special circumstances such as setid binaries and sticky directories. If you want more information on file permissions and how to set them, be sure to look at the chmod man pages.
The UNIX directory hierarchy is fundamental to obtaining an overall understanding of the system. The most important concept to grasp is that of the root directory, "/" . This directory is the first one mounted at boot time and it contains the base system necessary to prepare the operating system for multi-user operation. The root directory also contains mount points for every other file system that you may want to mount.
A mount point is a directory where additional file systems can be grafted onto the root file system. Standard mount points include /usr, /var, /mnt, and /cdrom . These directories are usually referenced to entries in the file /etc/fstab . The /etc/fstab is a table of various file systems and mount points for reference by the system. Most of the file systems in /etc/fstab are mounted automatically at boot time from the script unless they contain the noauto option.
A brief overview of the most common directories include:
In UNIX, a lot of everyday work is done in a command line interface called a shell. A shell's main job is to take commands from the input channel and execute them. A lot of shells also have built in functions to help everyday tasks such as file management, file globing, command line editing, command macros, and environment variables. UNIX comes with a set of shells, such as sh, the Bourne Shell, and tcsh, the improved C-shell. Many other shells are available from the UNIX Ports Collections, such as zsh and bash .
Which shell do you use? It is really a matter of taste. If you are a C programmer, you might feel more comfortable with a C-like shell such as tcsh. If you have come from Linux or are new to a UNIX command line, you might try bash. The point is that each shell has unique properties that may or may not work with you preferred working environment, and that you have a choice of what shell to use.
One common feature in a shell is file name completion. Given the typing of the first few letters of a command or filename, you can usually have the shell automatically complete the rest of the command or filename by hitting the Tab key on the keyboard. Here is an example: suppose you have two files called foobar and foo.bar . You want to delete foo.bar. So what you would type on the keyboard is:
rm fo [Tab]
The shell would print out rm foo[BEEP]. bar . The [BEEP] is the console bell, which is the shell telling me it was unable to totally complete the filename because there is more than one match. Both foobar and foo.bar start with foo, but it was able to complete to foo. . If you type in . , then hit Tab again, the shell would be able to fill the rest of the filename for you.
Another function of the shell is environment variables. Environment variables are a variable key pair stored in the shell's environment space. This space can be read by any program invoked by the shell, and thus contains a lot of program configuration. Here is a list of common environment variables and what they mean:
To view or set an environment variable differs somewhat from shell to shell. For example, in the C-Style shells such as tcsh and csh, you would use setenv to set and view environment variables. Under Bourne shells such as sh and bash, you would use set and export to view and set you current environment variables. For example, to set or modify the EDITOR environment variable, under csh or tcsh a command like this would set EDITOR to /usr/local/bin/emacs:
# setenv EDITOR /usr/local/bin/emacs
Under Bourne shell:
# export EDITOR="/usr/local/bin/emacs"
You can also make most shells expand the environment variable by placing a $ character in front of it on the command line. For example, echo $TERM would print out whatever $TERM is set to, because the shell expands $TERM and passes it to echo.
Shells treat a lot of special characters, called meta-characters as special representations of data. The most common on is the * character, which represents any number of characters in a filename. These special meta-characters can be used to do file name globing. For example, typing in echo * is almost the same as typing in ls because the shell takes all the files that match * and puts them on the command line for echo to see.
To prevent the shell from interpreting these special characters, they can be escaped from the shell by putting a backslash (\) character in front of them. The echo $TERM prints whatever your terminal is set to. The echo \$TERM prints $TERM as is.
The filesystem is best visualized as a tree, rooted, as it were, at /. /dev, /usr, and the other directories in the root directory are branches, which may have their own branches, such as /usr/local, and so on
There are various reasons to house some of these directories on separate filesystems. The /var contains the directories log/, spool/, and various types of temporary files, and as such, may get filled up. Filling up the root filesystem is not a good idea, so splitting /var from / is often favorable.
Another common reason to contain certain directory trees on other filesystems is if they are to be housed on separate physical disks, or are separate virtual disks, such as Network File System (NSF) mounts or CDROM drives.
During the boot process, filesystems listed in the /etc/fstab are automatically mounted (unless they are listed with the noauto option)
The /etc/fstab file contains a list of lines of the following format:
device /mount-point fstype options dumpfreq passno
A device name (which should exist), as explained in the Disk naming conventions above.
A directory (which should exist) on which to mount the filesystem.
The filesystem type to pass to mount. The default filesystem varies form different flavors of UNIX.
Either rw for read-write filesystem, or ro for read-only filesystems, followed by any other options that may be needed. A common option is noauto for filesystems not normally mounted during the boot sequence.
This is used by dump to determine which filesystems require dumping. If the field is missing, a value of zero is assumed
This determines the order in which filesystems should be checked. Filesystems that should be skipped should have their passno set to zero. The root filesystem (which needs to be checked before everything else) should have its passno set to 1 and the other filesystems' passno should be set to values greater than 1. If more than one filesystems have the same passno, then fsck will attempt to check filesystems in parallel if possible.
The mount command is what is ultimately used to mount filesystems. In its most basic form, you have
# mount device mountpoint
There are plenty of options, but the most common are:
The unmount command takes, as a parameter, one of a mountpoint, a device name, or the -a or -A option.
All forms take -f to force unmounting, and -v for verbosity. Be warned that -f is not generally a good idea. Forcibly unmounting filesystems might crash the computer or damage data on the filesystem.
The -a and -A are used to unmount all mounted filesystems, possibly modified by the filesystem types listed after -t. The -A, however, does not attempt to unmount the root filesystem.
UNIX is a multi-tasking operating system. This means that it seems as though more than one program is running at once. Each program at any one time is called a process. Every command you run will start at least one new process, and there are a number of system processes that run all the time, keeping the system functional.
Each process is uniquely identified by a number call a process ID, and like files, each process also has one owner and group. The owner and the group information is used to determine what files and devices the process can open, using the file permissions discussed earlier. Most processes also have parent process which is the process that started them. For example, if you are typing commands to the shell, then the shell is a process, and any commands you run are also processes. Each process that you run in this way will have your shell as its parent process. The exception to this is a special process called init. The init is always the first process, so it process ID is 1. The init is started automatically by the kernel when UNIX starts.
Questions or problems regarding this web site should
be directed to firstname.lastname@example.org.