| .de SE \" start example |
| .sp .5 |
| .RS |
| .ft CR |
| .nf |
| .. |
| .de EE \" end example |
| .fi |
| .sp .5 |
| .RE |
| .ft R |
| .. |
| .TL |
| Bash \- The GNU shell* |
| .AU |
| Chet Ramey |
| Case Western Reserve University |
| chet@po.cwru.edu |
| .FS |
| *An earlier version of this article appeared in The Linux Journal. |
| .FE |
| .NH 1 |
| Introduction |
| .PP |
| .B Bash |
| is the shell, or command language interpreter, |
| that will appear in the GNU operating system. |
| The name is an acronym for |
| the \*QBourne-Again SHell\*U, a pun on Steve Bourne, the author |
| of the direct ancestor of the current |
| .UX |
| shell \fI/bin/sh\fP, |
| which appeared in the Seventh Edition Bell Labs Research version |
| of \s-1UNIX\s+1. |
| .PP |
| Bash is an \fBsh\fP\-compatible shell that incorporates useful |
| features from the Korn shell (\fBksh\fP) and the C shell (\fBcsh\fP), |
| described later in this article. It is ultimately intended to be a |
| conformant implementation of the IEEE POSIX Shell and Utilities |
| specification (IEEE Working Group 1003.2). It offers functional |
| improvements over sh for both interactive and programming use. |
| .PP |
| While the GNU operating system will most likely include a version |
| of the Berkeley shell csh, Bash will be the default shell. |
| Like other GNU software, Bash is quite portable. It currently runs |
| on nearly every version of |
| .UX |
| and a few other operating systems \- an independently-supported |
| port exists for OS/2, and there are rumors of ports to DOS and |
| Windows NT. Ports to \s-1UNIX\s+1-like systems such as QNX and Minix |
| are part of the distribution. |
| .PP |
| The original author of Bash |
| was Brian Fox, an employee of the Free Software Foundation. The |
| current developer and maintainer is Chet Ramey, a volunteer who |
| works at Case Western Reserve University. |
| .NH 1 |
| What's POSIX, anyway? |
| .PP |
| .I POSIX |
| is a name originally coined by Richard Stallman for a family of open |
| system standards based on \s-1UNIX\s+1. There are a number of aspects of \s-1UNIX\s+1 |
| under consideration for standardization, from the basic system services |
| at the system call and C library level to applications and tools to system |
| administration and management. Each area of standardization is |
| assigned to a working group in the 1003 series. |
| .PP |
| The POSIX Shell and Utilities standard has been developed by IEEE Working |
| Group 1003.2 (POSIX.2).\(dd |
| .FS |
| \(ddIEEE, \fIIEEE Standard for Information Technology -- Portable |
| Operating System Interface (POSIX) Part 2: Shell and Utilities\fP, |
| 1992. |
| .FE |
| It concentrates on the command interpreter |
| interface and utility programs |
| commonly executed from the command line or by other programs. |
| An initial version of the standard has been |
| approved and published by the IEEE, and work is currently underway to |
| update it. |
| There are four primary areas of work in the 1003.2 standard: |
| .IP \(bu |
| Aspects of the shell's syntax and command language. |
| A number of special builtins such as |
| .B cd |
| and |
| .B exec |
| are being specified as part of the shell, since their |
| functionality usually cannot be implemented by a separate executable; |
| .IP \(bu |
| A set of utilities to be called by shell scripts and applications. |
| Examples are programs like |
| .I sed, |
| .I tr, |
| and |
| .I awk. |
| Utilities commonly implemented as shell builtins |
| are described in this section, such as |
| .B test |
| and |
| .B kill . |
| An expansion of this section's scope, termed the User Portability |
| Extension, or UPE, has standardized interactive programs such as |
| .I vi |
| and |
| .I mailx; |
| .IP \(bu |
| A group of functional interfaces to services provided by the |
| shell, such as the traditional \f(CRsystem()\fP |
| C library function. There are functions to perform shell word |
| expansions, perform filename expansion (\fIglobbing\fP), obtain values |
| of POSIX.2 system configuration variables, retrieve values of |
| environment variables (\f(CRgetenv()\fP\^), and other services; |
| .IP \(bu |
| A suite of \*Qdevelopment\*U utilities such as |
| .I c89 |
| (the POSIX.2 version of \fIcc\fP), |
| and |
| .I yacc. |
| .PP |
| Bash is concerned with the aspects of the shell's behavior |
| defined by POSIX.2. The shell command language has of |
| course been standardized, including the basic flow control |
| and program execution constructs, I/O redirection and |
| pipelining, argument handling, variable expansion, and quoting. |
| The |
| .I special |
| builtins, which must be implemented as part of the shell to |
| provide the desired functionality, are specified as being |
| part of the shell; examples of these are |
| .B eval |
| and |
| .B export . |
| Other utilities appear in the sections of POSIX.2 not |
| devoted to the shell which are commonly (and in some |
| cases must be) implemented as builtin commands, such as |
| .B read |
| and |
| .B test . |
| POSIX.2 also specifies aspects of the shell's |
| interactive behavior as part of |
| the UPE, including job control and command line editing. |
| Interestingly enough, only \fIvi\fP-style line editing commands |
| have been standardized; \fIemacs\fP editing commands were left |
| out due to objections. |
| .PP |
| While POSIX.2 includes much of what the shell has traditionally |
| provided, some important things have been omitted as being |
| \*Qbeyond its scope.\*U There is, for instance, no mention of |
| a difference between a |
| .I login |
| shell and any other interactive shell (since POSIX.2 does not |
| specify a login program). No fixed startup files are defined, |
| either \- the standard does not mention |
| .I .profile . |
| .NH 1 |
| Basic Bash features |
| .PP |
| Since the Bourne shell |
| provides Bash with most of its philosophical underpinnings, |
| Bash inherits most of its features and functionality from sh. |
| Bash implements all of the traditional sh flow |
| control constructs (\fIfor\fP, \fIif\fP, \fIwhile\fP, etc.). |
| All of the Bourne shell builtins, including those not specified in |
| the POSIX.2 standard, appear in Bash. Shell \fIfunctions\fP, |
| introduced in the SVR2 version of the Bourne shell, |
| are similar to shell scripts, but are defined using a special |
| syntax and are executed in the same process as the calling shell. |
| Bash has shell functions |
| which behave in a fashion upward-compatible with sh functions. |
| There are certain shell |
| variables that Bash interprets in the same way as sh, such as |
| .B PS1 , |
| .B IFS , |
| and |
| .B PATH . |
| Bash implements essentially the same grammar, parameter and |
| variable expansion semantics, redirection, and quoting as the |
| Bourne shell. Where differences appear between the POSIX.2 |
| standard and traditional sh behavior, Bash follows POSIX. |
| .PP |
| The Korn Shell (\fBksh\fP) is a descendant of the Bourne shell written |
| at AT&T Bell Laboratories by David Korn\(dg. It provides a number of |
| useful features that POSIX and Bash have adopted. Many of the |
| interactive facilities in POSIX.2 have their roots in the ksh: |
| for example, the POSIX and ksh job control facilities are nearly |
| identical. Bash includes features from the Korn Shell for both |
| interactive use and shell programming. For programming, Bash provides |
| variables such as |
| .B RANDOM |
| and |
| .B REPLY , |
| the |
| .B typeset |
| builtin, |
| the ability to remove substrings from variables based on patterns, |
| and shell arithmetic. |
| .FS |
| \(dgMorris Bolsky and David Korn, \fIThe KornShell Command and |
| Programming Language\fP, Prentice Hall, 1989. |
| .FE |
| .B RANDOM |
| expands to a random number each time it is referenced; assigning a |
| value to |
| .B RANDOM |
| seeds the random number generator. |
| .B REPLY |
| is the default variable used by the |
| .B read |
| builtin when no variable names are supplied as arguments. |
| The |
| .B typeset |
| builtin is used to define variables and give them attributes |
| such as \fBreadonly\fP. |
| Bash arithmetic allows the evaluation of an expression and the |
| substitution of the result. Shell variables may be used as operands, |
| and the result of an expression may be assigned to a variable. |
| Nearly all of the operators from the C language are available, |
| with the same precedence rules: |
| .SE |
| $ echo $((3 + 5 * 32)) |
| 163 |
| .EE |
| .LP |
| For interactive use, Bash implements ksh-style aliases and builtins |
| such as |
| .B fc |
| (discussed below) and |
| .B jobs . |
| Bash aliases allow a string to be substituted for a command name. |
| They can be used to create a mnemonic for a \s-1UNIX\s+1 command |
| name (\f(CRalias del=rm\fP), to expand a single word to a complex command |
| (\f(CRalias news='xterm -g 80x45 -title trn -e trn -e -S1 -N &'\fP), or to |
| ensure that a command is invoked with a basic set of options |
| (\f(CRalias ls="/bin/ls -F"\fP). |
| .PP |
| The C shell (\fBcsh\fP)\(dg, originally written by Bill Joy while at |
| Berkeley, is widely used and quite popular for its interactive |
| facilities. Bash includes a csh-compatible history expansion |
| mechanism (\*Q! history\*U), brace expansion, access to a stack |
| of directories via the |
| .B pushd , |
| .B popd , |
| and |
| .B dirs |
| builtins, and tilde expansion, to generate users' home directories. |
| Tilde expansion has also been adopted by both the Korn Shell and |
| POSIX.2. |
| .FS |
| \(dgBill Joy, An Introduction to the C Shell, \fIUNIX User's Supplementary |
| Documents\fP, University of California at Berkeley, 1986. |
| .FE |
| .PP |
| There were certain areas in which POSIX.2 felt standardization |
| was necessary, but no existing implementation provided the proper |
| behavior. The working group invented and standardized functionality |
| in these areas, which Bash implements. The |
| .B command |
| builtin was invented so that shell functions could be written to |
| replace builtins; it makes the capabilities of the builtin |
| available to the function. The reserved word \*Q!\*U was added |
| to negate the return value of a command or pipeline; it was nearly |
| impossible to express \*Qif not x\*U cleanly using the sh language. |
| There exist multiple incompatible implementations of the |
| .B test |
| builtin, which tests files for type and other attributes and performs |
| arithmetic and string comparisons. |
| POSIX considered none of these correct, so the standard |
| behavior was specified in terms of the number of arguments to the |
| command. POSIX.2 dictates exactly what will happen when four or |
| fewer arguments are given to |
| .B test , |
| and leaves the behavior undefined when more arguments are supplied. |
| Bash uses the POSIX.2 algorithm, which was conceived by David Korn. |
| .NH 2 |
| Features not in the Bourne Shell |
| .PP |
| There are a number of minor differences between Bash and the |
| version of sh present on most other versions of \s-1UNIX\s+1. The majority |
| of these are due to the POSIX standard, but some are the result of |
| Bash adopting features from other shells. For instance, Bash |
| includes the new \*Q!\*U reserved word, the |
| .B command |
| builtin, the ability of the |
| .B read |
| builtin to correctly return a line ending with a backslash, symbolic |
| arguments to the |
| .B umask |
| builtin, variable substring removal, a way to get the length of a variable, |
| and the new algorithm for the |
| .B test |
| builtin from the POSIX.2 standard, none of which appear in sh. |
| .PP |
| Bash also implements the \*Q$(...)\*U command substitution syntax, |
| which supersedes the sh `...` construct. |
| The \*Q$(...)\*U construct expands to the output of the command |
| contained within the |
| parentheses, with trailing newlines removed. The sh syntax is |
| accepted for backwards compatibility, but the \*Q$(...)\*U form |
| is preferred because its quoting rules are much simpler and it |
| is easier to nest. |
| .PP |
| The Bourne shell does not provide such features as brace expansion, |
| the ability |
| to define a variable and a function with the same name, local variables |
| in shell functions, the ability to enable and disable individual |
| builtins or write a function to replace a builtin, or a means to |
| export a shell function to a child process. |
| .PP |
| Bash has closed |
| a long-standing shell security hole by not using the |
| .B $IFS |
| variable to split each word read by the shell, but splitting only |
| the results of expansion (ksh and the 4.4 BSD sh have fixed this |
| as well). Useful behavior such as a means to abort |
| execution of a script read with the \*Q.\*U command using the |
| \fBreturn\fP builtin or automatically |
| exporting variables in the shell's environment to children is also |
| not present in the Bourne shell. Bash provides a much more powerful |
| environment for both interactive use and programming. |
| .NH 1 |
| Bash-specific Features |
| .PP |
| This section details a few of the features which make Bash unique. |
| Most of them provide improved interactive use, but a few programming |
| improvements are present as well. Full descriptions of these |
| features can be found in the Bash documentation. |
| .NH 2 |
| Startup Files |
| .PP |
| Bash executes startup files differently than other shells. The Bash |
| behavior is a compromise between the csh principle of startup files |
| with fixed names executed for each shell and the sh |
| \*Qminimalist\*U behavior. An interactive instance of Bash started |
| as a login shell reads and executes |
| .I ~/.bash_profile |
| (the file .bash_profile in the user's home directory), if it exists. |
| An interactive non-login shell reads and executes |
| .I ~/.bashrc . |
| A non-interactive shell (one begun to execute a shell script, for |
| example) reads no fixed startup file, but uses the value of the variable |
| .B $ENV , |
| if set, as the name of a startup file. The ksh practice of reading |
| .B $ENV |
| for every shell, with the accompanying difficulty of defining the |
| proper variables and functions for interactive and non-interactive |
| shells or having the file read only for interactive shells, was |
| considered too complex. Ease of use won out here. Interestingly, |
| the next release of ksh will change to reading |
| .B $ENV |
| only for interactive shells. |
| .NH 2 |
| New Builtin Commands |
| .PP |
| There are a few builtins which are new or have been extended in Bash. |
| The |
| .B enable |
| builtin allows builtin commands to be turned on and off arbitrarily. |
| To use the version of |
| .I echo |
| found in a user's search path rather than the Bash builtin, |
| \f(CRenable -n echo\fP suffices. The |
| .B help |
| builtin provides |
| quick synopses of the shell facilities without requiring |
| access to a manual page. |
| .B Builtin |
| is similar to |
| .B command |
| in that it bypasses shell functions and directly executes builtin |
| commands. Access to a csh-style stack of directories is provided |
| via the |
| .B pushd , |
| .B popd , |
| and |
| .B dirs |
| builtins. |
| .B Pushd |
| and |
| .B popd |
| insert and remove directories from the stack, respectively, and |
| .B dirs |
| lists the stack contents. On systems that allow fine-grained control |
| of resources, the |
| .B ulimit |
| builtin can be used to tune these settings. |
| .B Ulimit |
| 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 |
| .B suspend |
| command will stop the shell process when job control is active; most |
| other shells do not allow themselves to be stopped like that. |
| .B Type, |
| the Bash answer to |
| .B which |
| and |
| .B whence, |
| shows what will happen when a word is typed as a command: |
| .SE |
| $ 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 |
| } |
| .EE |
| .LP |
| 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 |
| .B command |
| utility. |
| .NH 2 |
| Editing and Completion |
| .PP |
| One area in which Bash shines is command line editing. Bash uses the |
| .I readline |
| 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. |
| .PP |
| 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 inputrc |
| file, which defaults to the file |
| .I ~/.inputrc , |
| 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 bindings |
| that perform history expansion or shell word expansions on the current |
| input line. |
| .PP |
| 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 converted to meta-prefixed key sequences (a |
| meta-prefixed key sequence consists of the character with the |
| eighth bit zeroed, preceded by the |
| .I meta-prefix |
| 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 readline wants to |
| ring the terminal's bell. All of these variables can be set in |
| the inputrc file. |
| .PP |
| 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 readline, |
| 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 |
| .B $PATH |
| and double-quote the current or previous word: |
| .SE |
| # Macros that are convenient for shell interaction |
| $if Bash |
| # edit the path |
| "\eC-xp": "PATH=${PATH}\ee\eC-e\eC-a\eef\eC-f" |
| # prepare to type a quoted word -- insert open and close double |
| # quotes and move to just after the open quote |
| "\eC-x\e"": "\e"\e"\eC-b" |
| # Quote the current or previous word |
| "\eC-xq": "\eeb\e"\eef\e"" |
| $endif |
| .EE |
| .LP |
| 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. |
| .PP |
| Bash implements the |
| .B bind |
| builtin for more dynamic control of readline than the startup file |
| permits. |
| .B Bind |
| is used in several ways. In |
| .I list |
| mode, it can display the current key bindings, list all the |
| readline editing directives 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 |
| .I batch |
| mode, it reads a series of key bindings directly from a file and |
| passes them to readline. In its most common usage, |
| .B bind |
| 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 bind . |
| .PP |
| The readline library also provides an interface for \fIword completion\fP. |
| When the |
| .I completion |
| 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 possible 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 character 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 completely 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 generally quite |
| good at determining what type of completion to attempt. |
| .NH 2 |
| History |
| .PP |
| Access to the list of commands previously entered (the \fIcommand history\fP) |
| is provided jointly by Bash and the readline library. Bash provides |
| variables (\fB$HISTFILE\fP, \fB$HISTSIZE\fP, and \fB$HISTCONTROL\fP) |
| and the |
| .B history |
| and |
| .B fc |
| builtins to manipulate the history list. |
| The value of |
| .B $HISTFILE |
| specifies the file where Bash writes the command history on exit and |
| reads it on startup. |
| .B $HISTSIZE |
| is used to limit the number of commands saved in the history. |
| .B $HISTCONTROL |
| provides a crude form of control over which commands are saved on |
| the history list: a value of |
| .I ignorespace |
| means to not save commands which begin with a space; a value of |
| .I ignoredups |
| means to not save commands identical to the last command saved. |
| \fB$HISTCONTROL\fP was named \fB$history_control\fP in earlier |
| versions of Bash; the old name is still accepted for backwards |
| compatibility. The |
| .B history |
| command can read or write files containing the history list |
| and display the current list contents. The |
| .B fc |
| 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 history list for |
| a portion of the current input line or a string typed by the user. |
| Finally, the |
| .I history |
| 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 |
| (\*Qbang history\*U, so called because the exclamation point |
| introduces a history substitution): |
| .SE |
| $ 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 |
| .EE |
| .LP |
| The command history is only |
| saved when the shell is interactive, so it is not available for use |
| by shell scripts. |
| .NH 2 |
| New Shell Variables |
| .PP |
| There are a number of convenience variables that Bash interprets |
| to make life easier. These include |
| .B FIGNORE , |
| which is a set of filename suffixes identifying files to exclude when |
| completing filenames; |
| .B HOSTTYPE , |
| which is automatically set to a string describing the type of |
| hardware on which Bash is currently executing; |
| .B command_oriented_history , |
| which directs Bash to save all lines of a multiple-line |
| command such as a \fIwhile\fP or \fIfor\fP loop in a single |
| history entry, allowing easy re-editing; and |
| .B IGNOREEOF , |
| whose value indicates the number of consecutive EOF characters that |
| an interactive shell will read before exiting \- an easy way to keep |
| yourself from being logged out accidentally. The |
| .B auto_resume |
| 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. |
| .NH 2 |
| Brace Expansion |
| .PP |
| 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 implements \fIbrace expansion\fP, 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 |
| .I preamble , |
| followed by a pair of braces enclosing a series of comma-separated |
| strings, and an optional |
| .I postamble . |
| The preamble is prepended to each string within the braces, and the |
| postamble is then appended to each resulting string: |
| .SE |
| $ echo a{d,c,b}e |
| ade ace abe |
| .EE |
| .LP |
| As this example demonstrates, the results of brace expansion are not |
| sorted, as they are by filename expansion. |
| .NH 2 |
| Process Substitution |
| .PP |
| On systems that can support it, Bash provides a facility known as |
| \fIprocess substitution\fP. Process substitution is similar to command |
| substitution in that its specification includes a command to execute, |
| but the shell does not collect 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 |
| .I /dev/fd |
| 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: |
| .SE |
| $ cmp <(old_prog) <(new_prog) |
| .EE |
| .NH 2 |
| Prompt Customization |
| .PP |
| One of the more popular interactive features that Bash provides is |
| the ability to customize the prompt. Both |
| .B $PS1 |
| and |
| .B $PS2, |
| 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., |
| .B $SHLVL , |
| which indicates how deeply the current shell is nested). |
| Bash specially interprets characters in the prompt string |
| preceded by a backslash. Some of these backslash escapes are |
| replaced with |
| the current time, the date, the current working directory, |
| the username, and the command number or history 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 \fIsu\fP. |
| Before printing each primary prompt, Bash expands the variable |
| .B $PROMPT_COMMAND |
| 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: |
| .SE |
| $ PS1='\eu@\eh [\et] \eW($SHLVL:\e!)\e$ ' |
| chet@odin [21:03:44] documentation(2:636)$ cd .. |
| chet@odin [21:03:54] src(2:637)$ |
| .EE |
| .LP |
| The string being assigned is surrounded by single quotes so that if |
| it is exported, the value of |
| .B $SHLVL |
| will be updated by a child shell: |
| .SE |
| 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)$ |
| .EE |
| .LP |
| The \fP\e$\fP escape is displayed |
| as \*Q\fB$\fP\*U when running as a normal user, but as \*Q\fB#\fP\*U when |
| running as root. |
| .NH 2 |
| File System Views |
| .PP |
| Since Berkeley introduced symbolic links in 4.2 BSD, one of their most |
| annoying properties has been the \*Qwarping\*U to a completely |
| different area of the file system when using |
| .B cd , |
| and the resultant non-intuitive behavior of \*Q\fBcd ..\fP\*U. |
| The \s-1UNIX\s+1 kernel treats symbolic links |
| .I physically . |
| 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 component. In either case, the symbolic link |
| is visible. If the link value is an absolute pathname, |
| the user finds himself in a completely different part of the file |
| system. |
| .PP |
| Bash provides a |
| .I logical |
| view of the file system. In this default mode, command and filename |
| completion and builtin commands such as |
| .B cd |
| and |
| .B pushd |
| which change the current working directory transparently follow |
| symbolic links as if they were directories. |
| The |
| .B $PWD |
| variable, which holds the shell's idea of the current working directory, |
| depends on the path used to reach the directory rather than its |
| physical location in the local file system hierarchy. For example: |
| .SE |
| $ 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 |
| .EE |
| .LP |
| One problem with this, of |
| course, arises when programs that do not understand the shell's logical |
| notion of the file system interpret \*Q..\*U differently. This generally |
| happens when Bash completes filenames containing \*Q..\*U according to a |
| logical hierarchy which does not correspond to their physical location. |
| For users who find this troublesome, a corresponding |
| .I physical |
| view of the file system is available: |
| .SE |
| $ cd /usr/local/bin |
| $ pwd |
| /usr/local/bin |
| $ set -o physical |
| $ pwd |
| /net/share/sun4/local/bin |
| .EE |
| .NH 2 |
| Internationalization |
| .PP |
| One of the most significant improvements in version 1.13 of Bash was the |
| change to \*Qeight-bit cleanliness\*U. Previous versions used the |
| eighth bit of characters to mark whether or not they were |
| quoted when performing word expansions. 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 manipulate files with \*Qodd\*U 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 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 family of character sets, used by many European countries. |
| .NH 2 |
| POSIX Mode |
| .PP |
| Although Bash is intended to be POSIX.2 conformant, there are areas in |
| which the default behavior is not compatible with the standard. For |
| users who wish to operate in a strict POSIX.2 environment, Bash |
| implements a \fIPOSIX mode\fP. When this mode is active, Bash modifies |
| its default operation where it differs from POSIX.2 to match the |
| standard. POSIX mode is entered when Bash is started with the |
| .B -posix |
| option. This feature is also available as an option to the |
| \fBset\fP builtin, \fBset -o posix\fP. |
| For compatibility with other GNU software that attempts to be POSIX.2 |
| compliant, Bash also enters POSIX mode if the variable |
| .B $POSIXLY_CORRECT |
| is set when Bash is started or assigned a value during execution. |
| .B $POSIX_PEDANTIC |
| 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 |
| .B $ENV |
| rather than the \*Qnormal\*U startup files, and does not allow |
| reserved words to be aliased. |
| .NH 1 |
| New Features and Future Plans |
| .PP |
| There are several features introduced in the current |
| version of Bash, version 1.14, and a number under consideration |
| 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. |
| .NH 2 |
| New Features in Bash-1.14 |
| .PP |
| 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. |
| .PP |
| Readline has a few new |
| variables, several new bindable commands, and some additional |
| emacs mode default key bindings. 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 directory names. |
| The history expansion facilities are now nearly |
| completely csh-compatible: missing modifiers have been added and |
| history substitution has been extended. |
| .PP |
| Several of the features described earlier, such as |
| .B "set -o posix" |
| and |
| .B $POSIX_PEDANTIC , |
| are new in version 1.14. |
| There is a new shell variable, |
| .B OSTYPE , |
| to which Bash assigns a value that identifies the |
| version of \s-1UNIX\s+1 it's |
| running on (great for putting architecture-specific binary directories |
| into the \fB$PATH\fP). |
| Two variables have been renamed: |
| .B $HISTCONTROL |
| replaces |
| .B $history_control , |
| and |
| .B $HOSTFILE |
| replaces |
| .B $hostname_completion_file . |
| In both cases, the old names are accepted for backwards |
| compatibility. The ksh |
| .I select |
| construct, which allows the generation of simple menus, |
| has been implemented. New capabilities have been added |
| to existing variables: |
| .B $auto_resume |
| can now take values of |
| .I exact |
| or |
| .I substring , |
| and |
| .B $HISTCONTROL |
| understands the value |
| .I ignoreboth , |
| which combines the two previously acceptable values. The |
| .B dirs |
| builtin has acquired options to print out specific members of the |
| directory stack. The |
| .B $nolinks |
| variable, which forces a physical view of the file system, |
| has been superseded by the |
| .B \-P |
| option to the |
| .B set |
| builtin (equivalent to \fBset -o physical\fP); the variable is retained |
| for backwards compatibility. The version string contained in |
| .B $BASH_VERSION |
| now includes an indication of the patch level as well as the |
| \*Qbuild version\*U. |
| Some little-used features have |
| been removed: the |
| .B bye |
| synonym for |
| .B exit |
| and the |
| .B $NO_PROMPT_VARS |
| 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. |
| .PP |
| The documentation has been thoroughly overhauled: |
| there is a new manual page on the readline library and the \fIinfo\fP |
| file has been updated to reflect the current version. |
| As always, as many bugs as possible have been fixed, although some |
| surely remain. |
| .NH 2 |
| Other Features |
| .PP |
| There are a few features that I hope to include in later Bash releases. |
| Some are based on work already done in other shells. |
| .PP |
| 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 \fIvarname\fP=( ... ) to assign a list of words directly to |
| an array and a mechanism to allow |
| the |
| .B read |
| builtin to read a list of values directly into an array, would be |
| desirable. Given those extensions, the ksh |
| .B "set \-A" |
| syntax may not be worth supporting (the |
| .B \-A |
| option assigns a list of values to an array, but is a rather |
| peculiar special case). |
| .PP |
| Some shells include a means of \fIprogrammable\fP word |
| completion, where the user specifies on a per-command basis how the |
| arguments of the command are to be treated when completion 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. |
| .PP |
| 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 |
| .B HISTIGNORE , |
| which would contain a colon-separated list of commands. Lines beginning |
| with these commands, after the restrictions of |
| .B $HISTCONTROL |
| 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 |
| .B $HISTIGNORE . |
| .PP |
| One thing that newer shells such as |
| .B wksh |
| (also known as |
| .B dtksh ) |
| provide is a command to dynamically load code |
| implementing additional builtin commands into a running shell. |
| This new builtin would take an object file or shared library |
| implementing the \*Qbody\*U of the |
| builtin (\fIxxx_builtin()\fP for those familiar with Bash internals) |
| and a structure containing 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 |
| .B help |
| command (possibly present in the shared object as well). It would |
| manage the details of extending the internal table of builtins. |
| .PP |
| A few other builtins would also be desirable: two are the POSIX.2 |
| .B getconf |
| command, which prints the values of system configuration variables |
| defined by POSIX.2, and a |
| .B disown |
| builtin, which causes a shell running |
| with job control active to \*Qforget about\*U one or more |
| background jobs in its internal jobs table. Using |
| .B getconf , |
| for example, a user could retrieve a value for |
| .B $PATH |
| 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. |
| .PP |
| 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. |
| .NH 1 |
| Reflections and Lessons Learned |
| .PP |
| 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 grammar are both poorly |
| specified and incomplete; subsequent descriptions have not helped |
| much. The grammar presented in Bourne's paper describing |
| the shell distributed with the Seventh Edition of \s-1UNIX\s+1\(dg |
| is so far off that it does not allow the command \f(CWwho|wc\fP. |
| In fact, as Tom Duff states: |
| .QP |
| Nobody really knows what the |
| Bourne shell's grammar is. Even examination of the source code is |
| little help.\(dd |
| .FS |
| \(dgS. R. Bourne, \*QUNIX Time-Sharing System: The UNIX Shell\*U, |
| \fIBell System Technical Journal\fP, 57(6), July-August, 1978, pp. 1971-1990. |
| .FE |
| .FS |
| \(ddTom Duff, \*QRc \- A Shell for Plan 9 and \s-1UNIX\s+1 systems\*U, |
| \fIProc. of the Summer 1990 EUUG Conference\fP, London, July, 1990, |
| pp. 21-33. |
| .FE |
| .LP |
| The POSIX.2 standard includes a \fIyacc\fP 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 \*Qlegal\*U sh constructs which Bash flags as |
| syntax errors. Complete sh compatibility is a tough nut. |
| .PP |
| The shell is bigger and slower than I would like, though the current |
| version is substantially faster than previously. The readline library |
| could stand a substantial rewrite. A hand-written parser to replace |
| the current \fIyacc\fP-generated one would probably result in a speedup, |
| and would solve one glaring problem: the shell could parse |
| commands in \*Q$(...)\*U constructs |
| as they are entered, rather than reporting errors when the construct |
| is expanded. |
| .PP |
| 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 specially to |
| enable functionality available another way (\fB$notify\fP vs. |
| \fBset -o notify\fP and \fB$nolinks\fP vs. \fBset -o physical\fP, for |
| instance); the special treatment of the variable name should probably |
| be removed. A few more things could stand removal; the |
| .B $allow_null_glob_expansion |
| and |
| .B $glob_dot_filenames |
| variables are of particularly questionable value. |
| The \fB$[...]\fP arithmetic evaluation syntax is redundant now that |
| the POSIX-mandated \fB$((...))\fP construct has been implemented, |
| and could be deleted. |
| It would be nice if the text output by the |
| .B help |
| builtin were external to the shell rather than compiled into it. |
| The behavior enabled by |
| .B $command_oriented_history , |
| which causes the shell to attempt to save all lines of a multi-line |
| command in a single history entry, should be made the default and |
| the variable removed. |
| .NH 1 |
| Availability |
| .PP |
| As with all other |
| GNU software, Bash is available for anonymous FTP from |
| .I prep.ai.mit.edu:/pub/gnu |
| and from other GNU software mirror sites. The current version is in |
| .I bash-1.14.1.tar.gz |
| in that directory. Use |
| .I archie |
| to find the nearest archive site. The |
| latest version is always available for FTP from |
| .I bash.CWRU.Edu:/pub/dist. |
| Bash documentation is available for FTP from |
| .I bash.CWRU.Edu:/pub/bash. |
| .PP |
| The Free Software Foundation sells tapes and CD-ROMs |
| containing Bash; send electronic mail to |
| \f(CRgnu@prep.ai.mit.edu\fP or call \f(CR+1-617-876-3296\fP |
| for more information. |
| .PP |
| Bash is also distributed with several versions of \s-1UNIX\s+1-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. |
| .FS |
| *BSD/386 is a trademark of Berkeley Software Design, Inc. |
| .FE |
| .PP |
| The Linux distribution deserves special mention. There are two |
| configurations included in the standard Bash distribution: a |
| \*Qnormal\*U configuration, in which all of the standard features |
| are included, and a \*Qminimal\*U configuration, which omits job |
| control, aliases, history and command line editing, the directory |
| stack and |
| .B pushd/popd/dirs, |
| process substitution, prompt string special character decoding, and the |
| .I select |
| construct. This minimal version is designed to be a drop-in replacement |
| for the traditional \s-1UNIX\s+1 /bin/sh, and is included as the Linux |
| /bin/sh in several packagings. |
| .NH 1 |
| Conclusion |
| .PP |
| Bash is a worthy successor to sh. |
| It is sufficiently portable |
| to run on nearly every version of \s-1UNIX\s+1 from |
| 4.3 BSD to SVR4.2, and several \s-1UNIX\s+1 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. |