1132 lines
		
	
	
		
			37 KiB
		
	
	
	
		
			Groff
		
	
	
	
	
	
			
		
		
	
	
			1132 lines
		
	
	
		
			37 KiB
		
	
	
	
		
			Groff
		
	
	
	
	
	
.\" Copyright (c) 1991 The Regents of the University of California.
 | 
						|
.\" All rights reserved.
 | 
						|
.\"
 | 
						|
.\" This code is derived from software contributed to Berkeley by
 | 
						|
.\" Kenneth Almquist.
 | 
						|
.\"
 | 
						|
.\" Redistribution and use in source and binary forms, with or without
 | 
						|
.\" modification, are permitted provided that the following conditions
 | 
						|
.\" are met:
 | 
						|
.\" 1. Redistributions of source code must retain the above copyright
 | 
						|
.\"    notice, this list of conditions and the following disclaimer.
 | 
						|
.\" 2. Redistributions in binary form must reproduce the above copyright
 | 
						|
.\"    notice, this list of conditions and the following disclaimer in the
 | 
						|
.\"    documentation and/or other materials provided with the distribution.
 | 
						|
.\" 3. All advertising materials mentioning features or use of this software
 | 
						|
.\"    must display the following acknowledgement:
 | 
						|
.\"	This product includes software developed by the University of
 | 
						|
.\"	California, Berkeley and its contributors.
 | 
						|
.\" 4. Neither the name of the University nor the names of its contributors
 | 
						|
.\"    may be used to endorse or promote products derived from this software
 | 
						|
.\"    without specific prior written permission.
 | 
						|
.\"
 | 
						|
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
 | 
						|
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 | 
						|
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 | 
						|
.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
 | 
						|
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 | 
						|
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 | 
						|
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 | 
						|
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 | 
						|
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 | 
						|
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 | 
						|
.\" SUCH DAMAGE.
 | 
						|
.\"
 | 
						|
.\"	@(#)sh.1	5.1 (Berkeley) 3/7/91
 | 
						|
.\"
 | 
						|
.TH SH 1 "March 7, 1991"
 | 
						|
.UC 7
 | 
						|
.de h \" subheading
 | 
						|
.sp
 | 
						|
.ti -0.3i
 | 
						|
.B "\\$1"
 | 
						|
.PP
 | 
						|
..
 | 
						|
.de d \" begin display
 | 
						|
.sp
 | 
						|
.in +4
 | 
						|
.nf
 | 
						|
..
 | 
						|
.de e \" end display
 | 
						|
.in -4
 | 
						|
.fi
 | 
						|
.sp
 | 
						|
..
 | 
						|
.de c \" command, etc.
 | 
						|
.br
 | 
						|
.HP 3
 | 
						|
\fB\\$1\fR
 | 
						|
.br
 | 
						|
..
 | 
						|
.de b \" begin builtin command
 | 
						|
.HP 3
 | 
						|
.B \\$1
 | 
						|
..
 | 
						|
.SH NAME
 | 
						|
ash, sh, bigsh, ., break, case, cd, command, continue, eval, exec, exit, export, for, getopts, hash, if, jobs, local, read, readonly, return, set, setvar, shift, trap, umask, unset, wait, while \- a shell
 | 
						|
.SH SYNOPSIS
 | 
						|
.B ash
 | 
						|
[
 | 
						|
.B -efIijnsxz
 | 
						|
] [
 | 
						|
.B +efIijnsxz
 | 
						|
] [
 | 
						|
.B -c
 | 
						|
.I command
 | 
						|
] [
 | 
						|
.I arg
 | 
						|
] ...
 | 
						|
.SH COPYRIGHT
 | 
						|
Copyright 1989 by Kenneth Almquist.
 | 
						|
.SH DESCRIPTION
 | 
						|
.I Ash
 | 
						|
is a version of
 | 
						|
.I sh
 | 
						|
with features similar to those of the System V shell.
 | 
						|
This manual page lists all the features of
 | 
						|
.I ash
 | 
						|
but concentrates on the ones not in other shells.
 | 
						|
.h "Invocation"
 | 
						|
If the
 | 
						|
.B -c
 | 
						|
options is given, then the shell executes the specified shell command.
 | 
						|
The
 | 
						|
.B -s
 | 
						|
flag cause the shell to read commands from the standard input (after
 | 
						|
executing any command specified with the
 | 
						|
.B -c
 | 
						|
option.
 | 
						|
If neither the
 | 
						|
.B -s
 | 
						|
or
 | 
						|
.B -c
 | 
						|
options are set, then the first
 | 
						|
.I arg
 | 
						|
is taken as the name of a file to read commands from.
 | 
						|
If this is impossible because there are no arguments following
 | 
						|
the options, then
 | 
						|
.I ash
 | 
						|
will set the
 | 
						|
.B -s
 | 
						|
flag and will read commands from the standard input.
 | 
						|
.PP
 | 
						|
The shell sets the initial value of the positional parameters from the
 | 
						|
.IR arg s
 | 
						|
remaining after any
 | 
						|
.I arg
 | 
						|
used as the name of a file of commands is deleted.
 | 
						|
.PP
 | 
						|
The flags (other than
 | 
						|
.BR -c )
 | 
						|
are set by preceding them with ``-'' and cleared by preceding them
 | 
						|
with ``+''; see the
 | 
						|
.I set
 | 
						|
builtin command for a list of flags.
 | 
						|
If no value is specified for the
 | 
						|
.B -i
 | 
						|
flag, the
 | 
						|
.B -s
 | 
						|
flag is set, and the standard input and output of the shell
 | 
						|
are connected to terminals, then the
 | 
						|
.B -i
 | 
						|
flag will be set.
 | 
						|
If no value is specified for the
 | 
						|
.B -j
 | 
						|
flag, then the
 | 
						|
.B -j
 | 
						|
flag will be set if the
 | 
						|
.B -i
 | 
						|
flag is set.
 | 
						|
.PP
 | 
						|
When the shell is invoked with the
 | 
						|
.B -c
 | 
						|
option, it is good practice to include the
 | 
						|
.I -i
 | 
						|
flag if the command was entered interactively by a user.
 | 
						|
For compatibility with the System V shell, the
 | 
						|
.I -i
 | 
						|
option should come after the
 | 
						|
.B -c
 | 
						|
option.
 | 
						|
.PP
 | 
						|
If the first character of argument zero to the shell is ``-'',
 | 
						|
the shell is assumed to be a login shell, and the files
 | 
						|
.B /etc/profile
 | 
						|
and
 | 
						|
.B .profile
 | 
						|
are read if they exist.
 | 
						|
If the environment variable SHINIT is set on entry to the shell,
 | 
						|
the commands in SHINIT are normally parsed and executed.  SHINIT is
 | 
						|
not examined if the shell is a login shell, or if it the shell is running a
 | 
						|
shell procedure.   (A shell is considered to be running a shell
 | 
						|
procedure if neither the
 | 
						|
.B -s
 | 
						|
nor the
 | 
						|
.B -c
 | 
						|
options are set.)
 | 
						|
.PP
 | 
						|
In older versions of MINIX that did not have virtual memory, it was
 | 
						|
important for executables to have enough memory assigned to them. The
 | 
						|
.B bigsh
 | 
						|
binary was provided for shells that need much memory. This command is
 | 
						|
retained for backward compatibility and need not be used on MINIX 3.1.4
 | 
						|
and later.
 | 
						|
.h "Control Structures"
 | 
						|
A
 | 
						|
.I list
 | 
						|
is a sequence of zero or more commands separated by newlines,
 | 
						|
semicolons, or ampersands, and optionally terminated by one of these
 | 
						|
three characters.  (This differs from the System V shell, which
 | 
						|
requires a list to contain at least one command in most cases.)  The
 | 
						|
commands in a list are executed in the order they are written.
 | 
						|
If command is followed by an ampersand, the shell starts the command
 | 
						|
and immediately proceed onto the next command; otherwise it waits
 | 
						|
for the command to terminate before proceeding to the next one.
 | 
						|
.PP
 | 
						|
``&&'' and ``||'' are binary operators.
 | 
						|
``&&'' executes the first command, and then executes the second command
 | 
						|
iff the exit status of the first command is zero.  ``||'' is similar,
 | 
						|
but executes the second command iff the exit status of the first command
 | 
						|
is nonzero.  ``&&'' and ``||'' both have the same priority.
 | 
						|
.PP
 | 
						|
The ``|'' operator is a binary operator which feeds the standard output
 | 
						|
of the first command into the standard input of the second command.
 | 
						|
The exit status of the ``|'' operator is the exit status of the second
 | 
						|
command.  ``|'' has a higher priority than ``||'' or ``&&''.
 | 
						|
.PP
 | 
						|
An
 | 
						|
.I if
 | 
						|
command looks like
 | 
						|
.d
 | 
						|
\fBif\fR list
 | 
						|
\fBthen\fR	list
 | 
						|
.ti -\w'[ 'u
 | 
						|
[ \fBelif\fR list
 | 
						|
  \fBthen\fR	list ] ...
 | 
						|
.ti -\w'[ 'u
 | 
						|
[ \fBelse\fR	list ]
 | 
						|
\fBfi\fR
 | 
						|
.e
 | 
						|
.PP
 | 
						|
A
 | 
						|
.I while
 | 
						|
command looks like
 | 
						|
.d
 | 
						|
\fBwhile\fR list
 | 
						|
\fBdo\fR	list
 | 
						|
\fBdone\fR
 | 
						|
.e
 | 
						|
The two lists are executed repeatedly while the exit status of the first
 | 
						|
list is zero.  The
 | 
						|
.I until
 | 
						|
command is similar, but has the word
 | 
						|
.B until
 | 
						|
in place of
 | 
						|
.B while
 | 
						|
 repeats until the exit status of the first list
 | 
						|
is zero.
 | 
						|
.PP
 | 
						|
The
 | 
						|
.I for
 | 
						|
command looks like
 | 
						|
.d
 | 
						|
\fBfor\fR variable \fBin\fR word...
 | 
						|
\fBdo\fR	list
 | 
						|
\fBdone\fR
 | 
						|
.e
 | 
						|
The words are expanded, and then the list is executed repeatedly with
 | 
						|
the variable set to each word in turn.
 | 
						|
.B do
 | 
						|
and
 | 
						|
.B done
 | 
						|
may be replaced with
 | 
						|
``{'' and ``}''.
 | 
						|
.PP
 | 
						|
The
 | 
						|
.I break
 | 
						|
and
 | 
						|
.I continue
 | 
						|
commands look like
 | 
						|
.d
 | 
						|
\fBbreak\fR [ num ]
 | 
						|
\fBcontinue\fR [ num ]
 | 
						|
.e
 | 
						|
.I Break
 | 
						|
terminates the
 | 
						|
.I num
 | 
						|
innermost
 | 
						|
.I for
 | 
						|
or
 | 
						|
.I while
 | 
						|
loops.
 | 
						|
.I Continue
 | 
						|
continues with the next iteration of the
 | 
						|
.IR num'th
 | 
						|
innermost loop.
 | 
						|
These are implemented as builtin commands.
 | 
						|
.PP
 | 
						|
The
 | 
						|
.I case
 | 
						|
command looks like
 | 
						|
.d
 | 
						|
\fBcase\fR word \fBin\fR
 | 
						|
pattern\fB)\fR list \fB;;\fR
 | 
						|
\&...
 | 
						|
\fBesac\fR
 | 
						|
.e
 | 
						|
The pattern can actually be one or more patterns (see
 | 
						|
.I Patterns
 | 
						|
below), separated by ``|'' characters.
 | 
						|
.PP
 | 
						|
Commands may be grouped by writing either
 | 
						|
.d
 | 
						|
\fB(\fRlist\fB)\fR
 | 
						|
.e
 | 
						|
or
 | 
						|
.d
 | 
						|
\fB{\fR list; \fB}\fR
 | 
						|
.e
 | 
						|
The first of these executes the commands in a subshell.
 | 
						|
.PP
 | 
						|
A function definition looks like
 | 
						|
.d
 | 
						|
name \fB( )\fR command
 | 
						|
.e
 | 
						|
A function definition is an executable statement; when executed it installs
 | 
						|
a function named
 | 
						|
.B name
 | 
						|
and returns an exit status of zero.
 | 
						|
The command is normally a list enclosed between ``{'' and ``}''.
 | 
						|
.PP
 | 
						|
Variables may be declared to be local to a function by using a
 | 
						|
.I local
 | 
						|
command.  This should appear as the first staement of a function,
 | 
						|
and looks like
 | 
						|
.d
 | 
						|
\fBlocal\fR [ variable | \fB-\fR ] ...
 | 
						|
.e
 | 
						|
.I Local
 | 
						|
is implemented as a builtin command.
 | 
						|
.PP
 | 
						|
When a variable is made local, it inherits the initial value and
 | 
						|
exported and readonly flags from the variable with the same name in the
 | 
						|
surrounding scope, if there is one.  Otherwise, the variable is
 | 
						|
initially unset.
 | 
						|
.I Ash
 | 
						|
uses dynamic scoping, so that if you make the variable
 | 
						|
.B x
 | 
						|
local to function
 | 
						|
.IR f ,
 | 
						|
which then calls function
 | 
						|
.IR g ,
 | 
						|
references to the variable
 | 
						|
.B x
 | 
						|
made inside
 | 
						|
.I g
 | 
						|
will refer to the variable
 | 
						|
.B x
 | 
						|
declared inside
 | 
						|
.IR f ,
 | 
						|
not to the global variable named
 | 
						|
.BR x .
 | 
						|
.PP
 | 
						|
The only special parameter that can be made local is ``\fB-\fR''.
 | 
						|
Making ``\fB-\fR'' local any shell options that are changed via the
 | 
						|
.I set
 | 
						|
command inside the function to be restored to their original values
 | 
						|
when the function returns.
 | 
						|
.PP
 | 
						|
The
 | 
						|
.I return
 | 
						|
command looks like
 | 
						|
.d
 | 
						|
\fBreturn\fR [ exitstatus ]
 | 
						|
.e
 | 
						|
It terminates the currently executing function.
 | 
						|
.I Return
 | 
						|
is implemented as a builtin command.
 | 
						|
.h "Simple Commands"
 | 
						|
A simple command is a sequence of words.  The execution of a simple
 | 
						|
command proceeds as follows.  First, the leading words of the form
 | 
						|
``name=value'' are stripped off and assigned to the environment of
 | 
						|
the command.  Second, the words are expanded.  Third, the first
 | 
						|
remaining word is taken as the command name that command is located.
 | 
						|
Fourth, any redirections are performed.  Fifth, the command is
 | 
						|
executed.  We look at these operations in reverse order.
 | 
						|
.PP
 | 
						|
The execution of the command varies with the type of command.
 | 
						|
There are three types of commands:  shell functions, builtin commands,
 | 
						|
and normal programs.
 | 
						|
.PP
 | 
						|
When a shell function is executed, all of the shell positional parameters
 | 
						|
(except $0, which remains unchanged) are set to the parameters to the shell
 | 
						|
function.  The variables which are explicitly placed in the environment
 | 
						|
of the command (by placing assignments to them before the function name)
 | 
						|
are made local to the function and are set to values given.
 | 
						|
Then the command given in the function definition is executed.
 | 
						|
The positional parameters are restored to their original values when
 | 
						|
the command completes.
 | 
						|
.PP
 | 
						|
Shell builtins are executed internally to the shell, without spawning
 | 
						|
a new process.
 | 
						|
.PP
 | 
						|
When a normal program is executed, the shell runs the program, passing
 | 
						|
the parameters and the environment to the program.  If the program is
 | 
						|
a shell procedure, the shell will interpret the program in a subshell.
 | 
						|
The shell will reinitialize itself in this case, so that the effect
 | 
						|
will be as if a new shell had been invoked to handle the shell procedure,
 | 
						|
except that the location of commands located in the parent shell will
 | 
						|
be remembered by the child.  If the program is a file beginning with
 | 
						|
``#!'', the remainder of the first line specifies an interpreter for
 | 
						|
the program.  The shell (or the operating system, under Berkeley UNIX)
 | 
						|
will run the interpreter in this case.  The arguments to the interpreter
 | 
						|
will consist of any arguments given on the first line of the program,
 | 
						|
followed by the name of the program, followed by the arguments passed
 | 
						|
to the program.
 | 
						|
.h "Redirection"
 | 
						|
Input/output redirections can be intermixed with the words in a simple
 | 
						|
command and can be placed following any of the other commands.  When
 | 
						|
redirection occurs, the shell saves the old values of the file descriptors
 | 
						|
and restores them when the command completes.  The ``<'', ``>'', and ``>>''
 | 
						|
redirections open a file for input, output, and appending, respectively.
 | 
						|
The ``<&digit'' and ``>&digit'' makes the input or output a duplicate
 | 
						|
of the file descriptor numbered by the digit.  If a minus sign is used
 | 
						|
in place of a digit, the standard input or standard output are closed.
 | 
						|
.PP
 | 
						|
The ``<<\ word'' redirection
 | 
						|
takes input from a
 | 
						|
.I here
 | 
						|
document.
 | 
						|
As the shell encounters ``<<'' redirections, it collects them.  The
 | 
						|
next time it encounters an unescaped newline, it reads the documents
 | 
						|
in turn.  The word following the ``<<'' specifies the contents of the
 | 
						|
line that terminates the document.  If none of the quoting methods
 | 
						|
('', "", or \e) are used to enter the word, then the document is treated
 | 
						|
like a word inside double quotes:  ``$'' and backquote are expanded
 | 
						|
and backslash can be used to escape these and to continue long lines.
 | 
						|
The word cannot contain any variable or command substitutions, and
 | 
						|
its length (after quoting) must be in the range of 1 to 79 characters.
 | 
						|
If ``<<-'' is used in place of ``<<'', then leading tabs are deleted
 | 
						|
from the lines of the document.  (This is to allow you do indent shell
 | 
						|
procedures containing here documents in a natural fashion.)
 | 
						|
.PP
 | 
						|
Any of the preceding redirection operators may be preceded by a single
 | 
						|
digit specifying the file descriptor to be redirected.  There cannot
 | 
						|
be any white space between the digit and the redirection operator.
 | 
						|
.h "Path Search"
 | 
						|
When locating a command, the shell first looks to see if it has a
 | 
						|
shell function by that name.  Then, if PATH does not contain an
 | 
						|
entry for "%builtin", it looks for a builtin command by that name.
 | 
						|
Finally, it searches each entry in PATH in turn for the command.
 | 
						|
.PP
 | 
						|
The value of the PATH variable should be a series of entries separated
 | 
						|
by colons.
 | 
						|
Each entry consists of a directory name, or a directory name followed
 | 
						|
by a flag beginning with a percent sign.
 | 
						|
The current directory should be indicated by an empty directory name.
 | 
						|
.PP
 | 
						|
If no percent sign is present, then the entry causes the shell to
 | 
						|
search for the command in the specified directory.  If the flag is
 | 
						|
``%builtin'' then the list of shell builtin commands is searched.
 | 
						|
If the flag is ``%func'' then the directory is searched for a file which
 | 
						|
is read as input to the shell.  This file should define a function
 | 
						|
whose name is the name of the command being searched for.
 | 
						|
.PP
 | 
						|
Command names containing a slash are simply executed without performing
 | 
						|
any of the above searches.
 | 
						|
.h "The Environment"
 | 
						|
The environment of a command is a set of name/value pairs.  When the
 | 
						|
shell is invoked, it reads these names and values, sets the shell
 | 
						|
variables with these names to the corresponding values, and marks
 | 
						|
the variables as exported.  The
 | 
						|
.I export
 | 
						|
command can be used to mark additional variables as exported.
 | 
						|
.PP
 | 
						|
The environment of a command is constructed by constructing name/value
 | 
						|
pairs from all the exported shell variables, and then modifying this
 | 
						|
set by the assignments which precede the command, if any.
 | 
						|
.h "Expansion"
 | 
						|
The process of evaluating words when a shell procedure is executed is
 | 
						|
called
 | 
						|
.IR expansion .
 | 
						|
Expansion consists of four steps:  variable substitution, command
 | 
						|
substitution, word splitting, and file name generation.  If a word
 | 
						|
is the expression following the word
 | 
						|
.B case
 | 
						|
in a case statement, the file name
 | 
						|
which follows a redirection symbol, or an assignment to the environment
 | 
						|
of a command, then the word cannot be split into multiple words.  In
 | 
						|
these cases, the last two steps of the expansion process are omitted.
 | 
						|
.h "Variable Substitution"
 | 
						|
To be written.
 | 
						|
.h "Command Substitution"
 | 
						|
.I Ash
 | 
						|
accepts two syntaxes for command substitution:
 | 
						|
.d
 | 
						|
`\fIlist\fR`
 | 
						|
.e
 | 
						|
and
 | 
						|
.d
 | 
						|
$(\fIlist\fR)
 | 
						|
.e
 | 
						|
Either of these may be included in a word.
 | 
						|
During the command substitution process, the command (syntactly a
 | 
						|
.IR list )
 | 
						|
will be executed and anything that the command writes to the standard
 | 
						|
output will be captured by the shell.  The final newline (if any) of
 | 
						|
the output will be deleted; the rest of the output will be substituted
 | 
						|
for the command in the word.
 | 
						|
.h "Word Splitting"
 | 
						|
When the value of a variable or the output of a command is substituted,
 | 
						|
the resulting text is subject to word splitting, unless the dollar sign
 | 
						|
introducing the variable or backquotes containing the text were enclosed
 | 
						|
in double quotes.  In addition, ``$@'' is subject to a special type of
 | 
						|
splitting, even in the presence of double quotes.
 | 
						|
.PP
 | 
						|
Ash uses two different splitting algorithms.  The normal approach, which
 | 
						|
is intended for splitting text separated by which space, is used if the
 | 
						|
first character of the shell variable IFS is a space.  Otherwise an alternative
 | 
						|
experimental algorithm, which is useful for splitting (possibly empty)
 | 
						|
fields separated by a separator character, is used.
 | 
						|
.PP
 | 
						|
When performing splitting, the shell scans the replacement text looking
 | 
						|
for a character (when IFS does not begin with a space) or a sequence of
 | 
						|
characters (when IFS does begin with a space), deletes the character or
 | 
						|
sequence of characters, and spits the word into two strings at that
 | 
						|
point.  When IFS begins with a space, the shell deletes either of the
 | 
						|
strings if they are null.  As a special case, if the word containing
 | 
						|
the replacement text is the null string, the word is deleted.
 | 
						|
.PP
 | 
						|
The variable ``$@'' is special in two ways.  First, splitting takes
 | 
						|
place between the positional parameters, even if the text is enclosed
 | 
						|
in double quotes.  Second, if the word containing the replacement
 | 
						|
text is the null string and there are no positional parameters, then
 | 
						|
the word is deleted.  The result of these rules is that "$@" is
 | 
						|
equivalent to "$1" "$2" ... "$\fIn\fR", where \fIn\fR is the number of
 | 
						|
positional parameters.  (Note that this differs from the System V shell.
 | 
						|
The System V documentation claims that "$@" behaves this way; in fact
 | 
						|
on the System V shell "$@" is equivalent to "" when there are no
 | 
						|
positional paramteters.)
 | 
						|
.h "File Name Generation"
 | 
						|
Unless the
 | 
						|
.B -f
 | 
						|
flag is set, file name generation is performed after word splitting is
 | 
						|
complete.  Each word is viewed as a series of patterns, separated by
 | 
						|
slashes.  The process of expansion replaces the word with the names of
 | 
						|
all existing files whose names can be formed by replacing each pattern
 | 
						|
with a string that matches the specified pattern.  There are two
 | 
						|
restrictions on this:  first, a pattern cannot match a string containing
 | 
						|
a slash, and second, a pattern cannot match a string starting with a
 | 
						|
period unless the first character of the pattern is a period.
 | 
						|
.PP
 | 
						|
If a word fails to match any files and the
 | 
						|
.B -z
 | 
						|
flag is not set, then the word will be left unchanged (except that the
 | 
						|
meta-characters will be converted to normal characters).  If the
 | 
						|
.B -z
 | 
						|
flag is set, then the word is only left unchanged if none
 | 
						|
of the patterns contain a character that can match anything besides
 | 
						|
itself.  Otherwise the
 | 
						|
.B -z
 | 
						|
flag forces the word to be replaced with the names of the files that it
 | 
						|
matches, even if there are zero names.
 | 
						|
.h "Patterns"
 | 
						|
A
 | 
						|
.I pattern
 | 
						|
consists of normal characters, which match themselves, and meta-characters.
 | 
						|
The meta-characters are ``!'', ``*'', ``?'', and ``[''.  These characters lose
 | 
						|
there special meanings if they are quoted.  When command or variable
 | 
						|
substitution is performed and the dollar sign or back quotes are not
 | 
						|
double quoted, the value of the variable or the output of the command
 | 
						|
is scanned for these characters and they are turned into meta-characters.
 | 
						|
.PP
 | 
						|
Two exclamation points at the beginning of a pattern function as a ``not''
 | 
						|
operator, causing the pattern to match any string that the remainder of
 | 
						|
the pattern does
 | 
						|
.I not
 | 
						|
match.  Other occurances of exclamation points in a pattern match
 | 
						|
exclamation points.  Two exclamation points are required rather than one
 | 
						|
to decrease the incompatibility with the System V shell (which does not
 | 
						|
treat exclamation points specially).
 | 
						|
.PP
 | 
						|
An asterisk (``*'') matches any string of characters.
 | 
						|
A question mark matches any single character.
 | 
						|
A left bracket (``['') introduces a character class.  The end of the
 | 
						|
character class is indicated by a ``]''; if the ``]'' is missing then
 | 
						|
the ``['' matches a ``['' rather than introducing a character class.
 | 
						|
A character class matches any of the characters between the square
 | 
						|
brackets.  A range of characters may be specified using a minus sign.
 | 
						|
The character class may be complemented by making an exclamation point
 | 
						|
the first character of the character class.
 | 
						|
.PP
 | 
						|
To include a ``]'' in a character class, make it the first character listed
 | 
						|
(after the ``!'', if any).
 | 
						|
To include a minus sign, make it the first or last character listed.
 | 
						|
.h "The /u Directory"
 | 
						|
By convention, the name ``/u/user'' refers to the home directory of the
 | 
						|
specified user.  There are good reasons why this feature should be supported
 | 
						|
by the file system (using a feature such as symbolic links) rather than
 | 
						|
by the shell, but
 | 
						|
.I ash
 | 
						|
is capable of performing this mapping if the file system doesn't.
 | 
						|
If the mapping is done by
 | 
						|
.IR ash ,
 | 
						|
setting the
 | 
						|
.B -f
 | 
						|
flag will turn it off.
 | 
						|
.h "Character Set"
 | 
						|
.I Ash
 | 
						|
silently discards nul characters.  Any other character will be handled
 | 
						|
correctly by
 | 
						|
.IR ash ,
 | 
						|
including characters with the high order bit set.
 | 
						|
.h "Job Names and Job Control"
 | 
						|
The term
 | 
						|
.I job
 | 
						|
refers to a process created by a shell command, or in the case of a
 | 
						|
pipeline, to the set of processes in the pipeline.  The ways to refer
 | 
						|
to a job are:
 | 
						|
.d
 | 
						|
%\fInumber\fR
 | 
						|
%\fIstring\fR
 | 
						|
%%
 | 
						|
\fIprocess_id\fR
 | 
						|
.e
 | 
						|
The first form identifies a job by job number.
 | 
						|
When a command is run,
 | 
						|
.I ash
 | 
						|
assigns it a job number
 | 
						|
(the lowest unused number is assigned).
 | 
						|
The second form identifies a job by giving a prefix of the command used
 | 
						|
to create the job.  The prefix must be unique.  If there is only one job,
 | 
						|
then the null prefix will identify the job, so you can refer to the job
 | 
						|
by writing ``%''.  The third form refers to the \fIcurrent job\fR.  The
 | 
						|
current job is the last job to be stopped while it was in the foreground.
 | 
						|
(See the next paragraph.)  The last form identifies a job by giving the
 | 
						|
process id of the last process in the job.
 | 
						|
.PP
 | 
						|
If the operating system that
 | 
						|
.I ash
 | 
						|
is running on supports job control,
 | 
						|
.I ash
 | 
						|
will allow you to use it.
 | 
						|
In this case, typing the suspend character (typically ^Z) while running
 | 
						|
a command will return you to
 | 
						|
.I ash
 | 
						|
and will make the suspended command the current job.  You can then continue
 | 
						|
the job in the background by typing
 | 
						|
.IR bg ,
 | 
						|
or you can continue it in the foreground by typing
 | 
						|
.IR fg .
 | 
						|
.h "Atty"
 | 
						|
If the shell variable ATTY is set, and the shell variable TERM is not
 | 
						|
set to ``emacs'', then \fIash\fR generates appropriate escape sequences
 | 
						|
to talk to
 | 
						|
.IR atty (1).
 | 
						|
.h "Exit Statuses"
 | 
						|
By tradition, an exit status of zero means that a command has succeeded
 | 
						|
and a nonzero exit status indicates that the command failed.  This is
 | 
						|
better than no convention at all, but in practice it is extremely useful
 | 
						|
to allow commands that succeed to use the exit status to return information
 | 
						|
to the caller.  A variety of better conventions have been proposed, but
 | 
						|
none of them has met with universal approval.  The convention used by
 | 
						|
\fIash\fR and all the programs included in the \fIash\fR distribution is
 | 
						|
as follows:
 | 
						|
.ta 1i 2i
 | 
						|
.nf
 | 
						|
	0	Success.
 | 
						|
	1	Alternate success.
 | 
						|
	2	Failure.
 | 
						|
	129-...	Command terminated by a signal.
 | 
						|
.fi
 | 
						|
The \fIalternate success\fR return is used by commands to indicate various
 | 
						|
conditions which are not errors but which can, with a little imagination,
 | 
						|
be conceived of as less successful than plain success.  For example,
 | 
						|
.I test
 | 
						|
returns 1 when the tested condition is false and
 | 
						|
.I getopts
 | 
						|
returns 1 when there are no more options.
 | 
						|
Because this convention is not used universally, the
 | 
						|
.B -e
 | 
						|
option of
 | 
						|
.I ash
 | 
						|
causes the shell to exit when a command returns 1 even though that
 | 
						|
contradicts the convention described here.
 | 
						|
.PP
 | 
						|
When a command is terminated by a signal, the uses 128 plus the signal
 | 
						|
number as the exit code for the command.
 | 
						|
.h "Builtin Commands"
 | 
						|
This concluding section lists the builtin commands which are builtin
 | 
						|
because they need to perform some operation that can't be performed by a
 | 
						|
separate process.  In addition to these, there are several other commands
 | 
						|
.RI ( catf ,
 | 
						|
.IR echo ,
 | 
						|
.IR expr ,
 | 
						|
.IR line ,
 | 
						|
.IR nlecho ,
 | 
						|
.IR test ,
 | 
						|
.RI  `` : '',
 | 
						|
and
 | 
						|
.IR true )
 | 
						|
which can optionally be compiled into the shell.  The builtin
 | 
						|
commands described below that accept options use the System V Release 2
 | 
						|
.IR getopt (3)
 | 
						|
syntax.
 | 
						|
.sp
 | 
						|
.b bg
 | 
						|
[
 | 
						|
.I job
 | 
						|
] ...
 | 
						|
.br
 | 
						|
Continue the specified jobs (or the current job if no jobs are given)
 | 
						|
in the background.
 | 
						|
This command is only available on systems with Bekeley job control.
 | 
						|
.b command
 | 
						|
.IR "command arg" ...
 | 
						|
.br
 | 
						|
Execute the specified builtin command.  (This is useful when you have a
 | 
						|
shell function with the same name as a builtin command.)
 | 
						|
.b cd
 | 
						|
[
 | 
						|
.I directory
 | 
						|
]
 | 
						|
.br
 | 
						|
Switch to the specified directory (default $HOME).
 | 
						|
If the an entry for CDPATH appears in the environment of the cd command
 | 
						|
or the shell variable CDPATH is set and the directory name does not
 | 
						|
begin with a slash, then the directories listed in CDPATH will be
 | 
						|
searched for the specified directory.  The format of CDPATH is the
 | 
						|
same as that of PATH.
 | 
						|
In an interactive shell, the cd command will print out the name of the
 | 
						|
directory that it actually switched to if this is different from the
 | 
						|
name that the user gave.  These may be different either because
 | 
						|
the CDPATH mechanism was used or because a symbolic link was crossed.
 | 
						|
.\" .b ".\fI\h'0.1i'file"
 | 
						|
.\" Cawf can't do \h'0.1i'
 | 
						|
.b .
 | 
						|
.I file
 | 
						|
.br
 | 
						|
The commands in the specified file are read and executed by the shell.
 | 
						|
A path search is not done to find the file because the directories in
 | 
						|
PATH generally contain files that are intended to be executed, not read.
 | 
						|
.b eval
 | 
						|
.IR string ...
 | 
						|
.br
 | 
						|
The strings are parsed as shell commands and executed.
 | 
						|
(This differs from the System V shell, which concatenates the arguments
 | 
						|
(separated by spaces) and parses the result as a single command.)
 | 
						|
.b exec
 | 
						|
[
 | 
						|
.IR "command arg" ...
 | 
						|
]
 | 
						|
.br
 | 
						|
Unless
 | 
						|
.I command
 | 
						|
is omitted,
 | 
						|
the shell process is replaced with the specified program (which must be a real
 | 
						|
program, not a shell builtin or function).
 | 
						|
Any redirections on the exec command are marked as permanent, so that they
 | 
						|
are not undone when the exec command finishes.
 | 
						|
If the command is not found, the exec command causes the shell to exit.
 | 
						|
.b exit
 | 
						|
[
 | 
						|
.I exitstatus
 | 
						|
]
 | 
						|
.br
 | 
						|
Terminate the shell process.  If
 | 
						|
.I exitstatus
 | 
						|
is given it is used as the
 | 
						|
exit status of the shell; otherwise the exit status of the preceding
 | 
						|
command is used.
 | 
						|
.b export
 | 
						|
.IR name ...
 | 
						|
.br
 | 
						|
The specified names are exported so that they will appear in the environment
 | 
						|
of subsequent commands.  The only way to un-export a variable is to unset it.
 | 
						|
.I Ash
 | 
						|
allows the value of a variable to be set at the same time it is exported
 | 
						|
by writing
 | 
						|
.d
 | 
						|
\fBexport\fR name=value
 | 
						|
.e
 | 
						|
With no arguments the export command lists the names of all exported variables.
 | 
						|
.b fg
 | 
						|
[
 | 
						|
.I job
 | 
						|
]
 | 
						|
.br
 | 
						|
Move the specified job or the current job to the foreground.
 | 
						|
This command is only available on systems with Bekeley job control.
 | 
						|
.b getopts
 | 
						|
.I optstring
 | 
						|
.I var
 | 
						|
.br
 | 
						|
The System V
 | 
						|
.I getopts
 | 
						|
command.
 | 
						|
.b hash
 | 
						|
.B -rv
 | 
						|
.IR command ...
 | 
						|
.br
 | 
						|
The shell maintains a hash table which remembers the locations of
 | 
						|
commands.  With no arguments whatsoever, the hash command prints
 | 
						|
out the contents of this table.  Entries which have not been looked
 | 
						|
at since the last
 | 
						|
.I cd
 | 
						|
command are marked with an asterisk; it is possible for these entries
 | 
						|
to be invalid.
 | 
						|
.sp
 | 
						|
With arguments, the hash command removes the specified commands from
 | 
						|
the hash table (unless they are functions) and then locates them.
 | 
						|
With the
 | 
						|
.B -v
 | 
						|
option,
 | 
						|
.I hash
 | 
						|
prints the locations of the commands as it finds them.
 | 
						|
The
 | 
						|
.B -r
 | 
						|
option causes the
 | 
						|
.I hash
 | 
						|
command to delete all the entries in the hash table except for
 | 
						|
functions.
 | 
						|
.b jobid
 | 
						|
[
 | 
						|
.I job
 | 
						|
]
 | 
						|
.br
 | 
						|
Print the process id's of the processes in the job.  If the job argument
 | 
						|
is omitted, use the current job.
 | 
						|
.b jobs
 | 
						|
.br
 | 
						|
This command lists out all the background processes which are children
 | 
						|
of the current shell process.
 | 
						|
.b pwd
 | 
						|
.br
 | 
						|
Print the current directory.  The builtin command may differ from the
 | 
						|
program of the same name because the builtin command remembers what
 | 
						|
the current directory is rather than recomputing it each time.  This
 | 
						|
makes it faster.  However, if the current directory is renamed, the
 | 
						|
builtin version of pwd will continue to print the old name for the
 | 
						|
directory.
 | 
						|
.b read
 | 
						|
[
 | 
						|
.B -p
 | 
						|
.I prompt
 | 
						|
]
 | 
						|
[
 | 
						|
.B -e
 | 
						|
]
 | 
						|
.IR variable ...
 | 
						|
.br
 | 
						|
The prompt is printed if the
 | 
						|
.B -p
 | 
						|
option is specified and the standard input is a terminal.  Then a
 | 
						|
line is read from the standard input.  The trailing newline is deleted
 | 
						|
from the line and the line is split as described
 | 
						|
in the section on word splitting above, and the pieces are assigned to
 | 
						|
the variables in order.  If there are more pieces than variables, the
 | 
						|
remaining pieces (along with the characters in IFS that separated them)
 | 
						|
are assigned to the last variable.  If there are more variables than
 | 
						|
pieces, the remaining variables are assigned the null string.
 | 
						|
.sp
 | 
						|
The
 | 
						|
.B -e
 | 
						|
option causes any backslashes in the input to be treated specially.
 | 
						|
If a backslash is followed by a newline, the backslash and the newline
 | 
						|
will be deleted.  If a backslash is followed by any other character,
 | 
						|
the backslash will be deleted and the following character will be treated
 | 
						|
as though it were not in IFS, even if it is.
 | 
						|
.b readonly
 | 
						|
.IR name ...
 | 
						|
.br
 | 
						|
The specified names are marked as read only, so that they cannot be
 | 
						|
subsequently modified or unset.
 | 
						|
.I Ash
 | 
						|
allows the value of a variable to be set at the same time it is marked
 | 
						|
read only by writing
 | 
						|
.d
 | 
						|
\fBreadonly\fR name=value
 | 
						|
.e
 | 
						|
With no arguments the readonly command lists the names of all
 | 
						|
read only variables.
 | 
						|
.b set
 | 
						|
[
 | 
						|
{
 | 
						|
.BI - options
 | 
						|
|
 | 
						|
.BI + options
 | 
						|
|
 | 
						|
.B --
 | 
						|
}
 | 
						|
]
 | 
						|
.IR arg ...
 | 
						|
.br
 | 
						|
The
 | 
						|
.I set
 | 
						|
command performs three different functions.
 | 
						|
.sp
 | 
						|
With no arguments, it lists the values of all shell variables.
 | 
						|
.sp
 | 
						|
If options are given, it sets the specified option flags, or clears
 | 
						|
them if the option flags are introduced with a
 | 
						|
.B +
 | 
						|
rather than a
 | 
						|
.BR - .
 | 
						|
Only the first argument to
 | 
						|
.I set
 | 
						|
can contain options.
 | 
						|
The possible options are:
 | 
						|
.sp
 | 
						|
.ta 0.4i
 | 
						|
.in +0.4i
 | 
						|
.ti -0.4i
 | 
						|
\fB-e\fR	Causes the shell to exit when a command terminates with
 | 
						|
a nonzero exit status, except when the exit status of the command is
 | 
						|
explicitly tested.  The exit status of a command is considered to be
 | 
						|
explicitly tested if the command is used to control an
 | 
						|
.IR if ,
 | 
						|
.IR elif ,
 | 
						|
.IR while ,
 | 
						|
or
 | 
						|
.IR until ;
 | 
						|
or if the command is the left hand operand of an ``&&'' or ``||''
 | 
						|
operator.
 | 
						|
.sp
 | 
						|
.ti -0.4i
 | 
						|
\fB-f\fR	Turn off file name generation.
 | 
						|
.sp
 | 
						|
.ti -0.4i
 | 
						|
\fB-I\fR	Cause the shell to ignore end of file conditions.
 | 
						|
(This doesn't apply when the shell a script sourced using the ``.''
 | 
						|
command.)  The shell will in fact exit if it gets 50 eof's in a
 | 
						|
row.
 | 
						|
.sp
 | 
						|
.ti -0.4i
 | 
						|
\fB-i\fR	Make the shell interactive.  This causes the shell to
 | 
						|
prompt for input, to trap interrupts, to ignore quit and terminate signals,
 | 
						|
and to return to the main command loop rather than exiting on error.
 | 
						|
.sp
 | 
						|
.ti -0.4i
 | 
						|
\fB-j\fR	Turns on Berkeley job control, on systems that support it.
 | 
						|
When the shell starts up, the
 | 
						|
.B -j
 | 
						|
is set by default if the
 | 
						|
.B -i
 | 
						|
flag is set.
 | 
						|
.sp
 | 
						|
.ti -0.4i
 | 
						|
\fB-n\fR	Causes the shell to read commands but not execute them.
 | 
						|
(This is marginally useful for checking the syntax of scripts.)
 | 
						|
.sp
 | 
						|
.ti -0.4i
 | 
						|
\fB-s\fR	If this flag is set when the shell starts up, the shell
 | 
						|
reads commands from its standard input.  The shell doesn't examine the
 | 
						|
value of this flag any other time.
 | 
						|
.sp
 | 
						|
.ti -0.4i
 | 
						|
\fB-x\fR	If this flag is set, the shell will print out each
 | 
						|
command before executing it.
 | 
						|
.sp
 | 
						|
.ti -0.4i
 | 
						|
\fB-z\fR	If this flag is set, the file name generation process
 | 
						|
may generate zero files.  If it is not set, then a pattern which does
 | 
						|
not match any files will be replaced by a quoted version of the pattern.
 | 
						|
.in -0.4i
 | 
						|
.sp
 | 
						|
The third use of the set command is to set the values of the shell's
 | 
						|
positional parameters to the specified
 | 
						|
.IR args .
 | 
						|
To change the positional parameters without changing any options,
 | 
						|
use ``\fB--\fR'' as the first argument to
 | 
						|
.IR set .
 | 
						|
If no args are present, the set command will leave the value of the
 | 
						|
positional parameters unchanged, so to set the positional parameters
 | 
						|
to set of values that may be empty, execute the command
 | 
						|
.d
 | 
						|
shift $#
 | 
						|
.e
 | 
						|
first to clear out the old values of the positional parameters.
 | 
						|
.b setvar
 | 
						|
.I variable
 | 
						|
.I value
 | 
						|
.br
 | 
						|
Assigns
 | 
						|
.I value
 | 
						|
to
 | 
						|
.IR variable .
 | 
						|
(In general it is better to write
 | 
						|
.I variable=value
 | 
						|
rather than using
 | 
						|
.IR setvar .
 | 
						|
.I Setvar
 | 
						|
is intended to be used in functions that assign values to variables whose
 | 
						|
names are passed as parameters.)
 | 
						|
.b shift
 | 
						|
[
 | 
						|
.I n
 | 
						|
]
 | 
						|
.br
 | 
						|
Shift the positional parameters
 | 
						|
.I n
 | 
						|
times.
 | 
						|
A shift sets the value of $1 to the value of $2, the value of $2 to
 | 
						|
the value of $3, and so on, decreasing the value of $# by one.
 | 
						|
If there are zero positional parameters, shifting doesn't do anything.
 | 
						|
.b trap
 | 
						|
[
 | 
						|
.I action
 | 
						|
]
 | 
						|
.IR signal ...
 | 
						|
.br
 | 
						|
Cause the shell to parse and execute
 | 
						|
.I action
 | 
						|
when any of the specified signals are received.
 | 
						|
The signals are specified by signal number.
 | 
						|
.I Action
 | 
						|
may be null or omitted;
 | 
						|
the former causes the specified signal to be ignored and the latter
 | 
						|
causes the default action to be taken.
 | 
						|
When the shell forks off a subshell, it resets trapped (but not ignored)
 | 
						|
signals to the default action.
 | 
						|
The trap command has no effect on signals that were ignored on entry
 | 
						|
to the shell.
 | 
						|
.b umask
 | 
						|
[
 | 
						|
.I mask
 | 
						|
]
 | 
						|
.br
 | 
						|
Set the value of umask (see
 | 
						|
.IR umask (2))
 | 
						|
to the specified octal value.  If the argument is omitted, the umask
 | 
						|
value is printed.
 | 
						|
.b unset
 | 
						|
.IR name ...
 | 
						|
.br
 | 
						|
The specified variables and functions are unset and unexported.
 | 
						|
If a given name corresponds to both a variable and a function, both the
 | 
						|
variable and the function are unset.
 | 
						|
.b wait
 | 
						|
[
 | 
						|
.I job
 | 
						|
]
 | 
						|
.br
 | 
						|
Wait for the specified job to complete and return the exit status of the
 | 
						|
last process in the job.  If the argument is omitted, wait for all jobs
 | 
						|
to complete and the return an exit status of zero.
 | 
						|
.SH EXAMPLES
 | 
						|
The following function redefines the \fIcd\fR command:
 | 
						|
.d
 | 
						|
cd() {
 | 
						|
	if command cd "$@"
 | 
						|
	then	if test -f .enter
 | 
						|
		then	. .enter
 | 
						|
		else	return 0
 | 
						|
		fi
 | 
						|
	fi
 | 
						|
}
 | 
						|
.e
 | 
						|
This function causes the file ``.enter'' to be read when you enter a
 | 
						|
directory, if it exists.  The \fIcommand\fR command is used to access the
 | 
						|
real \fIcd\fR command.  The ``return 0'' ensures that the function will
 | 
						|
return an exit status of zero if it successfully changes to a directory
 | 
						|
that does not contain a ``.enter'' file.  Redefining existing commands
 | 
						|
is not always a good idea, but this example shows that you can do it if
 | 
						|
you want to.
 | 
						|
.PP
 | 
						|
The suspend function distributed with
 | 
						|
.I ash
 | 
						|
looks like
 | 
						|
.d
 | 
						|
# Copyright (C) 1989 by Kenneth Almquist.  All rights reserved.
 | 
						|
# This file is part of ash, which is distributed under the terms
 | 
						|
# specified by the Ash General Public License.
 | 
						|
 | 
						|
suspend() {
 | 
						|
	local -
 | 
						|
	set +j
 | 
						|
	kill -TSTP 0
 | 
						|
}
 | 
						|
.e
 | 
						|
This turns off job control and then sends a stop signal to the current
 | 
						|
process group, which suspends the shell.  (When job control is turned
 | 
						|
on, the shell ignores the TSTP signal.)  Job control will be turned back
 | 
						|
on when the function returns because ``-'' is local to the function.
 | 
						|
As an example of what \fInot\fR to do, consider an earlier version of
 | 
						|
\fIsuspend\fR:
 | 
						|
.d
 | 
						|
suspend() {
 | 
						|
	suspend_flag=$-
 | 
						|
	set +j
 | 
						|
	kill -TSTP 0
 | 
						|
	set -$suspend_flag
 | 
						|
}
 | 
						|
.e
 | 
						|
There are two problems with this.  First, \fBsuspend_flag\fR is a global
 | 
						|
variable rather than a local one, which will cause problems in the
 | 
						|
(unlikely) circumstance that the user is using that variable for some
 | 
						|
other purpose.  Second, consider what happens if shell received an interrupt
 | 
						|
signal after it executes the first \fIset\fR command but before it executes
 | 
						|
the second one.  The interrupt signal will abort the shell function, so
 | 
						|
that the second \fIset\fR command will never be executed and job control
 | 
						|
will be left off.  The first version of \fIsuspend\fR avoids this problem
 | 
						|
by turning job control off only in a local copy of the shell options.  The
 | 
						|
local copy of the shell options is discarded when the function is terminated,
 | 
						|
no matter how it is terminated.
 | 
						|
.SH HINTS
 | 
						|
Shell variables can be used to provide abbreviations for things which
 | 
						|
you type frequently.  For example, I set
 | 
						|
.br
 | 
						|
.\" \h'1i'export h=$HOME
 | 
						|
.\" Cawf can't do \h'1i'
 | 
						|
.in +1i
 | 
						|
export h=$HOME
 | 
						|
.in -1i
 | 
						|
.br
 | 
						|
in my .profile so that I can type the name of my home directory simply
 | 
						|
by typing ``$h''.
 | 
						|
.PP
 | 
						|
When writing shell procedures, try not to make assumptions about what is
 | 
						|
imported from the environment.  Explicitly unset or initialize all variables,
 | 
						|
rather than assuming they will be unset.  If you use cd, it is a good idea
 | 
						|
to unset CDPATH.
 | 
						|
.PP
 | 
						|
People sometimes use ``<&-'' or ``>&-'' to provide no input to a command
 | 
						|
or to discard the output of a command.  A better way to do this is
 | 
						|
to redirect the input or output of the command to
 | 
						|
.BR /dev/null .
 | 
						|
.PP
 | 
						|
Word splitting and file name generation are performed by default,
 | 
						|
and you have to explicitly use double quotes to suppress it.  This is
 | 
						|
backwards, but you can learn to live with it.  Just get in the habit of
 | 
						|
writing double quotes around variable and command substitutions, and
 | 
						|
omit them only when you really want word splitting and file name generation.
 | 
						|
If you want word splitting but not file name generation, use the
 | 
						|
.B -f
 | 
						|
option.
 | 
						|
.SH AUTHORS
 | 
						|
Kenneth Almquist
 | 
						|
.SH "SEE ALSO"
 | 
						|
echo(1), expr(1), line(1), pwd(1), true(1).
 | 
						|
.SH BUGS
 | 
						|
When command substitution occurs inside a here document, the commands inside
 | 
						|
the here document are run with their standard input closed.  For example,
 | 
						|
the following will not work because the standard input of the
 | 
						|
.I line
 | 
						|
command will be closed when the command is run:
 | 
						|
.d
 | 
						|
cat <<-!
 | 
						|
Line 1: $(line)
 | 
						|
Line 2: $(line)
 | 
						|
!
 | 
						|
.e
 | 
						|
.PP
 | 
						|
Unsetting a function which is currently being executed may cause strange
 | 
						|
behavior.
 | 
						|
.PP
 | 
						|
The shell syntax allows a here document to be terminated by an end of file
 | 
						|
as well as by a line containing the terminator word which follows the ``<<''.
 | 
						|
What this means is that if you mistype the terminator line, the shell
 | 
						|
will silently swallow up the rest of your shell script and stick it
 | 
						|
in the here document.
 | 
						|
.\" several minor typos corrected -- ASW 2005-01-15
 |