article.ms

android-w.song.android.widget

.de SE	\" start example
.sp .5
.RS
.ft CR
.nf
..
.de EE	\" end example
.fi
.sp .5
.RE
.ft R
..
.TL
Bash \- The GNU shell*
.AU
Chet Ramey
Case Western Reserve University
[e-mail]
.FS
*An earlier version of this article appeared in The Linux Journal.
.FE
.NH 1
Introduction
.PP
.B Bash
is the shell, or command language interpreter,
that will appear in the GNU operating system.
The name is an acronym for
the \*QBourne-Again SHell\*U, a pun on Steve Bourne, the author
of the direct ancestor of the current
.UX
shell \fI/bin/sh\fP,
which appeared in the Seventh Edition Bell Labs Research version
of \s-1UNIX\s+1.
.PP
Bash is an \fBsh\fP\-compatible shell that incorporates useful
features from the Korn shell (\fBksh\fP) and the C shell (\fBcsh\fP),
described later in this article.  It is ultimately intended to be a
conformant implementation of the IEEE POSIX Shell and Utilities
specification (IEEE Working Group 1003.2).  It offers functional
improvements over sh for both interactive and programming use.
.PP
While the GNU operating system will most likely include a version
of the Berkeley shell csh, Bash will be the default shell.
Like other GNU software, Bash is quite portable.  It currently runs
on nearly every version of
.UX
and a few other operating systems \- an independently-supported
port exists for OS/2, and there are rumors of ports to DOS and
Windows NT.  Ports to \s-1UNIX\s+1-like systems such as QNX and Minix
are part of the distribution.
.PP
The original author of Bash
was Brian Fox, an employee of the Free Software Foundation.  The
current developer and maintainer is Chet Ramey, a volunteer who
works at Case Western Reserve University.
.NH 1
What's POSIX, anyway?
.PP
.I POSIX
is a name originally coined by Richard Stallman for a family of open
system standards based on \s-1UNIX\s+1.  There are a number of aspects of \s-1UNIX\s+1
under consideration for standardization, from the basic system services
at the system call and C library level to applications and tools to system
administration and management.  Each area of standardization is
assigned to a working group in the 1003 series.
.PP
The POSIX Shell and Utilities standard has been developed by IEEE Working
Group 1003.2 (POSIX.2).\(dd
.FS
\(ddIEEE, \fIIEEE Standard for Information Technology -- Portable
Operating System Interface (POSIX) Part 2: Shell and Utilities\fP,
1992.
.FE
It concentrates on the command interpreter
interface and utility programs
commonly executed from the command line or by other programs.
An initial version of the standard has been
approved and published by the IEEE, and work is currently underway to
update it.
There are four primary areas of work in the 1003.2 standard:
.IP \(bu
Aspects of the shell's syntax and command language.
A number of special builtins such as
.B cd
and
.B exec
are being specified as part of the shell, since their
functionality usually cannot be implemented by a separate executable;
.IP \(bu
A set of utilities to be called by shell scripts and applications.
Examples are programs like
.I sed,
.I tr,
and
.I awk.
Utilities commonly implemented as shell builtins
are described in this section, such as
.B test
and
.B kill .
An expansion of this section's scope, termed the User Portability
Extension, or UPE, has standardized interactive programs such as
.I vi
and
.I mailx;
.IP \(bu
A group of functional interfaces to services provided by the
shell, such as the traditional \f(CRsystem()\fP
C library function.  There are functions to perform shell word
expansions, perform filename expansion (\fIglobbing\fP), obtain values
of POSIX.2 system configuration variables, retrieve values of
environment variables (\f(CRgetenv()\fP\^), and other services;
.IP \(bu
A suite of \*Qdevelopment\*U utilities such as
.I c89
(the POSIX.2 version of \fIcc\fP),
and
.I yacc.
.PP
Bash is concerned with the aspects of the shell's behavior
defined by POSIX.2.  The shell command language has of
course been standardized, including the basic flow control
and program execution constructs, I/O redirection and
pipelining, argument handling, variable expansion, and quoting.
The
.I special
builtins, which must be implemented as part of the shell to
provide the desired functionality, are specified as being
part of the shell; examples of these are
.B eval
and
.B export .
Other utilities appear in the sections of POSIX.2 not
devoted to the shell which are commonly (and in some
cases must be) implemented as builtin commands, such as
.B read
and
.B test .
POSIX.2 also specifies aspects of the shell's
interactive behavior as part of
the UPE, including job control and command line editing.
Interestingly enough, only \fIvi\fP-style line editing commands
have been standardized; \fIemacs\fP editing commands were left
out due to objections.
.PP
While POSIX.2 includes much of what the shell has traditionally
provided, some important things have been omitted as being
\*Qbeyond its scope.\*U  There is, for instance, no mention of
a difference between a
.I login
shell and any other interactive shell (since POSIX.2 does not
specify a login program).  No fixed startup files are defined,
either \- the standard does not mention
.I .profile .
.NH 1
Basic Bash features
.PP
Since the Bourne shell
provides Bash with most of its philosophical underpinnings,
Bash inherits most of its features and functionality from sh.
Bash implements all of the traditional sh flow
control constructs (\fIfor\fP, \fIif\fP, \fIwhile\fP, etc.).
All of the Bourne shell builtins, including those not specified in
the POSIX.2 standard, appear in Bash.  Shell \fIfunctions\fP,
introduced in the SVR2 version of the Bourne shell,
are similar to shell scripts, but are defined using a special
syntax and are executed in the same process as the calling shell.
Bash has shell functions
which behave in a fashion upward-compatible with sh functions.
There are certain shell
variables that Bash interprets in the same way as sh, such as
.B PS1 ,
.B IFS ,
and
.B PATH .
Bash implements essentially the same grammar, parameter and
variable expansion semantics, redirection, and quoting as the
Bourne shell.  Where differences appear between the POSIX.2
standard and traditional sh behavior, Bash follows POSIX.
.PP
The Korn Shell (\fBksh\fP) is a descendent of the Bourne shell written
at AT&T Bell Laboratories by David Korn\(dg.  It provides a number of
useful features that POSIX and Bash have adopted.  Many of the
interactive facilities in POSIX.2 have their roots in the ksh:
for example, the POSIX and ksh job control facilities are nearly
identical. Bash includes features from the Korn Shell for both
interactive use and shell programming.  For programming, Bash provides
variables such as
.B RANDOM
and
.B REPLY ,
the
.B typeset
builtin,
the ability to remove substrings from variables based on patterns,
and shell arithmetic.
.FS
\(dgMorris Bolsky and David Korn, \fIThe KornShell Command and
Programming Language\fP, Prentice Hall, 1989.
.FE
.B RANDOM
expands to a random number each time it is referenced; assigning a
value to
.B RANDOM
seeds the random number generator.
.B REPLY
is the default variable used by the
.B read
builtin when no variable names are supplied as arguments.
The
.B typeset
builtin is used to define variables and give them attributes
such as \fBreadonly\fP.
Bash arithmetic allows the evaluation of an expression and the
substitution of the result.  Shell variables may be used as operands,
and the result of an expression may be assigned to a variable.
Nearly all of the operators from the C language are available,
with the same precedence rules:
.SE
$ echo $((3 + 5 * 32))
163
.EE
.LP
For interactive use, Bash implements ksh-style aliases and builtins
such as
.B fc
(discussed below) and
.B jobs .
Bash aliases allow a string to be substituted for a command name.
They can be used to create a mnemonic for a \s-1UNIX\s+1 command
name (\f(CRalias del=rm\fP), to expand a single word to a complex command
(\f(CRalias news='xterm -g 80x45 -title trn -e trn -e -S1 -N &'\fP), or to
ensure that a command is invoked with a basic set of options
(\f(CRalias ls="/bin/ls -F"\fP).
.PP
The C shell (\fBcsh\fP)\(dg, originally written by Bill Joy while at
Berkeley, is widely used and quite popular for its interactive
facilities.  Bash includes a csh-compatible history expansion
mechanism (\*Q! history\*U), brace expansion, access to a stack
of directories via the
.B pushd ,
.B popd ,
and
.B dirs
builtins, and tilde expansion, to generate users' home directories.
Tilde expansion has also been adopted by both the Korn Shell and
POSIX.2.
.FS
\(dgBill Joy, An Introduction to the C Shell, \fIUNIX User's Supplementary
Documents\fP, University of California at Berkeley, 1986.
.FE
.PP
There were certain areas in which POSIX.2 felt standardization
was necessary, but no existing implementation provided the proper
behavior.  The working group invented and standardized functionality
in these areas, which Bash implements.  The
.B command
builtin was invented so that shell functions could be written to
replace builtins; it makes the capabilities of the builtin
available to the function.  The reserved word \*Q!\*U was added
to negate the return value of a command or pipeline; it was nearly
impossible to express \*Qif not x\*U cleanly using the sh language.
There exist multiple incompatible implementations of the 
.B test
builtin, which tests files for type and other attributes and performs
arithmetic and string comparisons.
POSIX considered none of these correct, so the standard
behavior was specified in terms of the number of arguments to the
command.  POSIX.2 dictates exactly what will happen when four or
fewer arguments are given to
.B test ,
and leaves the behavior undefined when more arguments are supplied.
Bash uses the POSIX.2 algorithm, which was conceived by David Korn.
.NH 2
Features not in the Bourne Shell
.PP
There are a number of minor differences between Bash and the
version of sh present on most other versions of \s-1UNIX\s+1.  The majority
of these are due to the POSIX standard, but some are the result of
Bash adopting features from other shells.  For instance, Bash
includes the new \*Q!\*U reserved word, the
.B command
builtin, the ability of the
.B read
builtin to correctly return a line ending with a backslash, symbolic
arguments to the
.B umask
builtin, variable substring removal, a way to get the length of a variable,
and the new algorithm for the
.B test
builtin from the POSIX.2 standard, none of which appear in sh.
.PP
Bash also implements the \*Q$(...)\*U command substitution syntax,
which supersedes the sh `...` construct.
The \*Q$(...)\*U construct expands to the output of the command
contained within the
parentheses, with trailing newlines removed.  The sh syntax is
accepted for backwards compatibility, but the \*Q$(...)\*U form
is preferred because its quoting rules are much simpler and it
is easier to nest.
.PP
The Bourne shell does not provide such features as brace expansion,
the ability
to define a variable and a function with the same name, local variables
in shell functions, the ability to enable and disable individual
builtins or write a function to replace a builtin, or a means to
export a shell function to a child process.
.PP
Bash has closed
a long-standing shell security hole by not using the
.B $IFS
variable to split each word read by the shell, but splitting only
the results of expansion (ksh and the 4.4 BSD sh have fixed this
as well).  Useful behavior such as a means to abort
execution of a script read with the \*Q.\*U command using the
\fBreturn\fP builtin or automatically
exporting variables in the shell's environment to children is also
not present in the Bourne shell.  Bash provides a much more powerful
environment for both interactive use and programming.
.NH 1
Bash-specific Features
.PP
This section details a few of the features which make Bash unique.
Most of them provide improved interactive use, but a few programming
improvements are present as well.  Full descriptions of these
features can be found in the Bash documentation.
.NH 2
Startup Files
.PP
Bash executes startup files differently than other shells.  The Bash
behavior is a compromise between the csh principle of startup files
with fixed names executed for each shell and the sh
\*Qminimalist\*U behavior.  An interactive instance of Bash started
as a login shell reads and executes
.I ~/.bash_profile
(the file .bash_profile in the user's home directory), if it exists.
An interactive non-login shell reads and executes
.I ~/.bashrc .
A non-interactive shell (one begun to execute a shell script, for
example) reads no fixed startup file, but uses the value of the variable
.B $ENV ,
if set, as the name of a startup file.  The ksh practice of reading
.B $ENV
for every shell, with the accompanying difficulty of defining the
proper variables and functions for interactive and non-interactive
shells or having the file read only for interactive shells, was
considered too complex.  Ease of use won out here.  Interestingly,
the next release of ksh will change to reading
.B $ENV
only for interactive shells.
.NH 2
New Builtin Commands
.PP
There are a few builtins which are new or have been extended in Bash.
The
.B enable
builtin allows builtin commands to be turned on and off arbitrarily.
To use the version of
.I echo
found in a user's search path rather than the Bash builtin,
\f(CRenable -n echo\fP suffices.  The
.B help
builtin provides
quick synopses of the shell facilities without requiring
access to a manual page.
.B Builtin
is similar to
.B command
in that it bypasses shell functions and directly executes builtin
commands.  Access to a csh-style stack of directories is provided
via the