--- /dev/null
+
+
+
+
+
+
+
+
+
+ Bash - The GNU shell*
+
+
+ Chet Ramey
+ Case Western Reserve University
+ chet@po.cwru.edu
+
+
+
+
+
+
+_\b1. _\bI_\bn_\bt_\br_\bo_\bd_\bu_\bc_\bt_\bi_\bo_\bn
+
+ _\bB_\ba_\bs_\bh 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|\b- shell /_\bb_\bi_\bn/_\bs_\bh, 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.
+
+_\b2. _\bW_\bh_\ba_\bt'_\bs _\bP_\bO_\bS_\bI_\bX, _\ba_\bn_\by_\bw_\ba_\by?
+
+ _\bP_\bO_\bS_\bI_\bX is a name originally coined by Richard Stallman
+_________________________
+*An earlier version of this article appeared in The
+Linux Journal.
+|\b- 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).|\b= 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\b+ Aspects of the shell's syntax and command language. A
+ number of special builtins such as _\bc_\bd and _\be_\bx_\be_\bc are
+ being specified as part of the shell, since their func-
+ tionality usually cannot be implemented by a separate
+ executable;
+
+o\b+ A set of utilities to be called by shell scripts and
+ applications. Examples are programs like _\bs_\be_\bd, _\bt_\br, and
+ _\ba_\bw_\bk. Utilities commonly implemented as shell builtins
+ are described in this section, such as _\bt_\be_\bs_\bt and _\bk_\bi_\bl_\bl.
+ An expansion of this section's scope, termed the User
+ Portability Extension, or UPE, has standardized
+ interactive programs such as _\bv_\bi and _\bm_\ba_\bi_\bl_\bx;
+
+o\b+ 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 (_\bg_\bl_\bo_\bb_\bb_\bi_\bn_\bg),
+ obtain values of POSIX.2 system configuration vari-
+ ables, retrieve values of environment variables
+ (getenv()), _\ba_\bn_\bd _\bo_\bt_\bh_\be_\br _\bs_\be_\br_\bv_\bi_\bc_\be_\bs;
+
+o\b+ A suite of "development" utilities such as _\bc_\b8_\b9 (the
+ POSIX.2 version of _\bc_\bc), and _\by_\ba_\bc_\bc.
+
+ 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 _\bs_\bp_\be_\bc_\bi_\ba_\bl builtins, which must be implemented as
+part of the shell to provide the desired functionality, are
+_________________________
+|\b=IEEE, _\bI_\bE_\bE_\bE _\bS_\bt_\ba_\bn_\bd_\ba_\br_\bd _\bf_\bo_\br _\bI_\bn_\bf_\bo_\br_\bm_\ba_\bt_\bi_\bo_\bn _\bT_\be_\bc_\bh_\bn_\bo_\bl_\bo_\bg_\by --
+_\bP_\bo_\br_\bt_\ba_\bb_\bl_\be _\bO_\bp_\be_\br_\ba_\bt_\bi_\bn_\bg _\bS_\by_\bs_\bt_\be_\bm _\bI_\bn_\bt_\be_\br_\bf_\ba_\bc_\be (_\bP_\bO_\bS_\bI_\bX) _\bP_\ba_\br_\bt _\b2:
+_\bS_\bh_\be_\bl_\bl _\ba_\bn_\bd _\bU_\bt_\bi_\bl_\bi_\bt_\bi_\be_\bs, 1992.
+
+
+
+
+ October 28, 1994
+
+
+
+
+
+ - 3 -
+
+
+specified as being part of the shell; examples of these are
+_\be_\bv_\ba_\bl and _\be_\bx_\bp_\bo_\br_\bt. 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
+_\br_\be_\ba_\bd and _\bt_\be_\bs_\bt. 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 _\bv_\bi-style line editing commands have been standardized;
+_\be_\bm_\ba_\bc_\bs 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 _\bl_\bo_\bg_\bi_\bn 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 ._\bp_\br_\bo_\bf_\bi_\bl_\be.
+
+_\b3. _\bB_\ba_\bs_\bi_\bc _\bB_\ba_\bs_\bh _\bf_\be_\ba_\bt_\bu_\br_\be_\bs
+
+ 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 (_\bf_\bo_\br, _\bi_\bf, _\bw_\bh_\bi_\bl_\be,
+etc.). All of the Bourne shell builtins, including those
+not specified in the POSIX.2 standard, appear in Bash.
+Shell _\bf_\bu_\bn_\bc_\bt_\bi_\bo_\bn_\bs, 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 _\bP_\bS_\b1, _\bI_\bF_\bS, and _\bP_\bA_\bT_\bH. 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|\b-. 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 _\bR_\bA_\bN_\bD_\bO_\bM and _\bR_\bE_\bP_\bL_\bY, the _\bt_\by_\bp_\be_\bs_\be_\bt builtin, the ability
+to remove substrings from variables based on patterns, and
+shell arithmetic. _\bR_\bA_\bN_\bD_\bO_\bM expands to a random number each
+time it is referenced; assigning a value to _\bR_\bA_\bN_\bD_\bO_\bM seeds the
+_________________________
+|\b-Morris Bolsky and David Korn, _\bT_\bh_\be _\bK_\bo_\br_\bn_\bS_\bh_\be_\bl_\bl _\bC_\bo_\bm_\bm_\ba_\bn_\bd
+_\ba_\bn_\bd _\bP_\br_\bo_\bg_\br_\ba_\bm_\bm_\bi_\bn_\bg _\bL_\ba_\bn_\bg_\bu_\ba_\bg_\be, Prentice Hall, 1989.
+
+
+
+
+ October 28, 1994
+
+
+
+
+
+ - 4 -
+
+
+random number generator. _\bR_\bE_\bP_\bL_\bY is the default variable used
+by the _\br_\be_\ba_\bd builtin when no variable names are supplied as
+arguments. The _\bt_\by_\bp_\be_\bs_\be_\bt 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:
+\e9 $ echo $((3 + 5 * 32))
+ 163
+\e9
+For interactive use, Bash implements ksh-style aliases and
+builtins such as _\bf_\bc (discussed below) and _\bj_\bo_\bb_\bs. 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)|\b-, 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 _\bp_\bu_\bs_\bh_\bd, _\bp_\bo_\bp_\bd, and
+_\bd_\bi_\br_\bs 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 _\bc_\bo_\bm_\bm_\ba_\bn_\bd 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 _\bt_\be_\bs_\bt 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 _\bt_\be_\bs_\bt, and leaves the behavior undefined
+when more arguments are supplied. Bash uses the POSIX.2
+_________________________
+|\b-Bill Joy, An Introduction to the C Shell, _\bU_\bN_\bI_\bX _\bU_\bs_\be_\br'_\bs
+_\bS_\bu_\bp_\bp_\bl_\be_\bm_\be_\bn_\bt_\ba_\br_\by _\bD_\bo_\bc_\bu_\bm_\be_\bn_\bt_\bs, University of California at
+Berkeley, 1986.
+
+
+
+
+ October 28, 1994
+
+
+
+
+
+ - 5 -
+
+
+algorithm, which was conceived by David Korn.
+
+_\b3._\b1. _\bF_\be_\ba_\bt_\bu_\br_\be_\bs _\bn_\bo_\bt _\bi_\bn _\bt_\bh_\be _\bB_\bo_\bu_\br_\bn_\be _\bS_\bh_\be_\bl_\bl
+
+ 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 _\bc_\bo_\bm_\bm_\ba_\bn_\bd builtin, the ability of the _\br_\be_\ba_\bd builtin
+to correctly return a line ending with a backslash, symbolic
+arguments to the _\bu_\bm_\ba_\bs_\bk builtin, variable substring removal,
+a way to get the length of a variable, and the new algorithm
+for the _\bt_\be_\bs_\bt 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 $_\bI_\bF_\bS 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.
+
+_\b4. _\bB_\ba_\bs_\bh-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bF_\be_\ba_\bt_\bu_\br_\be_\bs
+
+ 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.
+
+_\b4._\b1. _\bS_\bt_\ba_\br_\bt_\bu_\bp _\bF_\bi_\bl_\be_\bs
+
+ 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
+~/._\bb_\ba_\bs_\bh__\bp_\br_\bo_\bf_\bi_\bl_\be (the file .bash_profile in the user's home
+directory), if it exists. An interactive non-login shell
+reads and executes ~/._\bb_\ba_\bs_\bh_\br_\bc. 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 $_\bE_\bN_\bV, if
+set, as the name of a startup file. The ksh practice of
+reading $_\bE_\bN_\bV 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 $_\bE_\bN_\bV only for interac-
+tive shells.
+
+_\b4._\b2. _\bN_\be_\bw _\bB_\bu_\bi_\bl_\bt_\bi_\bn _\bC_\bo_\bm_\bm_\ba_\bn_\bd_\bs
+
+ There are a few builtins which are new or have been
+extended in Bash. The _\be_\bn_\ba_\bb_\bl_\be builtin allows builtin com-
+mands to be turned on and off arbitrarily. To use the ver-
+sion of _\be_\bc_\bh_\bo found in a user's search path rather than the
+Bash builtin, enable -n echo suffices. The _\bh_\be_\bl_\bp builtin
+provides quick synopses of the shell facilities without
+requiring access to a manual page. _\bB_\bu_\bi_\bl_\bt_\bi_\bn is similar to
+_\bc_\bo_\bm_\bm_\ba_\bn_\bd in that it bypasses shell functions and directly
+executes builtin commands. Access to a csh-style stack of
+directories is provided via the _\bp_\bu_\bs_\bh_\bd, _\bp_\bo_\bp_\bd, and _\bd_\bi_\br_\bs buil-
+tins. _\bP_\bu_\bs_\bh_\bd and _\bp_\bo_\bp_\bd insert and remove directories from the
+stack, respectively, and _\bd_\bi_\br_\bs lists the stack contents. On
+systems that allow fine-grained control of resources, the
+_\bu_\bl_\bi_\bm_\bi_\bt builtin can be used to tune these settings. _\bU_\bl_\bi_\bm_\bi_\bt
+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 _\bs_\bu_\bs_\bp_\be_\bn_\bd command
+will stop the shell process when job control is active; most
+other shells do not allow themselves to be stopped like
+that. _\bT_\by_\bp_\be, the Bash answer to _\bw_\bh_\bi_\bc_\bh and _\bw_\bh_\be_\bn_\bc_\be, shows what
+will happen when a word is typed as a command:
+\e9 $ 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
+ }
+\e9
+
+
+ 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 _\bc_\bo_\bm_\bm_\ba_\bn_\bd utility.
+
+_\b4._\b3. _\bE_\bd_\bi_\bt_\bi_\bn_\bg _\ba_\bn_\bd _\bC_\bo_\bm_\bp_\bl_\be_\bt_\bi_\bo_\bn
+
+ One area in which Bash shines is command line editing.
+Bash uses the _\br_\be_\ba_\bd_\bl_\bi_\bn_\be 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
+_\bi_\bn_\bp_\bu_\bt_\br_\bc file, which defaults to the file ~/._\bi_\bn_\bp_\bu_\bt_\br_\bc, 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 _\bm_\be_\bt_\ba-_\bp_\br_\be_\bf_\bi_\bx 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
+$_\bP_\bA_\bT_\bH and double-quote the current or previous word:
+\e9 # Macros that are convenient for shell interaction
+
+
+\e9 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
+\e9
+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 _\bb_\bi_\bn_\bd builtin for more dyamic con-
+trol of readline than the startup file permits. _\bB_\bi_\bn_\bd is
+used in several ways. In _\bl_\bi_\bs_\bt 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 _\bb_\ba_\bt_\bc_\bh mode, it reads a series of key bindings
+directly from a file and passes them to readline. In its
+most common usage, _\bb_\bi_\bn_\bd 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 _\bb_\bi_\bn_\bd.
+
+ The readline library also provides an interface for
+_\bw_\bo_\br_\bd _\bc_\bo_\bm_\bp_\bl_\be_\bt_\bi_\bo_\bn. When the _\bc_\bo_\bm_\bp_\bl_\be_\bt_\bi_\bo_\bn 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.
+
+_\b4._\b4. _\bH_\bi_\bs_\bt_\bo_\br_\by
+
+ Access to the list of commands previously entered (the
+_\bc_\bo_\bm_\bm_\ba_\bn_\bd _\bh_\bi_\bs_\bt_\bo_\br_\by) is provided jointly by Bash and the
+
+
+\e9 October 28, 1994
+
+
+
+
+
+ - 9 -
+
+
+readline library. Bash provides variables ($HISTFILE,
+$HISTSIZE, and $HISTCONTROL) and the _\bh_\bi_\bs_\bt_\bo_\br_\by and _\bf_\bc builtins
+to manipulate the history list. The value of $_\bH_\bI_\bS_\bT_\bF_\bI_\bL_\bE
+specifes the file where Bash writes the command history on
+exit and reads it on startup. $_\bH_\bI_\bS_\bT_\bS_\bI_\bZ_\bE is used to limit
+the number of commands saved in the history. $_\bH_\bI_\bS_\bT_\bC_\bO_\bN_\bT_\bR_\bO_\bL
+provides a crude form of control over which commands are
+saved on the history list: a value of _\bi_\bg_\bn_\bo_\br_\be_\bs_\bp_\ba_\bc_\be means to
+not save commands which begin with a space; a value of
+_\bi_\bg_\bn_\bo_\br_\be_\bd_\bu_\bp_\bs 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 _\bh_\bi_\bs_\bt_\bo_\br_\by command can read or
+write files containing the history list and display the
+current list contents. The _\bf_\bc 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 _\bh_\bi_\bs_\bt_\bo_\br_\by 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):
+\e9 $ 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
+\e9
+The command history is only saved when the shell is interac-
+tive, so it is not available for use by shell scripts.
+
+_\b4._\b5. _\bN_\be_\bw _\bS_\bh_\be_\bl_\bl _\bV_\ba_\br_\bi_\ba_\bb_\bl_\be_\bs
+
+ There are a number of convenience variables that Bash
+interprets to make life easier. These include _\bF_\bI_\bG_\bN_\bO_\bR_\bE,
+which is a set of filename suffixes identifying files to
+exclude when completing filenames; _\bH_\bO_\bS_\bT_\bT_\bY_\bP_\bE, which is
+automatically set to a string describing the type of
+hardware on which Bash is currently executing;
+_\bc_\bo_\bm_\bm_\ba_\bn_\bd__\bo_\br_\bi_\be_\bn_\bt_\be_\bd__\bh_\bi_\bs_\bt_\bo_\br_\by, which directs Bash to save all
+lines of a multiple-line command such as a _\bw_\bh_\bi_\bl_\be or _\bf_\bo_\br loop
+in a single history entry, allowing easy re-editing; and
+_\bI_\bG_\bN_\bO_\bR_\bE_\bE_\bO_\bF, 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 _\ba_\bu_\bt_\bo__\br_\be_\bs_\bu_\bm_\be 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.
+
+_\b4._\b6. _\bB_\br_\ba_\bc_\be _\bE_\bx_\bp_\ba_\bn_\bs_\bi_\bo_\bn
+
+ 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 _\bb_\br_\ba_\bc_\be _\be_\bx_\bp_\ba_\bn_\bs_\bi_\bo_\bn, 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 _\bp_\br_\be_\ba_\bm_\bb_\bl_\be, followed
+by a pair of braces enclosing a series of comma-separated
+strings, and an optional _\bp_\bo_\bs_\bt_\ba_\bm_\bb_\bl_\be. The preamble is
+prepended to each string within the braces, and the postam-
+ble is then appended to each resulting string:
+\e9 $ echo a{d,c,b}e
+ ade ace abe
+\e9
+As this example demonstrates, the results of brace expansion
+are not sorted, as they are by filename expansion.
+
+_\b4._\b7. _\bP_\br_\bo_\bc_\be_\bs_\bs _\bS_\bu_\bb_\bs_\bt_\bi_\bt_\bu_\bt_\bi_\bo_\bn
+
+ On systems that can support it, Bash provides a facil-
+ity known as _\bp_\br_\bo_\bc_\be_\bs_\bs _\bs_\bu_\bb_\bs_\bt_\bi_\bt_\bu_\bt_\bi_\bo_\bn. 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 /_\bd_\be_\bv/_\bf_\bd 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:
+\e9 $ cmp <(old_prog) <(new_prog)
+\e9
+_\b4._\b8. _\bP_\br_\bo_\bm_\bp_\bt _\bC_\bu_\bs_\bt_\bo_\bm_\bi_\bz_\ba_\bt_\bi_\bo_\bn
+
+ One of the more popular interactive features that Bash
+provides is the ability to customize the prompt. Both $_\bP_\bS_\b1
+and $_\bP_\bS_\b2, 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., $_\bS_\bH_\bL_\bV_\bL, 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 _\bs_\bu. Before printing each pri-
+mary prompt, Bash expands the variable $_\bP_\bR_\bO_\bM_\bP_\bT__\bC_\bO_\bM_\bM_\bA_\bN_\bD 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:
+\e9 $ PS1='\u@\h [\t] \W($SHLVL:\!)\$ '
+ chet@odin [21:03:44] documentation(2:636)$ cd ..
+ chet@odin [21:03:54] src(2:637)$
+\e9
+The string being assigned is surrounded by single quotes so
+that if it is exported, the value of $_\bS_\bH_\bL_\bV_\bL will be updated
+by a child shell:
+\e9 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)$
+\e9
+The \$ escape is displayed as "$" when running as a normal
+user, but as "#" when running as root.
+
+_\b4._\b9. _\bF_\bi_\bl_\be _\bS_\by_\bs_\bt_\be_\bm _\bV_\bi_\be_\bw_\bs
+
+ 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
+_\bc_\bd, and the resultant non-intuitive behavior of "cd ..".
+The UNIX kernel treats symbolic links _\bp_\bh_\by_\bs_\bi_\bc_\ba_\bl_\bl_\by. 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 _\bl_\bo_\bg_\bi_\bc_\ba_\bl view of the file system. In
+this default mode, command and filename completion and buil-
+tin commands such as _\bc_\bd and _\bp_\bu_\bs_\bh_\bd which change the current
+working directory transparently follow symbolic links as if
+they were directories. The $_\bP_\bW_\bD 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:
+\e9 $ 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
+\e9
+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 _\bp_\bh_\by_\bs_\bi_\bc_\ba_\bl view of the file system is available:
+\e9 $ cd /usr/local/bin
+ $ pwd
+ /usr/local/bin
+ $ set -o physical
+ $ pwd
+ /net/share/sun4/local/bin
+\e9
+_\b4._\b1_\b0. _\bI_\bn_\bt_\be_\br_\bn_\ba_\bt_\bi_\bo_\bn_\ba_\bl_\bi_\bz_\ba_\bt_\bi_\bo_\bn
+
+ 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.
+
+_\b4._\b1_\b1. _\bP_\bO_\bS_\bI_\bX _\bM_\bo_\bd_\be
+
+ 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 _\bP_\bO_\bS_\bI_\bX _\bm_\bo_\bd_\be.
+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 -_\bp_\bo_\bs_\bi_\bx
+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 $_\bP_\bO_\bS_\bI_\bX_\bL_\bY__\bC_\bO_\bR_\bR_\bE_\bC_\bT is set
+when Bash is started or assigned a value during execution.
+$_\bP_\bO_\bS_\bI_\bX__\bP_\bE_\bD_\bA_\bN_\bT_\bI_\bC 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
+$_\bE_\bN_\bV rather than the "normal" startup files, and does not
+allow reserved words to be aliased.
+
+_\b5. _\bN_\be_\bw _\bF_\be_\ba_\bt_\bu_\br_\be_\bs _\ba_\bn_\bd _\bF_\bu_\bt_\bu_\br_\be _\bP_\bl_\ba_\bn_\bs
+
+ 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.
+
+_\b5._\b1. _\bN_\be_\bw _\bF_\be_\ba_\bt_\bu_\br_\be_\bs _\bi_\bn _\bB_\ba_\bs_\bh-_\b1._\b1_\b4
+
+ 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 _\bs_\be_\bt
+-_\bo _\bp_\bo_\bs_\bi_\bx and $_\bP_\bO_\bS_\bI_\bX__\bP_\bE_\bD_\bA_\bN_\bT_\bI_\bC, are new in version 1.14.
+There is a new shell variable, _\bO_\bS_\bT_\bY_\bP_\bE, 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: $_\bH_\bI_\bS_\bT_\bC_\bO_\bN_\b-
+_\bT_\bR_\bO_\bL replaces $_\bh_\bi_\bs_\bt_\bo_\br_\by__\bc_\bo_\bn_\bt_\br_\bo_\bl, and $_\bH_\bO_\bS_\bT_\bF_\bI_\bL_\bE replaces
+$_\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be__\bc_\bo_\bm_\bp_\bl_\be_\bt_\bi_\bo_\bn__\bf_\bi_\bl_\be. In both cases, the old names are
+accepted for backwards compatibility. The ksh _\bs_\be_\bl_\be_\bc_\bt con-
+struct, which allows the generation of simple menus, has
+been implemented. New capabilities have been added to
+existing variables: $_\ba_\bu_\bt_\bo__\br_\be_\bs_\bu_\bm_\be can now take values of
+_\be_\bx_\ba_\bc_\bt or _\bs_\bu_\bb_\bs_\bt_\br_\bi_\bn_\bg, and $_\bH_\bI_\bS_\bT_\bC_\bO_\bN_\bT_\bR_\bO_\bL understands the value
+_\bi_\bg_\bn_\bo_\br_\be_\bb_\bo_\bt_\bh, which combines the two previously acceptable
+values. The _\bd_\bi_\br_\bs builtin has acquired options to print out
+specific members of the directory stack. The $_\bn_\bo_\bl_\bi_\bn_\bk_\bs vari-
+able, which forces a physical view of the file system, has
+been superseded by the -_\bP option to the _\bs_\be_\bt builtin
+(equivalent to set -o physical); the variable is retained
+for backwards compatibility. The version string contained
+in $_\bB_\bA_\bS_\bH__\bV_\bE_\bR_\bS_\bI_\bO_\bN now includes an indication of the patch
+level as well as the "build version". Some little-used
+features have been removed: the _\bb_\by_\be synonym for _\be_\bx_\bi_\bt and
+the $_\bN_\bO__\bP_\bR_\bO_\bM_\bP_\bT__\bV_\bA_\bR_\bS 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 _\bi_\bn_\bf_\bo
+file has been updated to reflect the current version. As
+always, as many bugs as possible have been fixed, although
+some surely remain.
+
+_\b5._\b2. _\bO_\bt_\bh_\be_\br _\bF_\be_\ba_\bt_\bu_\br_\be_\bs
+
+ 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 _\bv_\ba_\br_\bn_\ba_\bm_\be=( ... ) to assign a list of words
+directly to an array and a mechanism to allow the _\br_\be_\ba_\bd buil-
+tin to read a list of values directly into an array, would
+be desirable. Given those extensions, the ksh _\bs_\be_\bt -_\bA syntax
+may not be worth supporting (the -_\bA option assigns a list of
+values to an array, but is a rather peculiar special case).
+
+ Some shells include a means of _\bp_\br_\bo_\bg_\br_\ba_\bm_\bm_\ba_\bb_\bl_\be 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 _\bH_\bI_\bS_\bT_\bI_\bG_\b-
+_\bN_\bO_\bR_\bE, which would contain a colon-separated list of com-
+mands. Lines beginning with these commands, after the res-
+trictions of $_\bH_\bI_\bS_\bT_\bC_\bO_\bN_\bT_\bR_\bO_\bL 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 $_\bH_\bI_\bS_\bT_\bI_\bG_\bN_\bO_\bR_\bE.
+
+ One thing that newer shells such as _\bw_\bk_\bs_\bh (also known as
+_\bd_\bt_\bk_\bs_\bh) 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 (_\bx_\bx_\bx__\bb_\bu_\bi_\bl_\bt_\bi_\bn() 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 _\bh_\be_\bl_\bp 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 _\bg_\be_\bt_\bc_\bo_\bn_\bf command, which prints the values of sys-
+tem configuration variables defined by POSIX.2, and a _\bd_\bi_\bs_\bo_\bw_\bn
+builtin, which causes a shell running with job control
+active to "forget about" one or more background jobs in its
+internal jobs table. Using _\bg_\be_\bt_\bc_\bo_\bn_\bf, for example, a user
+could retrieve a value for $_\bP_\bA_\bT_\bH 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.
+
+_\b6. _\bR_\be_\bf_\bl_\be_\bc_\bt_\bi_\bo_\bn_\bs _\ba_\bn_\bd _\bL_\be_\bs_\bs_\bo_\bn_\bs _\bL_\be_\ba_\br_\bn_\be_\bd
+
+ 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|\b- 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.|\b=
+
+The POSIX.2 standard includes a _\by_\ba_\bc_\bc 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
+_\by_\ba_\bc_\bc-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 $_\ba_\bl_\bl_\bo_\bw__\bn_\bu_\bl_\bl__\bg_\bl_\bo_\bb__\be_\bx_\bp_\ba_\bn_\bs_\bi_\bo_\bn and
+$_\bg_\bl_\bo_\bb__\bd_\bo_\bt__\bf_\bi_\bl_\be_\bn_\ba_\bm_\be_\bs 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 _\bh_\be_\bl_\bp builtin were external to the
+shell rather than compiled into it. The behavior enabled by
+$_\bc_\bo_\bm_\bm_\ba_\bn_\bd__\bo_\br_\bi_\be_\bn_\bt_\be_\bd__\bh_\bi_\bs_\bt_\bo_\br_\by, 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.
+
+
+_________________________
+|\b-S. R. Bourne, "UNIX Time-Sharing System: The UNIX
+Shell", _\bB_\be_\bl_\bl _\bS_\by_\bs_\bt_\be_\bm _\bT_\be_\bc_\bh_\bn_\bi_\bc_\ba_\bl _\bJ_\bo_\bu_\br_\bn_\ba_\bl, 57(6), July-
+August, 1978, pp. 1971-1990.
+|\b=Tom Duff, "Rc - A Shell for Plan 9 and UNIX systems",
+_\bP_\br_\bo_\bc. _\bo_\bf _\bt_\bh_\be _\bS_\bu_\bm_\bm_\be_\br _\b1_\b9_\b9_\b0 _\bE_\bU_\bU_\bG _\bC_\bo_\bn_\bf_\be_\br_\be_\bn_\bc_\be, London, July,
+1990, pp. 21-33.
+
+
+
+
+ October 28, 1994
+
+
+
+
+
+ - 17 -
+
+
+_\b7. _\bA_\bv_\ba_\bi_\bl_\ba_\bb_\bi_\bl_\bi_\bt_\by
+
+ As with all other GNU software, Bash is available for
+anonymous FTP from _\bp_\br_\be_\bp._\ba_\bi._\bm_\bi_\bt._\be_\bd_\bu:/_\bp_\bu_\bb/_\bg_\bn_\bu and from other
+GNU software mirror sites. The current version is in _\bb_\ba_\bs_\bh-
+_\b1._\b1_\b4._\b1._\bt_\ba_\br._\bg_\bz in that directory. Use _\ba_\br_\bc_\bh_\bi_\be to find the
+nearest archive site. The latest version is always avail-
+able for FTP from _\bb_\ba_\bs_\bh._\bC_\bW_\bR_\bU._\bE_\bd_\bu:/_\bp_\bu_\bb/_\bd_\bi_\bs_\bt. Bash documenta-
+tion is available for FTP from _\bb_\ba_\bs_\bh._\bC_\bW_\bR_\bU._\bE_\bd_\bu:/_\bp_\bu_\bb/_\bb_\ba_\bs_\bh.
+
+ 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 _\bp_\bu_\bs_\bh_\bd/_\bp_\bo_\bp_\bd/_\bd_\bi_\br_\bs, process
+substitution, prompt string special character decoding, and
+the _\bs_\be_\bl_\be_\bc_\bt 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.
+
+_\b8. _\bC_\bo_\bn_\bc_\bl_\bu_\bs_\bi_\bo_\bn
+
+ 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
+
+
projects / thirdparty / bash.git / blobdiff