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