aboutsummaryrefslogtreecommitdiffstats
path: root/doc/article.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/article.txt')
-rw-r--r--doc/article.txt1111
1 files changed, 1111 insertions, 0 deletions
diff --git a/doc/article.txt b/doc/article.txt
new file mode 100644
index 0000000..c19ff92
--- /dev/null
+++ b/doc/article.txt
@@ -0,0 +1,1111 @@
+
+
+
+
+
+
+
+
+
+ Bash - The GNU shell*
+
+
+ Chet Ramey
+ Case Western Reserve University
+ chet@po.cwru.edu
+
+
+
+
+
+
+_1. _I_n_t_r_o_d_u_c_t_i_o_n
+
+ _B_a_s_h is the shell, or command language interpreter,
+that will appear in the GNU operating system. The name is
+an acronym for the "Bourne-Again SHell", a pun on Steve
+Bourne, the author of the direct ancestor of the current
+UNIX|- shell /_b_i_n/_s_h, which appeared in the Seventh Edition
+Bell Labs Research version of UNIX.
+
+ Bash is an sh-compatible shell that incorporates useful
+features from the Korn shell (ksh) and the C shell (csh),
+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.
+
+ 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 port-
+able. It currently runs on nearly every version of UNIX 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 UNIX-like systems such as QNX and
+Minix are part of the distribution.
+
+ 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.
+
+_2. _W_h_a_t'_s _P_O_S_I_X, _a_n_y_w_a_y?
+
+ _P_O_S_I_X is a name originally coined by Richard Stallman
+_________________________
+*An earlier version of this article appeared in The
+Linux Journal.
+|- UNIX is a trademark of Bell Laboratories.
+
+
+
+
+ October 28, 1994
+
+
+
+
+
+ - 2 -
+
+
+for a family of open system standards based on UNIX. There
+are a number of aspects of UNIX under consideration for
+standardization, from the basic system services at the sys-
+tem call and C library level to applications and tools to
+system administration and management. Each area of stan-
+dardization is assigned to a working group in the 1003
+series.
+
+ The POSIX Shell and Utilities standard has been
+developed by IEEE Working Group 1003.2 (POSIX.2).|= It con-
+centrates 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:
+
+o+ Aspects of the shell's syntax and command language. A
+ number of special builtins such as _c_d and _e_x_e_c are
+ being specified as part of the shell, since their func-
+ tionality usually cannot be implemented by a separate
+ executable;
+
+o+ A set of utilities to be called by shell scripts and
+ applications. Examples are programs like _s_e_d, _t_r, and
+ _a_w_k. Utilities commonly implemented as shell builtins
+ are described in this section, such as _t_e_s_t and _k_i_l_l.
+ An expansion of this section's scope, termed the User
+ Portability Extension, or UPE, has standardized
+ interactive programs such as _v_i and _m_a_i_l_x;
+
+o+ A group of functional interfaces to services provided
+ by the shell, such as the traditional system() C
+ library function. There are functions to perform shell
+ word expansions, perform filename expansion (_g_l_o_b_b_i_n_g),
+ obtain values of POSIX.2 system configuration vari-
+ ables, retrieve values of environment variables
+ (getenv()), _a_n_d _o_t_h_e_r _s_e_r_v_i_c_e_s;
+
+o+ A suite of "development" utilities such as _c_8_9 (the
+ POSIX.2 version of _c_c), and _y_a_c_c.
+
+ 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 con-
+trol and program execution constructs, I/O redirection and
+pipelining, argument handling, variable expansion, and quot-
+ing. The _s_p_e_c_i_a_l builtins, which must be implemented as
+part of the shell to provide the desired functionality, are
+_________________________
+|=IEEE, _I_E_E_E _S_t_a_n_d_a_r_d _f_o_r _I_n_f_o_r_m_a_t_i_o_n _T_e_c_h_n_o_l_o_g_y --
+_P_o_r_t_a_b_l_e _O_p_e_r_a_t_i_n_g _S_y_s_t_e_m _I_n_t_e_r_f_a_c_e (_P_O_S_I_X) _P_a_r_t _2:
+_S_h_e_l_l _a_n_d _U_t_i_l_i_t_i_e_s, 1992.
+
+
+
+
+ October 28, 1994
+
+
+
+
+
+ - 3 -
+
+
+specified as being part of the shell; examples of these are
+_e_v_a_l and _e_x_p_o_r_t. 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
+_r_e_a_d and _t_e_s_t. 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 _v_i-style line editing commands have been standardized;
+_e_m_a_c_s editing commands were left out due to objections.
+
+ While POSIX.2 includes much of what the shell has trad-
+itionally provided, some important things have been omitted
+as being "beyond its scope." There is, for instance, no
+mention of a difference between a _l_o_g_i_n 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 ._p_r_o_f_i_l_e.
+
+_3. _B_a_s_i_c _B_a_s_h _f_e_a_t_u_r_e_s
+
+ 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 (_f_o_r, _i_f, _w_h_i_l_e,
+etc.). All of the Bourne shell builtins, including those
+not specified in the POSIX.2 standard, appear in Bash.
+Shell _f_u_n_c_t_i_o_n_s, 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 _P_S_1, _I_F_S, and _P_A_T_H. Bash implements essen-
+tially 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.
+
+ The Korn Shell (ksh) is a descendent of the Bourne
+shell written at AT&T Bell Laboratories by David Korn|-. 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 _R_A_N_D_O_M and _R_E_P_L_Y, the _t_y_p_e_s_e_t builtin, the ability
+to remove substrings from variables based on patterns, and
+shell arithmetic. _R_A_N_D_O_M expands to a random number each
+time it is referenced; assigning a value to _R_A_N_D_O_M seeds the
+_________________________
+|-Morris Bolsky and David Korn, _T_h_e _K_o_r_n_S_h_e_l_l _C_o_m_m_a_n_d
+_a_n_d _P_r_o_g_r_a_m_m_i_n_g _L_a_n_g_u_a_g_e, Prentice Hall, 1989.
+
+
+
+
+ October 28, 1994
+
+
+
+
+
+ - 4 -
+
+
+random number generator. _R_E_P_L_Y is the default variable used
+by the _r_e_a_d builtin when no variable names are supplied as
+arguments. The _t_y_p_e_s_e_t builtin is used to define variables
+and give them attributes such as readonly. 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 avail-
+able, with the same precedence rules:
+9 $ echo $((3 + 5 * 32))
+ 163
+9
+For interactive use, Bash implements ksh-style aliases and
+builtins such as _f_c (discussed below) and _j_o_b_s. Bash
+aliases allow a string to be substituted for a command name.
+They can be used to create a mnemonic for a UNIX command
+name (alias del=rm), to expand a single word to a complex
+command (alias news='xterm -g 80x45 -title trn -e trn -e -S1
+-N &'), or to ensure that a command is invoked with a basic
+set of options (alias ls="/bin/ls -F").
+
+ The C shell (csh)|-, originally written by Bill Joy
+while at Berkeley, is widely used and quite popular for its
+interactive facilities. Bash includes a csh-compatible his-
+tory expansion mechanism ("! history"), brace expansion,
+access to a stack of directories via the _p_u_s_h_d, _p_o_p_d, and
+_d_i_r_s builtins, and tilde expansion, to generate users' home
+directories. Tilde expansion has also been adopted by both
+the Korn Shell and POSIX.2.
+
+ There were certain areas in which POSIX.2 felt stan-
+dardization was necessary, but no existing implementation
+provided the proper behavior. The working group invented
+and standardized functionality in these areas, which Bash
+implements. The _c_o_m_m_a_n_d 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 "!" was added to negate the return value of a
+command or pipeline; it was nearly impossible to express "if
+not x" cleanly using the sh language. There exist multiple
+incompatible implementations of the _t_e_s_t 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 argu-
+ments are given to _t_e_s_t, and leaves the behavior undefined
+when more arguments are supplied. Bash uses the POSIX.2
+_________________________
+|-Bill Joy, An Introduction to the C Shell, _U_N_I_X _U_s_e_r'_s
+_S_u_p_p_l_e_m_e_n_t_a_r_y _D_o_c_u_m_e_n_t_s, University of California at
+Berkeley, 1986.
+
+
+
+
+ October 28, 1994
+
+
+
+
+
+ - 5 -
+
+
+algorithm, which was conceived by David Korn.
+
+_3._1. _F_e_a_t_u_r_e_s _n_o_t _i_n _t_h_e _B_o_u_r_n_e _S_h_e_l_l
+
+ There are a number of minor differences between Bash
+and the version of sh present on most other versions of
+UNIX. 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 "!" reserved
+word, the _c_o_m_m_a_n_d builtin, the ability of the _r_e_a_d builtin
+to correctly return a line ending with a backslash, symbolic
+arguments to the _u_m_a_s_k builtin, variable substring removal,
+a way to get the length of a variable, and the new algorithm
+for the _t_e_s_t builtin from the POSIX.2 standard, none of
+which appear in sh.
+
+ Bash also implements the "$(...)" command substitution
+syntax, which supersedes the sh `...` construct. The
+"$(...)" construct expands to the output of the command con-
+tained within the parentheses, with trailing newlines
+removed. The sh syntax is accepted for backwards compati-
+bility, but the "$(...)" form is preferred because its quot-
+ing rules are much simpler and it is easier to nest.
+
+ 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 func-
+tions, 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.
+
+ Bash has closed a long-standing shell security hole by
+not using the $_I_F_S 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
+"." command using the return 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.
+
+_4. _B_a_s_h-_s_p_e_c_i_f_i_c _F_e_a_t_u_r_e_s
+
+ 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.
+
+_4._1. _S_t_a_r_t_u_p _F_i_l_e_s
+
+ Bash executes startup files differently than other
+shells. The Bash behavior is a compromise between the csh
+
+
+
+ October 28, 1994
+
+
+
+
+
+ - 6 -
+
+
+principle of startup files with fixed names executed for
+each shell and the sh "minimalist" behavior. An interactive
+instance of Bash started as a login shell reads and executes
+~/._b_a_s_h__p_r_o_f_i_l_e (the file .bash_profile in the user's home
+directory), if it exists. An interactive non-login shell
+reads and executes ~/._b_a_s_h_r_c. 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 $_E_N_V, if
+set, as the name of a startup file. The ksh practice of
+reading $_E_N_V for every shell, with the accompanying diffi-
+culty 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 com-
+plex. Ease of use won out here. Interestingly, the next
+release of ksh will change to reading $_E_N_V only for interac-
+tive shells.
+
+_4._2. _N_e_w _B_u_i_l_t_i_n _C_o_m_m_a_n_d_s
+
+ There are a few builtins which are new or have been
+extended in Bash. The _e_n_a_b_l_e builtin allows builtin com-
+mands to be turned on and off arbitrarily. To use the ver-
+sion of _e_c_h_o found in a user's search path rather than the
+Bash builtin, enable -n echo suffices. The _h_e_l_p builtin
+provides quick synopses of the shell facilities without
+requiring access to a manual page. _B_u_i_l_t_i_n is similar to
+_c_o_m_m_a_n_d in that it bypasses shell functions and directly
+executes builtin commands. Access to a csh-style stack of
+directories is provided via the _p_u_s_h_d, _p_o_p_d, and _d_i_r_s buil-
+tins. _P_u_s_h_d and _p_o_p_d insert and remove directories from the
+stack, respectively, and _d_i_r_s lists the stack contents. On
+systems that allow fine-grained control of resources, the
+_u_l_i_m_i_t builtin can be used to tune these settings. _U_l_i_m_i_t
+allows a user to control, among other things, whether core
+dumps are to be generated, how much memory the shell or a
+child process is allowed to allocate, and how large a file
+created by a child process can grow. The _s_u_s_p_e_n_d command
+will stop the shell process when job control is active; most
+other shells do not allow themselves to be stopped like
+that. _T_y_p_e, the Bash answer to _w_h_i_c_h and _w_h_e_n_c_e, shows what
+will happen when a word is typed as a command:
+9 $ type export
+ export is a shell builtin
+ $ type -t export
+ builtin
+ $ type bash
+ bash is /bin/bash
+ $ type cd
+ cd is a function
+ cd ()
+ {
+ builtin cd ${1+"$@"} && xtitle $HOST: $PWD
+ }
+9
+
+
+ October 28, 1994
+
+
+
+
+
+ - 7 -
+
+
+Various modes tell what a command word is (reserved word,
+alias, function, builtin, or file) or which version of a
+command will be executed based on a user's search path.
+Some of this functionality has been adopted by POSIX.2 and
+folded into the _c_o_m_m_a_n_d utility.
+
+_4._3. _E_d_i_t_i_n_g _a_n_d _C_o_m_p_l_e_t_i_o_n
+
+ One area in which Bash shines is command line editing.
+Bash uses the _r_e_a_d_l_i_n_e library to read and edit lines when
+interactive. Readline is a powerful and flexible input
+facility that a user can configure to individual tastes. It
+allows lines to be edited using either emacs or vi commands,
+where those commands are appropriate. The full capability
+of emacs is not present - there is no way to execute a named
+command with M-x, for instance - but the existing commands
+are more than adequate. The vi mode is compliant with the
+command line editing standardized by POSIX.2.
+
+ Readline is fully customizable. In addition to the
+basic commands and key bindings, the library allows users to
+define additional key bindings using a startup file. The
+_i_n_p_u_t_r_c file, which defaults to the file ~/._i_n_p_u_t_r_c, is read
+each time readline initializes, permitting users to maintain
+a consistent interface across a set of programs. Readline
+includes an extensible interface, so each program using the
+library can add its own bindable commands and program-
+specific key bindings. Bash uses this facility to add bind-
+ings that perform history expansion or shell word expansions
+on the current input line.
+
+ Readline interprets a number of variables which further
+tune its behavior. Variables exist to control whether or
+not eight-bit characters are directly read as input or con-
+verted to meta-prefixed key sequences (a meta-prefixed key
+sequence consists of the character with the eighth bit
+zeroed, preceded by the _m_e_t_a-_p_r_e_f_i_x character, usually
+escape, which selects an alternate keymap), to decide
+whether to output characters with the eighth bit set
+directly or as a meta-prefixed key sequence, whether or not
+to wrap to a new screen line when a line being edited is
+longer than the screen width, the keymap to which subsequent
+key bindings should apply, or even what happens when read-
+line wants to ring the terminal's bell. All of these vari-
+ables can be set in the inputrc file.
+
+ The startup file understands a set of C preprocessor-
+like conditional constructs which allow variables or key
+bindings to be assigned based on the application using read-
+line, the terminal currently being used, or the editing
+mode. Users can add program-specific bindings to make their
+lives easier: I have bindings that let me edit the value of
+$_P_A_T_H and double-quote the current or previous word:
+9 # Macros that are convenient for shell interaction
+
+
+9 October 28, 1994
+
+
+
+
+
+ - 8 -
+
+
+ $if Bash
+ # edit the path
+ "\C-xp": "PATH=${PATH}\e\C-e\C-a\ef\C-f"
+ # prepare to type a quoted word -- insert open and close double
+ # quotes and move to just after the open quote
+ "\C-x\"": "\"\"\C-b"
+ # Quote the current or previous word
+ "\C-xq": "\eb\"\ef\""
+ $endif
+9
+There is a readline command to re-read the file, so users
+can edit the file, change some bindings, and begin to use
+them almost immediately.
+
+ Bash implements the _b_i_n_d builtin for more dyamic con-
+trol of readline than the startup file permits. _B_i_n_d is
+used in several ways. In _l_i_s_t mode, it can display the
+current key bindings, list all the readline editing direc-
+tives available for binding, list which keys invoke a given
+directive, or output the current set of key bindings in a
+format that can be incorporated directly into an inputrc
+file. In _b_a_t_c_h mode, it reads a series of key bindings
+directly from a file and passes them to readline. In its
+most common usage, _b_i_n_d takes a single string and passes it
+directly to readline, which interprets the line as if it had
+just been read from the inputrc file. Both key bindings and
+variable assignments may appear in the string given to _b_i_n_d.
+
+ The readline library also provides an interface for
+_w_o_r_d _c_o_m_p_l_e_t_i_o_n. When the _c_o_m_p_l_e_t_i_o_n character (usually
+TAB) is typed, readline looks at the word currently being
+entered and computes the set of filenames of which the
+current word is a valid prefix. If there is only one possi-
+ble completion, the rest of the characters are inserted
+directly, otherwise the common prefix of the set of
+filenames is added to the current word. A second TAB char-
+acter entered immediately after a non-unique completion
+causes readline to list the possible completions; there is
+an option to have the list displayed immediately. Readline
+provides hooks so that applications can provide specific
+types of completion before the default filename completion
+is attempted. This is quite flexible, though it is not com-
+pletely user-programmable. Bash, for example, can complete
+filenames, command names (including aliases, builtins, shell
+reserved words, shell functions, and executables found in
+the file system), shell variables, usernames, and hostnames.
+It uses a set of heuristics that, while not perfect, is gen-
+erally quite good at determining what type of completion to
+attempt.
+
+_4._4. _H_i_s_t_o_r_y
+
+ Access to the list of commands previously entered (the
+_c_o_m_m_a_n_d _h_i_s_t_o_r_y) is provided jointly by Bash and the
+
+
+9 October 28, 1994
+
+
+
+
+
+ - 9 -
+
+
+readline library. Bash provides variables ($HISTFILE,
+$HISTSIZE, and $HISTCONTROL) and the _h_i_s_t_o_r_y and _f_c builtins
+to manipulate the history list. The value of $_H_I_S_T_F_I_L_E
+specifes the file where Bash writes the command history on
+exit and reads it on startup. $_H_I_S_T_S_I_Z_E is used to limit
+the number of commands saved in the history. $_H_I_S_T_C_O_N_T_R_O_L
+provides a crude form of control over which commands are
+saved on the history list: a value of _i_g_n_o_r_e_s_p_a_c_e means to
+not save commands which begin with a space; a value of
+_i_g_n_o_r_e_d_u_p_s means to not save commands identical to the last
+command saved. $HISTCONTROL was named $history_control in
+earlier versions of Bash; the old name is still accepted for
+backwards compatibility. The _h_i_s_t_o_r_y command can read or
+write files containing the history list and display the
+current list contents. The _f_c builtin, adopted from POSIX.2
+and the Korn Shell, allows display and re-execution, with
+optional editing, of commands from the history list. The
+readline library offers a set of commands to search the his-
+tory list for a portion of the current input line or a
+string typed by the user. Finally, the _h_i_s_t_o_r_y library,
+generally incorporated directly into the readline library,
+implements a facility for history recall, expansion, and
+re-execution of previous commands very similar to csh ("bang
+history", so called because the exclamation point introduces
+a history substitution):
+9 $ echo a b c d e
+ a b c d e
+ $ !! f g h i
+ echo a b c d e f g h i
+ a b c d e f g h i
+ $ !-2
+ echo a b c d e
+ a b c d e
+ $ echo !-2:1-4
+ echo a b c d
+ a b c d
+9
+The command history is only saved when the shell is interac-
+tive, so it is not available for use by shell scripts.
+
+_4._5. _N_e_w _S_h_e_l_l _V_a_r_i_a_b_l_e_s
+
+ There are a number of convenience variables that Bash
+interprets to make life easier. These include _F_I_G_N_O_R_E,
+which is a set of filename suffixes identifying files to
+exclude when completing filenames; _H_O_S_T_T_Y_P_E, which is
+automatically set to a string describing the type of
+hardware on which Bash is currently executing;
+_c_o_m_m_a_n_d__o_r_i_e_n_t_e_d__h_i_s_t_o_r_y, which directs Bash to save all
+lines of a multiple-line command such as a _w_h_i_l_e or _f_o_r loop
+in a single history entry, allowing easy re-editing; and
+_I_G_N_O_R_E_E_O_F, whose value indicates the number of consecutive
+EOF characters that an interactive shell will read before
+
+
+
+ October 28, 1994
+
+
+
+
+
+ - 10 -
+
+
+exiting - an easy way to keep yourself from being logged out
+accidentally. The _a_u_t_o__r_e_s_u_m_e variable alters the way the
+shell treats simple command names: if job control is active,
+and this variable is set, single-word simple commands
+without redirections cause the shell to first look for and
+restart a suspended job with that name before starting a new
+process.
+
+_4._6. _B_r_a_c_e _E_x_p_a_n_s_i_o_n
+
+ Since sh offers no convenient way to generate arbitrary
+strings that share a common prefix or suffix (filename
+expansion requires that the filenames exist), Bash imple-
+ments _b_r_a_c_e _e_x_p_a_n_s_i_o_n, a capability picked up from csh.
+Brace expansion is similar to filename expansion, but the
+strings generated need not correspond to existing files. A
+brace expression consists of an optional _p_r_e_a_m_b_l_e, followed
+by a pair of braces enclosing a series of comma-separated
+strings, and an optional _p_o_s_t_a_m_b_l_e. The preamble is
+prepended to each string within the braces, and the postam-
+ble is then appended to each resulting string:
+9 $ echo a{d,c,b}e
+ ade ace abe
+9
+As this example demonstrates, the results of brace expansion
+are not sorted, as they are by filename expansion.
+
+_4._7. _P_r_o_c_e_s_s _S_u_b_s_t_i_t_u_t_i_o_n
+
+ On systems that can support it, Bash provides a facil-
+ity known as _p_r_o_c_e_s_s _s_u_b_s_t_i_t_u_t_i_o_n. Process substitution is
+similar to command substitution in that its specification
+includes a command to execute, but the shell does not col-
+lect the command's output and insert it into the command
+line. Rather, Bash opens a pipe to the command, which is
+run in the background. The shell uses named pipes (FIFOs)
+or the /_d_e_v/_f_d method of naming open files to expand the
+process substitution to a filename which connects to the
+pipe when opened. This filename becomes the result of the
+expansion. Process substitution can be used to compare the
+outputs of two different versions of an application as part
+of a regression test:
+9 $ cmp <(old_prog) <(new_prog)
+9
+_4._8. _P_r_o_m_p_t _C_u_s_t_o_m_i_z_a_t_i_o_n
+
+ One of the more popular interactive features that Bash
+provides is the ability to customize the prompt. Both $_P_S_1
+and $_P_S_2, the primary and secondary prompts, are expanded
+before being displayed. Parameter and variable expansion is
+performed when the prompt string is expanded, so any shell
+variable can be put into the prompt (e.g., $_S_H_L_V_L, which
+
+
+
+ October 28, 1994
+
+
+
+
+
+ - 11 -
+
+
+indicates how deeply the current shell is nested). Bash
+specially interprets characters in the prompt string pre-
+ceded by a backslash. Some of these backslash escapes are
+replaced with the current time, the date, the current work-
+ing directory, the username, and the command number or his-
+tory number of the command being entered. There is even a
+backslash escape to cause the shell to change its prompt
+when running as root after an _s_u. Before printing each pri-
+mary prompt, Bash expands the variable $_P_R_O_M_P_T__C_O_M_M_A_N_D and,
+if it has a value, executes the expanded value as a command,
+allowing additional prompt customization. For example, this
+assignment causes the current user, the current host, the
+time, the last component of the current working directory,
+the level of shell nesting, and the history number of the
+current command to be embedded into the primary prompt:
+9 $ PS1='\u@\h [\t] \W($SHLVL:\!)\$ '
+ chet@odin [21:03:44] documentation(2:636)$ cd ..
+ chet@odin [21:03:54] src(2:637)$
+9
+The string being assigned is surrounded by single quotes so
+that if it is exported, the value of $_S_H_L_V_L will be updated
+by a child shell:
+9 chet@odin [21:17:35] src(2:638)$ export PS1
+ chet@odin [21:17:40] src(2:639)$ bash
+ chet@odin [21:17:46] src(3:696)$
+9
+The \$ escape is displayed as "$" when running as a normal
+user, but as "#" when running as root.
+
+_4._9. _F_i_l_e _S_y_s_t_e_m _V_i_e_w_s
+
+ Since Berkeley introduced symbolic links in 4.2 BSD,
+one of their most annoying properties has been the "warping"
+to a completely different area of the file system when using
+_c_d, and the resultant non-intuitive behavior of "cd ..".
+The UNIX kernel treats symbolic links _p_h_y_s_i_c_a_l_l_y. When the
+kernel is translating a pathname in which one component is a
+symbolic link, it replaces all or part of the pathname while
+processing the link. If the contents of the symbolic link
+begin with a slash, the kernel replaces the pathname
+entirely; if not, the link contents replace the current com-
+ponent. In either case, the symbolic link is visible. If
+the link value is an absolute pathname, the user finds him-
+self in a completely different part of the file system.
+
+ Bash provides a _l_o_g_i_c_a_l view of the file system. In
+this default mode, command and filename completion and buil-
+tin commands such as _c_d and _p_u_s_h_d which change the current
+working directory transparently follow symbolic links as if
+they were directories. The $_P_W_D variable, which holds the
+shell's idea of the current working directory, depends on
+the path used to reach the directory rather than its
+
+
+
+ October 28, 1994
+
+
+
+
+
+ - 12 -
+
+
+physical location in the local file system hierarchy. For
+example:
+9 $ cd /usr/local/bin
+ $ echo $PWD
+ /usr/local/bin
+ $ pwd
+ /usr/local/bin
+ $ /bin/pwd
+ /net/share/sun4/local/bin
+ $ cd ..
+ $ pwd
+ /usr/local
+ $ /bin/pwd
+ /net/share/sun4/local
+ $ cd ..
+ $ pwd
+ /usr
+ $ /bin/pwd
+ /usr
+9
+One problem with this, of course, arises when programs that
+do not understand the shell's logical notion of the file
+system interpret ".." differently. This generally happens
+when Bash completes filenames containing ".." according to a
+logical hierarchy which does not correspond to their physi-
+cal location. For users who find this troublesome, a
+corresponding _p_h_y_s_i_c_a_l view of the file system is available:
+9 $ cd /usr/local/bin
+ $ pwd
+ /usr/local/bin
+ $ set -o physical
+ $ pwd
+ /net/share/sun4/local/bin
+9
+_4._1_0. _I_n_t_e_r_n_a_t_i_o_n_a_l_i_z_a_t_i_o_n
+
+ One of the most significant improvements in version
+1.13 of Bash was the change to "eight-bit cleanliness".
+Previous versions used the eighth bit of characters to mark
+whether or not they were quoted when performing word expan-
+sions. While this did not affect the majority of users,
+most of whom used only seven-bit ASCII characters, some
+found it confining. Beginning with version 1.13, Bash
+implemented a different quoting mechanism that did not alter
+the eighth bit of characters. This allowed Bash to manipu-
+late files with "odd" characters in their names, but did
+nothing to help users enter those names, so version 1.13
+introduced changes to readline that made it eight-bit clean
+as well. Options exist that force readline to attach no
+special significance to characters with the eighth bit set
+(the default behavior is to convert these characters to
+meta-prefixed key sequences) and to output these characters
+
+
+
+ October 28, 1994
+
+
+
+
+
+ - 13 -
+
+
+without conversion to meta-prefixed sequences. These
+changes, along with the expansion of keymaps to a full eight
+bits, enable readline to work with most of the ISO-8859 fam-
+ily of character sets, used by many European countries.
+
+_4._1_1. _P_O_S_I_X _M_o_d_e
+
+ Although Bash is intended to be POSIX.2 conformant,
+there are areas in which the default behavior is not compa-
+tible with the standard. For users who wish to operate in a
+strict POSIX.2 environment, Bash implements a _P_O_S_I_X _m_o_d_e.
+When this mode is active, Bash modifies its default opera-
+tion where it differs from POSIX.2 to match the standard.
+POSIX mode is entered when Bash is started with the -_p_o_s_i_x
+option. This feature is also available as an option to the
+set builtin, set -o posix. For compatibility with other GNU
+software that attempts to be POSIX.2 compliant, Bash also
+enters POSIX mode if the variable $_P_O_S_I_X_L_Y__C_O_R_R_E_C_T is set
+when Bash is started or assigned a value during execution.
+$_P_O_S_I_X__P_E_D_A_N_T_I_C is accepted as well, to be compatible with
+some older GNU utilities. When Bash is started in POSIX
+mode, for example, it sources the file named by the value of
+$_E_N_V rather than the "normal" startup files, and does not
+allow reserved words to be aliased.
+
+_5. _N_e_w _F_e_a_t_u_r_e_s _a_n_d _F_u_t_u_r_e _P_l_a_n_s
+
+ There are several features introduced in the current
+version of Bash, version 1.14, and a number under considera-
+tion for future releases. This section will briefly detail
+the new features in version 1.14 and describe several
+features that may appear in later versions.
+
+_5._1. _N_e_w _F_e_a_t_u_r_e_s _i_n _B_a_s_h-_1._1_4
+
+ The new features available in Bash-1.14 answer several
+of the most common requests for enhancements. Most notably,
+there is a mechanism for including non-visible character
+sequences in prompts, such as those which cause a terminal
+to print characters in different colors or in standout mode.
+There was nothing preventing the use of these sequences in
+earlier versions, but the readline redisplay algorithm
+assumed each character occupied physical screen space and
+would wrap lines prematurely.
+
+ Readline has a few new variables, several new bindable
+commands, and some additional emacs mode default key bind-
+ings. A new history search mode has been implemented: in
+this mode, readline searches the history for lines beginning
+with the characters between the beginning of the current
+line and the cursor. The existing readline incremental
+search commands no longer match identical lines more than
+once. Filename completion now expands variables in direc-
+tory names. The history expansion facilities are now nearly
+
+
+
+ October 28, 1994
+
+
+
+
+
+ - 14 -
+
+
+completely csh-compatible: missing modifiers have been added
+and history substitution has been extended.
+
+ Several of the features described earlier, such as _s_e_t
+-_o _p_o_s_i_x and $_P_O_S_I_X__P_E_D_A_N_T_I_C, are new in version 1.14.
+There is a new shell variable, _O_S_T_Y_P_E, to which Bash assigns
+a value that identifies the version of UNIX it's running on
+(great for putting architecture-specific binary directories
+into the $PATH). Two variables have been renamed: $_H_I_S_T_C_O_N_-
+_T_R_O_L replaces $_h_i_s_t_o_r_y__c_o_n_t_r_o_l, and $_H_O_S_T_F_I_L_E replaces
+$_h_o_s_t_n_a_m_e__c_o_m_p_l_e_t_i_o_n__f_i_l_e. In both cases, the old names are
+accepted for backwards compatibility. The ksh _s_e_l_e_c_t con-
+struct, which allows the generation of simple menus, has
+been implemented. New capabilities have been added to
+existing variables: $_a_u_t_o__r_e_s_u_m_e can now take values of
+_e_x_a_c_t or _s_u_b_s_t_r_i_n_g, and $_H_I_S_T_C_O_N_T_R_O_L understands the value
+_i_g_n_o_r_e_b_o_t_h, which combines the two previously acceptable
+values. The _d_i_r_s builtin has acquired options to print out
+specific members of the directory stack. The $_n_o_l_i_n_k_s vari-
+able, which forces a physical view of the file system, has
+been superseded by the -_P option to the _s_e_t builtin
+(equivalent to set -o physical); the variable is retained
+for backwards compatibility. The version string contained
+in $_B_A_S_H__V_E_R_S_I_O_N now includes an indication of the patch
+level as well as the "build version". Some little-used
+features have been removed: the _b_y_e synonym for _e_x_i_t and
+the $_N_O__P_R_O_M_P_T__V_A_R_S variable are gone. There is now an
+organized test suite that can be run as a regression test
+when building a new version of Bash.
+
+ The documentation has been thoroughly overhauled: there
+is a new manual page on the readline library and the _i_n_f_o
+file has been updated to reflect the current version. As
+always, as many bugs as possible have been fixed, although
+some surely remain.
+
+_5._2. _O_t_h_e_r _F_e_a_t_u_r_e_s
+
+ There are a few features that I hope to include in
+later Bash releases. Some are based on work already done in
+other shells.
+
+ In addition to simple variables, a future release of
+Bash will include one-dimensional arrays, using the ksh
+implementation of arrays as a model. Additions to the ksh
+syntax, such as _v_a_r_n_a_m_e=( ... ) to assign a list of words
+directly to an array and a mechanism to allow the _r_e_a_d buil-
+tin to read a list of values directly into an array, would
+be desirable. Given those extensions, the ksh _s_e_t -_A syntax
+may not be worth supporting (the -_A option assigns a list of
+values to an array, but is a rather peculiar special case).
+
+ Some shells include a means of _p_r_o_g_r_a_m_m_a_b_l_e word com-
+pletion, where the user specifies on a per-command basis how
+
+
+
+ October 28, 1994
+
+
+
+
+
+ - 15 -
+
+
+the arguments of the command are to be treated when comple-
+tion is attempted: as filenames, hostnames, executable
+files, and so on. The other aspects of the current Bash
+implementation could remain as-is; the existing heuristics
+would still be valid. Only when completing the arguments to
+a simple command would the programmable completion be in
+effect.
+
+ It would also be nice to give the user finer-grained
+control over which commands are saved onto the history list.
+One proposal is for a variable, tentatively named _H_I_S_T_I_G_-
+_N_O_R_E, which would contain a colon-separated list of com-
+mands. Lines beginning with these commands, after the res-
+trictions of $_H_I_S_T_C_O_N_T_R_O_L have been applied, would not be
+placed onto the history list. The shell pattern-matching
+capabilities could also be available when specifying the
+contents of $_H_I_S_T_I_G_N_O_R_E.
+
+ One thing that newer shells such as _w_k_s_h (also known as
+_d_t_k_s_h) provide is a command to dynamically load code imple-
+menting additional builtin commands into a running shell.
+This new builtin would take an object file or shared library
+implementing the "body" of the builtin (_x_x_x__b_u_i_l_t_i_n() for
+those familiar with Bash internals) and a structure contain-
+ing the name of the new command, the function to call when
+the new builtin is invoked (presumably defined in the shared
+object specified as an argument), and the documentation to
+be printed by the _h_e_l_p command (possibly present in the
+shared object as well). It would manage the details of
+extending the internal table of builtins.
+
+ A few other builtins would also be desirable: two are
+the POSIX.2 _g_e_t_c_o_n_f command, which prints the values of sys-
+tem configuration variables defined by POSIX.2, and a _d_i_s_o_w_n
+builtin, which causes a shell running with job control
+active to "forget about" one or more background jobs in its
+internal jobs table. Using _g_e_t_c_o_n_f, for example, a user
+could retrieve a value for $_P_A_T_H guaranteed to find all of
+the POSIX standard utilities, or find out how long filenames
+may be in the file system containing a specified directory.
+
+ There are no implementation timetables for any of these
+features, nor are there concrete plans to include them. If
+anyone has comments on these proposals, feel free to send me
+electronic mail.
+
+_6. _R_e_f_l_e_c_t_i_o_n_s _a_n_d _L_e_s_s_o_n_s _L_e_a_r_n_e_d
+
+ The lesson that has been repeated most often during
+Bash development is that there are dark corners in the
+Bourne shell, and people use all of them. In the original
+description of the Bourne shell, quoting and the shell gram-
+mar are both poorly specified and incomplete; subsequent
+descriptions have not helped much. The grammar presented in
+
+
+
+ October 28, 1994
+
+
+
+
+
+ - 16 -
+
+
+Bourne's paper describing the shell distributed with the
+Seventh Edition of UNIX|- is so far off that it does not
+allow the command who|wc. In fact, as Tom Duff states:
+
+ Nobody really knows what the Bourne shell's gram-
+ mar is. Even examination of the source code is
+ little help.|=
+
+The POSIX.2 standard includes a _y_a_c_c grammar that comes
+close to capturing the Bourne shell's behavior, but it
+disallows some constructs which sh accepts without complaint
+- and there are scripts out there that use them. It took a
+few versions and several bug reports before Bash implemented
+sh-compatible quoting, and there are still some "legal" sh
+constructs which Bash flags as syntax errors. Complete sh
+compatibility is a tough nut.
+
+ The shell is bigger and slower than I would like,
+though the current version is substantially faster than pre-
+viously. The readline library could stand a substantial
+rewrite. A hand-written parser to replace the current
+_y_a_c_c-generated one would probably result in a speedup, and
+would solve one glaring problem: the shell could parse com-
+mands in "$(...)" constructs as they are entered, rather
+than reporting errors when the construct is expanded.
+
+ As always, there is some chaff to go with the wheat.
+Areas of duplicated functionality need to be cleaned up.
+There are several cases where Bash treats a variable spe-
+cially to enable functionality available another way
+($notify vs. set -o notify and $nolinks vs. set -o physi-
+cal, for instance); the special treatment of the variable
+name should probably be removed. A few more things could
+stand removal; the $_a_l_l_o_w__n_u_l_l__g_l_o_b__e_x_p_a_n_s_i_o_n and
+$_g_l_o_b__d_o_t__f_i_l_e_n_a_m_e_s variables are of particularly question-
+able value. The $[...] arithmetic evaluation syntax is
+redundant now that the POSIX-mandated $((...)) construct has
+been implemented, and could be deleted. It would be nice if
+the text output by the _h_e_l_p builtin were external to the
+shell rather than compiled into it. The behavior enabled by
+$_c_o_m_m_a_n_d__o_r_i_e_n_t_e_d__h_i_s_t_o_r_y, which causes the shell to attempt
+to save all lines of a multi-line command in a single his-
+tory entry, should be made the default and the variable
+removed.
+
+
+_________________________
+|-S. R. Bourne, "UNIX Time-Sharing System: The UNIX
+Shell", _B_e_l_l _S_y_s_t_e_m _T_e_c_h_n_i_c_a_l _J_o_u_r_n_a_l, 57(6), July-
+August, 1978, pp. 1971-1990.
+|=Tom Duff, "Rc - A Shell for Plan 9 and UNIX systems",
+_P_r_o_c. _o_f _t_h_e _S_u_m_m_e_r _1_9_9_0 _E_U_U_G _C_o_n_f_e_r_e_n_c_e, London, July,
+1990, pp. 21-33.
+
+
+
+
+ October 28, 1994
+
+
+
+
+
+ - 17 -
+
+
+_7. _A_v_a_i_l_a_b_i_l_i_t_y
+
+ As with all other GNU software, Bash is available for
+anonymous FTP from _p_r_e_p._a_i._m_i_t._e_d_u:/_p_u_b/_g_n_u and from other
+GNU software mirror sites. The current version is in _b_a_s_h-
+_1._1_4._1._t_a_r._g_z in that directory. Use _a_r_c_h_i_e to find the
+nearest archive site. The latest version is always avail-
+able for FTP from _b_a_s_h._C_W_R_U._E_d_u:/_p_u_b/_d_i_s_t. Bash documenta-
+tion is available for FTP from _b_a_s_h._C_W_R_U._E_d_u:/_p_u_b/_b_a_s_h.
+
+ The Free Software Foundation sells tapes and CD-ROMs
+containing Bash; send electronic mail to gnu@prep.ai.mit.edu
+or call +1-617-876-3296 for more information.
+
+ Bash is also distributed with several versions of
+UNIX-compatible systems. It is included as /bin/sh and
+/bin/bash on several Linux distributions (more about the
+difference in a moment), and as contributed software in
+BSDI's BSD/386* and FreeBSD.
+
+ The Linux distribution deserves special mention. There
+are two configurations included in the standard Bash distri-
+bution: a "normal" configuration, in which all of the stan-
+dard features are included, and a "minimal" configuration,
+which omits job control, aliases, history and command line
+editing, the directory stack and _p_u_s_h_d/_p_o_p_d/_d_i_r_s, process
+substitution, prompt string special character decoding, and
+the _s_e_l_e_c_t construct. This minimal version is designed to
+be a drop-in replacement for the traditional UNIX /bin/sh,
+and is included as the Linux /bin/sh in several packagings.
+
+_8. _C_o_n_c_l_u_s_i_o_n
+
+ Bash is a worthy successor to sh. It is sufficiently
+portable to run on nearly every version of UNIX from 4.3 BSD
+to SVR4.2, and several UNIX workalikes. It is robust enough
+to replace sh on most of those systems, and provides more
+functionality. It has several thousand regular users, and
+their feedback has helped to make it as good as it is today
+- a testament to the benefits of free software.
+
+
+
+
+
+
+
+
+
+
+_________________________
+*BSD/386 is a trademark of Berkeley Software Design,
+Inc.
+
+
+
+
+ October 28, 1994
+
+