P1: JDW
UNIX WL040/Bidgoli-Vol III-Ch-41 August 13, 2003 17:26 Char Count= 0
CORECOMPONENTS 503Giving the ‘-a’ flag will listallfiles, including certain hid-
den files that are not normally shown by default. Giving
the ‘-1’ flag will list filenames all in a single column at the
left of the terminal screen. Giving the ‘-i’ flag will list the
file’s inode number next to its filename. Giving the ‘-R’
flag will recurse through subdirectories, list out the files
in those directories as well as the current directory (de-
fault). Giving the ‘-S’ flag will sort the files according to file
size. Giving the ‘-Sr’ flag will sort the files in reverse order.
Options vary according to the flavor of Unix. For in-
stance, certain options apply to AT&T derivatives, and
other options apply to Berkeley derivatives. That is to say,
a given command (most notoriously the ‘ps’ command to
list out all running processes) have different flags based on
whether the ps command is on a Berkeley-based or AT&T-
based Unix. Nevertheless, options can allow the user to
tailor the standard output of a Unix command to suit their
special interests or needs.Redirection
By default, output from a command (if there is any) goes
to a special file called standard output. By default, stan-
dard output is set to the current user’s terminal (also a
file). So if I issue the command “date,” the current date
will be displayed on my terminal. Because everything is a
file in Unix, it is easy to redirect the output from one file
to another, that is, from the terminal device to some other
file. For example, the command “echo hello >hello.txt”
would redirect the standard output of the “echo hello”
command into a new file called “hello.txt,” effectively cre-
ating the file called “hello.txt” (if the file already existed,
its contents would be overwritten with the redirected out-
put). Thus, if I were to type out the contents of the new
file hello.txt, I would see that its contents was “hello”:$ echo hello >hello.txt
$ cat hello.txt
helloUnix assigns three default files for use on the system:
the “standard input,” “standard output,” and “standard
error” files. All files are designated in the system by some-
thing known as a “file handle,” and our default files have
three associated file handles. Standard input has file han-
dle number 0, standard output has default file handle
number 1, and standard error has a default file handle
number 2. These file handles allow users to reference them
during redirection.
Standard input is a file through which the system de-
livers data entered to the program by either the user inter-
acting with the shell or by some other program through a
pipe. When a program wishes to write text out to the user’s
terminal, the program’s author can choose which of the
two “output” files to write to, either standard output or
standard error. Generally, when a program’s author wants
to display information that is part of the general operation
of the program (often the information the user wants to
see by running the program in the first place), that infor-
mation is written “to” the standard output file, which is by
default sent to the user’s terminal screen. If the program’s
author wants to write out some type of error-related infor-
mation, the author will write the error information out tostandard error. By using this standard, the user can enter
(in Bourne-derived shells) the following syntax:mycommand 1>standard.output 2>errors.txtand expect that the program’s main information would
be redirected out to a file called “standard.output” and
that errors, if any, would be written out to a separate file
called “errors.txt.” This allows a user to “declutter” the
output they are interested in from the various errors that,
though not necessarily critical, still might be distracting.
Redirection is one of the many concepts in Unix that
was adopted by subsequent operating systems (although
not to the same degree of depth), in limited form, such as
MSDOS and later Windows NT.Command History
Most Unix shells maintain a list of previous commands en-
tered at the command prompt. These shells also provide
some means for accessing previous commands and parts
of previous commands. Although the precise shell syntax
varies, command history serves one main purpose: to re-
duce typing at the command line. Say a user wants to use
elm to mail the same e-mail message to a number of users,
he or she types the following commands at the prompt,
successively:elm -s "please come to my Halloween party
tonight" linda <mail.invitation.txt
elm -s "please come to my Halloween party
tonight" ellen <mail.invitation.txt
elm -s "please come to my Halloween party
tonight" steve <mail.invitation.txtNow, even in these few commands, there is a signif-
icant degree of repetition. The user is sending the same
e-mail message mail.invitation.txt (via redirecting input)
with the same subject to three people. Notice also that ev-
ery command ends with the filename mail.invitation.txt.
Now, the user could of course simply type this redun-
dant text over and over again. But what if she were throw-
ing a large party and needed to send out 50 invitations?
That’s a lot of typing. The command history mechanism
offers a number of shortcuts at the command line that
save us from having to retype repetitive data. For exam-
ple, the lines could also be executed (with the tcsh as well
as the bash shells) as follows:elm -s "please come to my Halloween party
tonight" linda <mail.invitation.txt
^linda^ellen
^ellen^steveClearly, a great deal less typing at the expense of
some really strange looking syntax. Although I cannot
go into the details of command line history, suffice it to
say that the command syntaxˆsearchˆ replacewill search
through the previous command and replacesearchwith
replace. So, once the command “vi myfile1.txt” has been
executed, immediately executing the command “ˆ1ˆ2”
would execute the command “vi myfile2.txt,” effectively
replacing the 1 from the previous command with a 2.