diff options
Diffstat (limited to 'doc/article.ms')
-rw-r--r-- | doc/article.ms | 1114 |
1 files changed, 0 insertions, 1114 deletions
diff --git a/doc/article.ms b/doc/article.ms deleted file mode 100644 index 517155a..0000000 --- a/doc/article.ms +++ /dev/null @@ -1,1114 +0,0 @@ -.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 descendent of the Bourne shell written -at AT&T Bell Laboratories by David Korn\(dg. It provides a number of -useful features that POSIX and Bash have adopted. Many of the -interactive facilities in POSIX.2 have their roots in the ksh: -for example, the POSIX and ksh job control facilities are nearly -identical. Bash includes features from the Korn Shell for both -interactive use and shell programming. For programming, Bash provides -variables such as -.B RANDOM -and -.B REPLY , -the -.B typeset -builtin, -the ability to remove substrings from variables based on patterns, -and shell arithmetic. -.FS -\(dgMorris Bolsky and David Korn, \fIThe KornShell Command and -Programming Language\fP, Prentice Hall, 1989. -.FE -.B RANDOM -expands to a random number each time it is referenced; assigning a -value to -.B RANDOM -seeds the random number generator. -.B REPLY -is the default variable used by the -.B read -builtin when no variable names are supplied as arguments. -The -.B typeset -builtin is used to define variables and give them attributes -such as \fBreadonly\fP. -Bash arithmetic allows the evaluation of an expression and the -substitution of the result. Shell variables may be used as operands, -and the result of an expression may be assigned to a variable. -Nearly all of the operators from the C language are available, -with the same precedence rules: -.SE -$ echo $((3 + 5 * 32)) -163 -.EE -.LP -For interactive use, Bash implements ksh-style aliases and builtins -such as -.B fc -(discussed below) and -.B jobs . -Bash aliases allow a string to be substituted for a command name. -They can be used to create a mnemonic for a \s-1UNIX\s+1 command -name (\f(CRalias del=rm\fP), to expand a single word to a complex command -(\f(CRalias news='xterm -g 80x45 -title trn -e trn -e -S1 -N &'\fP), or to -ensure that a command is invoked with a basic set of options -(\f(CRalias ls="/bin/ls -F"\fP). -.PP -The C shell (\fBcsh\fP)\(dg, originally written by Bill Joy while at -Berkeley, is widely used and quite popular for its interactive -facilities. Bash includes a csh-compatible history expansion -mechanism (\*Q! history\*U), brace expansion, access to a stack -of directories via the -.B pushd , -.B popd , -and -.B dirs -builtins, and tilde expansion, to generate users' home directories. -Tilde expansion has also been adopted by both the Korn Shell and -POSIX.2. -.FS -\(dgBill Joy, An Introduction to the C Shell, \fIUNIX User's Supplementary -Documents\fP, University of California at Berkeley, 1986. -.FE -.PP -There were certain areas in which POSIX.2 felt standardization -was necessary, but no existing implementation provided the proper -behavior. The working group invented and standardized functionality -in these areas, which Bash implements. The -.B command -builtin was invented so that shell functions could be written to -replace builtins; it makes the capabilities of the builtin -available to the function. The reserved word \*Q!\*U was added -to negate the return value of a command or pipeline; it was nearly -impossible to express \*Qif not x\*U cleanly using the sh language. -There exist multiple incompatible implementations of the -.B test -builtin, which tests files for type and other attributes and performs -arithmetic and string comparisons. -POSIX considered none of these correct, so the standard -behavior was specified in terms of the number of arguments to the -command. POSIX.2 dictates exactly what will happen when four or -fewer arguments are given to -.B test , -and leaves the behavior undefined when more arguments are supplied. -Bash uses the POSIX.2 algorithm, which was conceived by David Korn. -.NH 2 -Features not in the Bourne Shell -.PP -There are a number of minor differences between Bash and the -version of sh present on most other versions of \s-1UNIX\s+1. The majority -of these are due to the POSIX standard, but some are the result of -Bash adopting features from other shells. For instance, Bash -includes the new \*Q!\*U reserved word, the -.B command -builtin, the ability of the -.B read -builtin to correctly return a line ending with a backslash, symbolic -arguments to the -.B umask -builtin, variable substring removal, a way to get the length of a variable, -and the new algorithm for the -.B test -builtin from the POSIX.2 standard, none of which appear in sh. -.PP -Bash also implements the \*Q$(...)\*U command substitution syntax, -which supersedes the sh `...` construct. -The \*Q$(...)\*U construct expands to the output of the command -contained within the -parentheses, with trailing newlines removed. The sh syntax is -accepted for backwards compatibility, but the \*Q$(...)\*U form -is preferred because its quoting rules are much simpler and it -is easier to nest. -.PP -The Bourne shell does not provide such features as brace expansion, -the ability -to define a variable and a function with the same name, local variables -in shell functions, the ability to enable and disable individual -builtins or write a function to replace a builtin, or a means to -export a shell function to a child process. -.PP -Bash has closed -a long-standing shell security hole by not using the -.B $IFS -variable to split each word read by the shell, but splitting only -the results of expansion (ksh and the 4.4 BSD sh have fixed this -as well). Useful behavior such as a means to abort -execution of a script read with the \*Q.\*U command using the -\fBreturn\fP builtin or automatically -exporting variables in the shell's environment to children is also -not present in the Bourne shell. Bash provides a much more powerful -environment for both interactive use and programming. -.NH 1 -Bash-specific Features -.PP -This section details a few of the features which make Bash unique. -Most of them provide improved interactive use, but a few programming -improvements are present as well. Full descriptions of these -features can be found in the Bash documentation. -.NH 2 -Startup Files -.PP -Bash executes startup files differently than other shells. The Bash -behavior is a compromise between the csh principle of startup files -with fixed names executed for each shell and the sh -\*Qminimalist\*U behavior. An interactive instance of Bash started -as a login shell reads and executes -.I ~/.bash_profile -(the file .bash_profile in the user's home directory), if it exists. -An interactive non-login shell reads and executes -.I ~/.bashrc . -A non-interactive shell (one begun to execute a shell script, for -example) reads no fixed startup file, but uses the value of the variable -.B $ENV , -if set, as the name of a startup file. The ksh practice of reading -.B $ENV -for every shell, with the accompanying difficulty of defining the -proper variables and functions for interactive and non-interactive -shells or having the file read only for interactive shells, was -considered too complex. Ease of use won out here. Interestingly, -the next release of ksh will change to reading -.B $ENV -only for interactive shells. -.NH 2 -New Builtin Commands -.PP -There are a few builtins which are new or have been extended in Bash. -The -.B enable -builtin allows builtin commands to be turned on and off arbitrarily. -To use the version of -.I echo -found in a user's search path rather than the Bash builtin, -\f(CRenable -n echo\fP suffices. The -.B help -builtin provides -quick synopses of the shell facilities without requiring -access to a manual page. -.B Builtin -is similar to -.B command -in that it bypasses shell functions and directly executes builtin -commands. Access to a csh-style stack of directories is provided -via the -.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 dyamic 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 -specifes 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. |