article.ms

android-w.song.android.widget

/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([e-mail]\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.