article.txt

android-w.song.android.widget

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 [e-mail]
or call [phone] 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