








                   Bash - The GNU shell*


                         Chet Ramey
              Case Western Reserve University
                      chet@po.cwru.edu






1.  Introduction

     Bash 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 /bin/sh, 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.  What's POSIX, anyway?

     POSIX 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:

+    Aspects of the shell's syntax and command language.   A
     number  of  special  builtins  such  as cd and exec are
     being specified as part of the shell, since their func-
     tionality  usually  cannot be implemented by a separate
     executable;

+    A set of utilities to be called by  shell  scripts  and
     applications.   Examples are programs like sed, tr, and
     awk.  Utilities commonly implemented as shell  builtins
     are  described  in this section, such as test and kill.
     An expansion of this section's scope, termed  the  User
     Portability   Extension,   or   UPE,  has  standardized
     interactive programs such as vi and mailx;

+    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 (globbing),
     obtain values of  POSIX.2  system  configuration  vari-
     ables,   retrieve   values   of  environment  variables
     (getenv()), and other services;

+    A suite of "development" utilities  such  as  c89  (the
     POSIX.2 version of cc), and yacc.

     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  special  builtins,  which must be implemented as
part of the shell to provide the desired functionality,  are
_________________________
=IEEE, IEEE  Standard  for  Information  Technology  --
Portable  Operating  System  Interface  (POSIX) Part 2:
Shell and Utilities, 1992.




                      October 28, 1994





                           - 3 -


specified as being part of the shell; examples of these  are
eval  and 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
read and  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  vi-style line editing commands have been standardized;
emacs 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 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 .profile.

3.  Basic Bash features

     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 (for, if, while,
etc.).  All of the Bourne shell  builtins,  including  those
not  specified  in  the  POSIX.2  standard,  appear in Bash.
Shell functions, 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 PS1, IFS, and PATH.  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 RANDOM and REPLY, the typeset builtin,  the  ability
to  remove  substrings from variables based on patterns, and
shell arithmetic.  RANDOM expands to a  random  number  each
time it is referenced; assigning a value to RANDOM seeds the
_________________________
-Morris Bolsky and David Korn,  The  KornShell  Command
and Programming Language, Prentice Hall, 1989.




                      October 28, 1994





                           - 4 -


random number generator.  REPLY is the default variable used
by  the  read builtin when no variable names are supplied as
arguments.  The typeset 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  fc  (discussed  below)  and  jobs.  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  pushd,  popd,  and
dirs  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 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 "!" 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  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 argu-
ments are given to test, and leaves the  behavior  undefined
when  more  arguments  are  supplied.  Bash uses the POSIX.2
_________________________
-Bill Joy, An Introduction to the C Shell, UNIX  User's
Supplementary  Documents,  University  of California at
Berkeley, 1986.




                      October 28, 1994





                           - 5 -


algorithm, which was conceived by David Korn.

3.1.  Features not in the Bourne Shell

     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  command builtin, the ability of the read builtin
to correctly return a line ending with a backslash, symbolic
arguments  to the umask builtin, variable substring removal,
a way to get the length of a variable, and the new algorithm
for  the  test  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 $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
"."  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.  Bash-specific Features

     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.  Startup Files

     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
~/.bash_profile  (the  file .bash_profile in the user's home
directory), if it exists.  An  interactive  non-login  shell
reads  and executes ~/.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 $ENV, if
set, as the name of a startup file.   The  ksh  practice  of
reading  $ENV  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 $ENV only for interac-
tive shells.

4.2.  New Builtin Commands

     There are a few builtins which are  new  or  have  been
extended  in  Bash.   The enable builtin allows builtin com-
mands to be turned on and off arbitrarily.  To use the  ver-
sion  of  echo found in a user's search path rather than the
Bash builtin, enable -n echo  suffices.   The  help  builtin
provides  quick  synopses  of  the  shell facilities without
requiring access to a manual page.  Builtin  is  similar  to
command  in  that  it  bypasses shell functions and directly
executes builtin commands.  Access to a csh-style  stack  of
directories  is provided via the pushd, popd, and dirs buil-
tins.  Pushd and popd insert and remove directories from the
stack,  respectively, and dirs lists the stack contents.  On
systems that allow fine-grained control  of  resources,  the
ulimit  builtin  can be used to tune these settings.  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 suspend command
will stop the shell process when job control is active; most
other  shells  do  not  allow  themselves to be stopped like
that.  Type, the Bash answer to which and whence, 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 command utility.

4.3.  Editing and Completion

     One area in which Bash shines is command line  editing.
Bash  uses  the 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.

     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
inputrc file, which defaults to the file ~/.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 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  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 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
$PATH 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 bind builtin for more  dyamic  con-
trol  of  readline  than  the startup file permits.  Bind is
used in several ways.  In list  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  batch  mode,  it  reads a series of key bindings
directly from a file and passes them to  readline.   In  its
most  common usage, 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 bind.

     The readline library also  provides  an  interface  for
word  completion.   When  the  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 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.  History

     Access to the list of commands previously entered  (the
command  history)  is  provided  jointly  by  Bash  and  the


9                      October 28, 1994





                           - 9 -


readline  library.   Bash  provides  variables   ($HISTFILE,
$HISTSIZE, and $HISTCONTROL) and the history and fc builtins
to manipulate the history  list.   The  value  of  $HISTFILE
specifies the  file where Bash writes the command history on
exit and reads it on startup.  $HISTSIZE is  used  to  limit
the  number  of commands saved in the history.  $HISTCONTROL
provides a crude form of control  over  which  commands  are
saved  on  the history list: a value of ignorespace means to
not save commands which begin  with  a  space;  a  value  of
ignoredups  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 history command  can  read  or
write  files  containing  the  history  list and display the
current list contents.  The 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 his-
tory list for a portion of  the  current  input  line  or  a
string  typed  by  the  user.  Finally, the 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 ("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.  New Shell Variables

     There are a number of convenience variables  that  Bash
interprets  to  make  life  easier.   These include FIGNORE,
which is a set of filename  suffixes  identifying  files  to
exclude   when  completing  filenames;  HOSTTYPE,  which  is
automatically  set  to  a  string  describing  the  type  of
hardware    on    which   Bash   is   currently   executing;
command_oriented_history, which directs  Bash  to  save  all
lines of a multiple-line command such as a while or for loop
in a single history entry,  allowing  easy  re-editing;  and
IGNOREEOF,  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 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.

4.6.  Brace Expansion

     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  brace  expansion,  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 preamble,  followed
by  a  pair  of braces enclosing a series of comma-separated
strings,  and  an  optional  postamble.   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.  Process Substitution

     On systems that can support it, Bash provides a  facil-
ity  known as process substitution.  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  /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:
9     $ cmp <(old_prog) <(new_prog)
9
4.8.  Prompt Customization

     One of the more popular interactive features that  Bash
provides  is the ability to customize the prompt.  Both $PS1
and $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., $SHLVL, 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 su.  Before printing each pri-
mary prompt, Bash expands the variable $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:
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 $SHLVL 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.  File System Views

     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
cd,  and  the  resultant  non-intuitive behavior of "cd ..".
The UNIX kernel treats symbolic links 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 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 logical view of the  file  system.   In
this default mode, command and filename completion and buil-
tin commands such as cd and pushd which change  the  current
working  directory transparently follow symbolic links as if
they were directories.  The $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



                      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 physical 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.10.  Internationalization

     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.11.  POSIX Mode

     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 POSIX mode.
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  -posix
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  $POSIXLY_CORRECT  is  set
when  Bash  is started or assigned a value during execution.
$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
$ENV  rather  than  the "normal" startup files, and does not
allow reserved words to be aliased.

5.  New Features and Future Plans

     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.  New Features in Bash-1.14

     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  set
-o  posix  and  $POSIX_PEDANTIC,  are  new  in version 1.14.
There is a new shell variable, OSTYPE, 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: $HISTCON-
TROL  replaces  $history_control,  and  $HOSTFILE   replaces
$hostname_completion_file.  In both cases, the old names are
accepted for backwards compatibility.  The ksh  select  con-
struct,  which  allows  the  generation of simple menus, has
been implemented.   New  capabilities  have  been  added  to
existing  variables:  $auto_resume  can  now  take values of
exact or substring, and $HISTCONTROL understands  the  value
ignoreboth,  which  combines  the  two previously acceptable
values.  The dirs builtin has acquired options to print  out
specific members of the directory stack.  The $nolinks vari-
able, which forces a physical view of the file  system,  has
been  superseded  by  the  -P  option  to  the  set  builtin
(equivalent to set -o physical); the  variable  is  retained
for  backwards  compatibility.  The version string contained
in $BASH_VERSION now includes an  indication  of  the  patch
level  as  well  as  the  "build version".  Some little-used
features have been removed:  the bye synonym  for  exit  and
the  $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.

     The documentation has been thoroughly overhauled: there
is  a  new  manual page on the readline library and the info
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.  Other Features

     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  varname=( ... ) to assign a list of words
directly to an array and a mechanism to allow the read buil-
tin  to  read a list of values directly into an array, would
be desirable.  Given those extensions, the ksh set -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 programmable  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  HISTIG-
NORE,  which  would  contain  a colon-separated list of com-
mands.  Lines beginning with these commands, after the  res-
trictions  of  $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 $HISTIGNORE.

     One thing that newer shells such as wksh (also known as
dtksh)  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  (xxx_builtin()  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  help  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 getconf command, which prints the values of sys-
tem configuration variables defined by POSIX.2, and a disown
builtin,  which  causes  a  shell  running  with job control
active to "forget about" one or more background jobs in  its
internal  jobs  table.   Using  getconf, for example, a user
could retrieve a value for $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.

     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.  Reflections and Lessons Learned

     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  yacc  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
yacc-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    $allow_null_glob_expansion   and
$glob_dot_filenames 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 help builtin  were  external  to  the
shell rather than compiled into it.  The behavior enabled by
$command_oriented_history, 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",  Bell  System  Technical  Journal, 57(6), July-
August, 1978, pp. 1971-1990.
=Tom Duff, "Rc - A Shell for Plan 9 and UNIX  systems",
Proc. of the Summer 1990 EUUG Conference, London, July,
1990, pp. 21-33.




                      October 28, 1994





                           - 17 -


7.  Availability

     As with all other GNU software, Bash is  available  for
anonymous  FTP  from prep.ai.mit.edu:/pub/gnu and from other
GNU software mirror sites.  The current version is in  bash-
1.14.1.tar.gz  in  that  directory.   Use archie to find the
nearest archive site.  The latest version is  always  avail-
able  for FTP from bash.CWRU.Edu:/pub/dist.  Bash documenta-
tion is available for FTP from bash.CWRU.Edu:/pub/bash.

     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 pushd/popd/dirs, process
substitution, prompt string special character decoding,  and
the  select  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.  Conclusion

     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
