article.ms

android-w.song.android.widget

.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