mirror of
https://github.com/Gator96100/ProxSpace.git
synced 2025-01-25 20:23:03 -08:00
2415 lines
97 KiB
Plaintext
2415 lines
97 KiB
Plaintext
This is the Bash FAQ, version 4.15, for Bash version 5.1.
|
|
|
|
[This document is no longer maintained.]
|
|
|
|
This document contains a set of frequently-asked questions concerning
|
|
Bash, the GNU Bourne-Again Shell. Bash is a freely-available command
|
|
interpreter with advanced features for both interactive use and shell
|
|
programming.
|
|
|
|
Another good source of basic information about shells is the collection
|
|
of FAQ articles periodically posted to comp.unix.shell.
|
|
|
|
Questions and comments concerning this document should be sent to
|
|
chet.ramey@case.edu.
|
|
|
|
This document is available for anonymous FTP with the URL
|
|
|
|
ftp://ftp.cwru.edu/pub/bash/FAQ
|
|
|
|
The Bash home page is http://cnswww.cns.cwru.edu/~chet/bash/bashtop.html
|
|
|
|
----------
|
|
Contents:
|
|
|
|
Section A: The Basics
|
|
|
|
A1) What is it?
|
|
A2) What's the latest version?
|
|
A3) Where can I get it?
|
|
A4) On what machines will bash run?
|
|
A5) Will bash run on operating systems other than Unix?
|
|
A6) How can I build bash with gcc?
|
|
A7) How can I make bash my login shell?
|
|
A8) I just changed my login shell to bash, and now I can't FTP into my
|
|
machine. Why not?
|
|
A9) What's the `POSIX Shell and Utilities standard'?
|
|
A10) What is the bash `posix mode'?
|
|
|
|
Section B: The latest version
|
|
|
|
B1) What's new in version 4.3?
|
|
B2) Are there any user-visible incompatibilities between bash-4.3 and
|
|
previous bash versions?
|
|
|
|
Section C: Differences from other Unix shells
|
|
|
|
C1) How does bash differ from sh, the Bourne shell?
|
|
C2) How does bash differ from the Korn shell, version ksh88?
|
|
C3) Which new features in ksh-93 are not in bash, and which are?
|
|
|
|
Section D: Why does bash do some things differently than other Unix shells?
|
|
|
|
D1) Why does bash run a different version of `command' than
|
|
`which command' says it will?
|
|
D2) Why doesn't bash treat brace expansions exactly like csh?
|
|
D3) Why doesn't bash have csh variable modifiers?
|
|
D4) How can I make my csh aliases work when I convert to bash?
|
|
D5) How can I pipe standard output and standard error from one command to
|
|
another, like csh does with `|&'?
|
|
D6) Now that I've converted from ksh to bash, are there equivalents to
|
|
ksh features like autoloaded functions and the `whence' command?
|
|
|
|
Section E: Why does bash do certain things the way it does?
|
|
|
|
E1) Why is the bash builtin `test' slightly different from /bin/test?
|
|
E2) Why does bash sometimes say `Broken pipe'?
|
|
E3) When I have terminal escape sequences in my prompt, why does bash
|
|
wrap lines at the wrong column?
|
|
E4) If I pipe the output of a command into `read variable', why doesn't
|
|
the output show up in $variable when the read command finishes?
|
|
E5) I have a bunch of shell scripts that use backslash-escaped characters
|
|
in arguments to `echo'. Bash doesn't interpret these characters. Why
|
|
not, and how can I make it understand them?
|
|
E6) Why doesn't a while or for loop get suspended when I type ^Z?
|
|
E7) What about empty for loops in Makefiles?
|
|
E8) Why does the arithmetic evaluation code complain about `08'?
|
|
E9) Why does the pattern matching expression [A-Z]* match files beginning
|
|
with every letter except `z'?
|
|
E10) Why does `cd //' leave $PWD as `//'?
|
|
E11) If I resize my xterm while another program is running, why doesn't bash
|
|
notice the change?
|
|
E12) Why don't negative offsets in substring expansion work like I expect?
|
|
E13) Why does filename completion misbehave if a colon appears in the filename?
|
|
E14) Why does quoting the pattern argument to the regular expression matching
|
|
conditional operator (=~) cause matching to stop working?
|
|
E15) Tell me more about the shell compatibility level.
|
|
|
|
Section F: Things to watch out for on certain Unix versions
|
|
|
|
F1) Why can't I use command line editing in my `cmdtool'?
|
|
F2) I built bash on Solaris 2. Why do globbing expansions and filename
|
|
completion chop off the first few characters of each filename?
|
|
F3) Why does bash dump core after I interrupt username completion or
|
|
`~user' tilde expansion on a machine running NIS?
|
|
F4) I'm running SVR4.2. Why is the line erased every time I type `@'?
|
|
F5) Why does bash report syntax errors when my C News scripts use a
|
|
redirection before a subshell command?
|
|
F6) Why can't I use vi-mode editing on Red Hat Linux 6.1?
|
|
F7) Why do bash-2.05a and bash-2.05b fail to compile `printf.def' on
|
|
HP/UX 11.x?
|
|
|
|
Section G: How can I get bash to do certain common things?
|
|
|
|
G1) How can I get bash to read and display eight-bit characters?
|
|
G2) How do I write a function `x' to replace builtin command `x', but
|
|
still invoke the command from within the function?
|
|
G3) How can I find the value of a shell variable whose name is the value
|
|
of another shell variable?
|
|
G4) How can I make the bash `time' reserved word print timing output that
|
|
looks like the output from my system's /usr/bin/time?
|
|
G5) How do I get the current directory into my prompt?
|
|
G6) How can I rename "*.foo" to "*.bar"?
|
|
G7) How can I translate a filename from uppercase to lowercase?
|
|
G8) How can I write a filename expansion (globbing) pattern that will match
|
|
all files in the current directory except "." and ".."?
|
|
|
|
Section H: Where do I go from here?
|
|
|
|
H1) How do I report bugs in bash, and where should I look for fixes and
|
|
advice?
|
|
H2) What kind of bash documentation is there?
|
|
H3) What's coming in future versions?
|
|
H4) What's on the bash `wish list'?
|
|
H5) When will the next release appear?
|
|
|
|
----------
|
|
Section A: The Basics
|
|
|
|
A1) What is it?
|
|
|
|
Bash is a Unix command interpreter (shell). It is an implementation of
|
|
the Posix 1003.2 shell standard, and resembles the Korn and System V
|
|
shells.
|
|
|
|
Bash contains a number of enhancements over those shells, both
|
|
for interactive use and shell programming. Features geared
|
|
toward interactive use include command line editing, command
|
|
history, job control, aliases, and prompt expansion. Programming
|
|
features include additional variable expansions, shell
|
|
arithmetic, and a number of variables and options to control
|
|
shell behavior.
|
|
|
|
Bash was originally written by Brian Fox of the Free Software
|
|
Foundation. The current developer and maintainer is Chet Ramey
|
|
of Case Western Reserve University.
|
|
|
|
A2) What's the latest version?
|
|
|
|
The latest version is 4.3, first made available on 26 February, 2014.
|
|
|
|
A3) Where can I get it?
|
|
|
|
Bash is the GNU project's shell, and so is available from the
|
|
master GNU archive site, ftp.gnu.org, and its mirrors. The
|
|
latest version is also available for FTP from ftp.cwru.edu.
|
|
The following URLs tell how to get version 4.3:
|
|
|
|
ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3.tar.gz
|
|
ftp://ftp.cwru.edu/pub/bash/bash-4.3.tar.gz
|
|
|
|
Formatted versions of the documentation are available with the URLs:
|
|
|
|
ftp://ftp.gnu.org/pub/gnu/bash/bash-doc-4.3.tar.gz
|
|
ftp://ftp.cwru.edu/pub/bash/bash-doc-4.3.tar.gz
|
|
|
|
Any patches for the current version are available with the URL:
|
|
|
|
ftp://ftp.cwru.edu/pub/bash/bash-4.3-patches/
|
|
|
|
A4) On what machines will bash run?
|
|
|
|
Bash has been ported to nearly every version of Unix. All you
|
|
should have to do to build it on a machine for which a port
|
|
exists is to type `configure' and then `make'. The build process
|
|
will attempt to discover the version of Unix you have and tailor
|
|
itself accordingly, using a script created by GNU autoconf.
|
|
|
|
More information appears in the file `INSTALL' in the distribution.
|
|
|
|
The Bash web page (http://cnswww.cns.cwru.edu/~chet/bash/bashtop.html)
|
|
explains how to obtain binary versions of bash for most of the major
|
|
commercial Unix systems.
|
|
|
|
A5) Will bash run on operating systems other than Unix?
|
|
|
|
Configuration specifics for Unix-like systems such as QNX and
|
|
LynxOS are included in the distribution. Bash-2.05 and later
|
|
versions should compile and run on Minix 2.0 (patches were
|
|
contributed), but I don't believe anyone has built bash-2.x on
|
|
earlier Minix versions yet.
|
|
|
|
Bash has been ported to versions of Windows implementing the Win32
|
|
programming interface. This includes Windows 95 and Windows NT.
|
|
The port was done by Cygnus Solutions (now part of Red Hat) as part
|
|
of their CYGWIN project. For more information about the project, see
|
|
http://www.cygwin.com/.
|
|
|
|
Cygnus originally ported bash-1.14.7, and that port was part of their
|
|
early GNU-Win32 (the original name) releases. Cygnus has also done
|
|
ports of bash-3.2 and bash-4.0 to the CYGWIN environment, and both
|
|
are available as part of their current release.
|
|
|
|
Bash-2.05b and later versions should require no local Cygnus changes to
|
|
build and run under CYGWIN.
|
|
|
|
DJ Delorie has a port of bash-2.x which runs under MS-DOS, as part
|
|
of the DJGPP project. For more information on the project, see
|
|
|
|
http://www.delorie.com/djgpp/
|
|
|
|
I have been told that the original DJGPP port was done by Daisuke Aoyama.
|
|
|
|
Mark Elbrecht <snowball3@bigfoot.com> has sent me notice that bash-2.04
|
|
is available for DJGPP V2. The files are available as:
|
|
|
|
ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2gnu/bsh204b.zip binary
|
|
ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2gnu/bsh204d.zip documentation
|
|
ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2gnu/bsh204s.zip source
|
|
|
|
Mark began to work with bash-2.05, but I don't know the current status.
|
|
|
|
Bash-3.0 compiles and runs with no modifications under Microsoft's Services
|
|
for Unix (SFU), once known as Interix. I do not anticipate any problems
|
|
with building bash-4.2 and later, but will gladly accept any patches that
|
|
are needed.
|
|
|
|
A6) How can I build bash with gcc?
|
|
|
|
Bash configures to use gcc by default if it is available. Read the
|
|
file INSTALL in the distribution for more information.
|
|
|
|
A7) How can I make bash my login shell?
|
|
|
|
Some machines let you use `chsh' to change your login shell. Other
|
|
systems use `passwd -s' or `passwd -e'. If one of these works for
|
|
you, that's all you need. Note that many systems require the full
|
|
pathname to a shell to appear in /etc/shells before you can make it
|
|
your login shell. For this, you may need the assistance of your
|
|
friendly local system administrator.
|
|
|
|
If you cannot do this, you can still use bash as your login shell, but
|
|
you need to perform some tricks. The basic idea is to add a command
|
|
to your login shell's startup file to replace your login shell with
|
|
bash.
|
|
|
|
For example, if your login shell is csh or tcsh, and you have installed
|
|
bash in /usr/gnu/bin/bash, add the following line to ~/.login:
|
|
|
|
if ( -f /usr/gnu/bin/bash ) exec /usr/gnu/bin/bash --login
|
|
|
|
(the `--login' tells bash that it is a login shell).
|
|
|
|
It's not a good idea to put this command into ~/.cshrc, because every
|
|
csh you run without the `-f' option, even ones started to run csh scripts,
|
|
reads that file. If you must put the command in ~/.cshrc, use something
|
|
like
|
|
|
|
if ( $?prompt ) exec /usr/gnu/bin/bash --login
|
|
|
|
to ensure that bash is exec'd only when the csh is interactive.
|
|
|
|
If your login shell is sh or ksh, you have to do two things.
|
|
|
|
First, create an empty file in your home directory named `.bash_profile'.
|
|
The existence of this file will prevent the exec'd bash from trying to
|
|
read ~/.profile, and re-execing itself over and over again. ~/.bash_profile
|
|
is the first file bash tries to read initialization commands from when
|
|
it is invoked as a login shell.
|
|
|
|
Next, add a line similar to the above to ~/.profile:
|
|
|
|
[ -f /usr/gnu/bin/bash ] && [ -x /usr/gnu/bin/bash ] && \
|
|
exec /usr/gnu/bin/bash --login
|
|
|
|
This will cause login shells to replace themselves with bash running as
|
|
a login shell. Once you have this working, you can copy your initialization
|
|
code from ~/.profile to ~/.bash_profile.
|
|
|
|
I have received word that the recipe supplied above is insufficient for
|
|
machines running CDE. CDE has a maze of twisty little startup files, all
|
|
slightly different.
|
|
|
|
If you cannot change your login shell in the password file to bash, you
|
|
will have to (apparently) live with CDE using the shell in the password
|
|
file to run its startup scripts. If you have changed your shell to bash,
|
|
there is code in the CDE startup files (on Solaris, at least) that attempts
|
|
to do the right thing. It is, however, often broken, and may require that
|
|
you use the $BASH_ENV trick described below.
|
|
|
|
`dtterm' claims to use $SHELL as the default program to start, so if you
|
|
can change $SHELL in the CDE startup files, you should be able to use bash
|
|
in your terminal windows.
|
|
|
|
Setting DTSOURCEPROFILE in ~/.dtprofile will cause the `Xsession' program
|
|
to read your login shell's startup files. You may be able to use bash for
|
|
the rest of the CDE programs by setting SHELL to bash in ~/.dtprofile as
|
|
well, but I have not tried this.
|
|
|
|
You can use the above `exec' recipe to start bash when not logging in with
|
|
CDE by testing the value of the DT variable:
|
|
|
|
if [ -n "$DT" ]; then
|
|
[ -f /usr/gnu/bin/bash ] && exec /usr/gnu/bin/bash --login
|
|
fi
|
|
|
|
If CDE starts its shells non-interactively during login, the login shell
|
|
startup files (~/.profile, ~/.bash_profile) will not be sourced at login.
|
|
To get around this problem, append a line similar to the following to your
|
|
~/.dtprofile:
|
|
|
|
BASH_ENV=${HOME}/.bash_profile ; export BASH_ENV
|
|
|
|
and add the following line to the beginning of ~/.bash_profile:
|
|
|
|
unset BASH_ENV
|
|
|
|
A8) I just changed my login shell to bash, and now I can't FTP into my
|
|
machine. Why not?
|
|
|
|
You must add the full pathname to bash to the file /etc/shells. As
|
|
noted in the answer to the previous question, many systems require
|
|
this before you can make bash your login shell.
|
|
|
|
Most versions of ftpd use this file to prohibit `special' users
|
|
such as `uucp' and `news' from using FTP.
|
|
|
|
A9) What's the `POSIX Shell and Utilities standard'?
|
|
|
|
POSIX is a name originally coined by Richard Stallman 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 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.
|
|
|
|
The POSIX Shell and Utilities standard was originally developed by
|
|
IEEE Working Group 1003.2 (POSIX.2). Today it has been merged with
|
|
the original 1003.1 Working Group and is maintained by the Austin
|
|
Group (a joint working group of the IEEE, The Open Group and
|
|
ISO/IEC SC22/WG15). Today the Shell and Utilities are a volume
|
|
within the set of documents that make up IEEE Std 1003.1-2001, and
|
|
thus now the former POSIX.2 (from 1992) is now part of the current
|
|
POSIX.1 standard (POSIX 1003.1-2001).
|
|
|
|
The Shell and Utilities volume concentrates on the command
|
|
interpreter interface and utility programs commonly executed from
|
|
the command line or by other programs. The standard is freely
|
|
available on the web at http://www.UNIX-systems.org/version3/ .
|
|
Work continues at the Austin Group on maintenance issues; see
|
|
http://www.opengroup.org/austin/ to join the discussions.
|
|
|
|
Bash is concerned with the aspects of the shell's behavior defined
|
|
by the POSIX Shell and Utilities volume. 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 `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 `eval' and
|
|
`export'. Other utilities appear in the sections of POSIX not
|
|
devoted to the shell which are commonly (and in some cases must
|
|
be) implemented as builtin commands, such as `read' and `test'.
|
|
POSIX also specifies aspects of the shell's interactive
|
|
behavior as part of the UPE, including job control and command
|
|
line editing. Only vi-style line editing commands have been
|
|
standardized; emacs editing commands were left out due to
|
|
objections.
|
|
|
|
The latest version of the POSIX Shell and Utilities standard is
|
|
available (now updated to the 2004 Edition) as part of the Single
|
|
UNIX Specification Version 3 at
|
|
|
|
http://www.UNIX-systems.org/version3/
|
|
|
|
A10) What is the bash `posix mode'?
|
|
|
|
Although bash is an implementation of the POSIX shell
|
|
specification, there are areas where the bash default behavior
|
|
differs from that spec. The bash `posix mode' changes the bash
|
|
behavior in these areas so that it obeys the spec more closely.
|
|
|
|
Posix mode is entered by starting bash with the --posix or
|
|
'-o posix' option or executing `set -o posix' after bash is running.
|
|
|
|
The specific aspects of bash which change when posix mode is
|
|
active are listed in the file POSIX in the bash distribution.
|
|
They are also listed in a section in the Bash Reference Manual
|
|
(from which that file is generated).
|
|
|
|
Section B: The latest version
|
|
|
|
B1) What's new in version 4.3?
|
|
|
|
Bash-4.3 is the third revision to the fourth major release of bash.
|
|
|
|
Bash-4.3 contains the following new features (see the manual page for
|
|
complete descriptions and the CHANGES and NEWS files in the bash-4.3
|
|
distribution):
|
|
|
|
o The `helptopic' completion action now maps to all the help topics, not just
|
|
the shell builtins.
|
|
|
|
o The `help' builtin no longer does prefix substring matching first, so
|
|
`help read' does not match `readonly', but will do it if exact string
|
|
matching fails.
|
|
|
|
o The shell can be compiled to not display a message about processes that
|
|
terminate due to SIGTERM.
|
|
|
|
o Non-interactive shells now react to the setting of checkwinsize and set
|
|
LINES and COLUMNS after a foreground job exits.
|
|
|
|
o There is a new shell option, `globasciiranges', which, when set to on,
|
|
forces globbing range comparisons to use character ordering as if they
|
|
were run in the C locale.
|
|
|
|
o There is a new shell option, `direxpand', which makes filename completion
|
|
expand variables in directory names in the way bash-4.1 did.
|
|
|
|
o In Posix mode, the `command' builtin does not change whether or not a
|
|
builtin it shadows is treated as an assignment builtin.
|
|
|
|
o The `return' and `exit' builtins accept negative exit status arguments.
|
|
|
|
o The word completion code checks whether or not a filename containing a
|
|
shell variable expands to a directory name and appends `/' to the word
|
|
as appropriate. The same code expands shell variables in command names
|
|
when performing command completion.
|
|
|
|
o In Posix mode, it is now an error to attempt to define a shell function
|
|
with the same name as a Posix special builtin.
|
|
|
|
o When compiled for strict Posix conformance, history expansion is disabled
|
|
by default.
|
|
|
|
o The history expansion character (!) does not cause history expansion when
|
|
followed by the closing quote in a double-quoted string.
|
|
|
|
o `complete' and its siblings compgen/compopt now takes a new `-o noquote'
|
|
option to inhibit quoting of the completions.
|
|
|
|
o Setting HISTSIZE to a value less than zero causes the history list to be
|
|
unlimited (setting it 0 zero disables the history list).
|
|
|
|
o Setting HISTFILESIZE to a value less than zero causes the history file size
|
|
to be unlimited (setting it to 0 causes the history file to be truncated
|
|
to zero size).
|
|
|
|
o The `read' builtin now skips NUL bytes in the input.
|
|
|
|
o There is a new `bind -X' option to print all key sequences bound to Unix
|
|
commands.
|
|
|
|
o When in Posix mode, `read' is interruptible by a trapped signal. After
|
|
running the trap handler, read returns 128+signal and throws away any
|
|
partially-read input.
|
|
|
|
o The command completion code skips whitespace and assignment statements
|
|
before looking for the command name word to be completed.
|
|
|
|
o The build process has a new mechanism for constructing separate help files
|
|
that better reflects the current set of compilation options.
|
|
|
|
o The -nt and -ot options to test now work with files with nanosecond
|
|
timestamp resolution.
|
|
|
|
o The shell saves the command history in any shell for which history is
|
|
enabled and HISTFILE is set, not just interactive shells.
|
|
|
|
o The shell has `nameref' variables and new -n(/+n) options to declare and
|
|
unset to use them, and a `test -R' option to test for them.
|
|
|
|
o The shell now allows assigning, referencing, and unsetting elements of
|
|
indexed arrays using negative subscripts (a[-1]=2, echo ${a[-1]}) which
|
|
count back from the last element of the array.
|
|
|
|
o The {x}<word redirection feature now allows words like {array[ind]} and
|
|
can use variables with special meanings to the shell (e.g., BASH_XTRACEFD).
|
|
|
|
o There is a new CHILD_MAX special shell variable; its value controls the
|
|
number of exited child statues the shell remembers.
|
|
|
|
o There is a new configuration option (--enable-direxpand-default) that
|
|
causes the `direxpand' shell option to be enabled by default.
|
|
|
|
o Bash does not do anything special to ensure that the file descriptor
|
|
assigned to X in {x}<foo remains open after the block containing it
|
|
completes.
|
|
|
|
o The `wait' builtin has a new `-n' option to wait for the next child to
|
|
change status.
|
|
|
|
o The `printf' %(...)T format specifier now uses the current time if no
|
|
argument is supplied.
|
|
|
|
o There is a new variable, BASH_COMPAT, that controls the current shell
|
|
compatibility level.
|
|
|
|
o The `popd' builtin now treats additional arguments as errors.
|
|
|
|
o The brace expansion code now treats a failed sequence expansion as a
|
|
simple string and will continue to expand brace terms in the remainder
|
|
of the word.
|
|
|
|
o Shells started to run process substitutions now run any trap set on EXIT.
|
|
|
|
o The fc builtin now interprets -0 as the current command line.
|
|
|
|
o Completing directory names containing shell variables now adds a trailing
|
|
slash if the expanded result is a directory.
|
|
|
|
A short feature history dating back to Bash-2.0:
|
|
|
|
Bash-4.2 contained the following new features:
|
|
|
|
o `exec -a foo' now sets $0 to `foo' in an executable shell script without a
|
|
leading #!.
|
|
|
|
o Subshells begun to execute command substitutions or run shell functions or
|
|
builtins in subshells do not reset trap strings until a new trap is
|
|
specified. This allows $(trap) to display the caller's traps and the
|
|
trap strings to persist until a new trap is set.
|
|
|
|
o `trap -p' will now show signals ignored at shell startup, though their
|
|
disposition still cannot be modified.
|
|
|
|
o $'...', echo, and printf understand \uXXXX and \UXXXXXXXX escape sequences.
|
|
|
|
o declare/typeset has a new `-g' option, which creates variables in the
|
|
global scope even when run in a shell function.
|
|
|
|
o test/[/[[ have a new -v variable unary operator, which returns success if
|
|
`variable' has been set.
|
|
|
|
o Posix parsing changes to allow `! time command' and multiple consecutive
|
|
instances of `!' (which toggle) and `time' (which have no cumulative
|
|
effect).
|
|
|
|
o Posix change to allow `time' as a command by itself to print the elapsed
|
|
user, system, and real times for the shell and its children.
|
|
|
|
o $((...)) is always parsed as an arithmetic expansion first, instead of as
|
|
a potential nested command substitution, as Posix requires.
|
|
|
|
o A new FUNCNEST variable to allow the user to control the maximum shell
|
|
function nesting (recursive execution) level.
|
|
|
|
o The mapfile builtin now supplies a third argument to the callback command:
|
|
the line about to be assigned to the supplied array index.
|
|
|
|
o The printf builtin has as new %(fmt)T specifier, which allows time values
|
|
to use strftime-like formatting.
|
|
|
|
o There is a new `compat41' shell option.
|
|
|
|
o The cd builtin has a new Posix-mandated `-e' option.
|
|
|
|
o Negative subscripts to indexed arrays, previously errors, now are treated
|
|
as offsets from the maximum assigned index + 1.
|
|
|
|
o Negative length specifications in the ${var:offset:length} expansion,
|
|
previously errors, are now treated as offsets from the end of the variable.
|
|
|
|
o Parsing change to allow `time -p --'.
|
|
|
|
o Posix-mode parsing change to not recognize `time' as a keyword if the
|
|
following token begins with a `-'. This means no more Posix-mode
|
|
`time -p'. Posix interpretation 267.
|
|
|
|
o There is a new `lastpipe' shell option that runs the last command of a
|
|
pipeline in the current shell context. The lastpipe option has no
|
|
effect if job control is enabled.
|
|
|
|
o History expansion no longer expands the `$!' variable expansion.
|
|
|
|
o Posix mode shells no longer exit if a variable assignment error occurs
|
|
with an assignment preceding a command that is not a special builtin.
|
|
|
|
o Non-interactive mode shells exit if -u is enabled an an attempt is made
|
|
to use an unset variable with the % or # expansions, the `//', `^', or
|
|
`,' expansions, or the parameter length expansion.
|
|
|
|
o Posix-mode shells use the argument passed to `.' as-is if a $PATH search
|
|
fails, effectively searching the current directory. Posix-2008 change.
|
|
|
|
A short feature history dating back to Bash-2.0:
|
|
|
|
Bash-4.1 contained the following new features:
|
|
|
|
o Here-documents within $(...) command substitutions may once more be
|
|
delimited by the closing right paren, instead of requiring a newline.
|
|
|
|
o Bash's file status checks (executable, readable, etc.) now take file
|
|
system ACLs into account on file systems that support them.
|
|
|
|
o Bash now passes environment variables with names that are not valid
|
|
shell variable names through into the environment passed to child
|
|
processes.
|
|
|
|
o The `execute-unix-command' readline function now attempts to clear and
|
|
reuse the current line rather than move to a new one after the command
|
|
executes.
|
|
|
|
o `printf -v' can now assign values to array indices.
|
|
|
|
o New `complete -E' and `compopt -E' options that work on the "empty"
|
|
completion: completion attempted on an empty command line.
|
|
|
|
o New complete/compgen/compopt -D option to define a `default' completion:
|
|
a completion to be invoked on command for which no completion has been
|
|
defined. If this function returns 124, programmable completion is
|
|
attempted again, allowing a user to dynamically build a set of completions
|
|
as completion is attempted by having the default completion function
|
|
install individual completion functions each time it is invoked.
|
|
|
|
o When displaying associative arrays, subscripts are now quoted.
|
|
|
|
o Changes to dabbrev-expand to make it more `emacs-like': no space appended
|
|
after matches, completions are not sorted, and most recent history entries
|
|
are presented first.
|
|
|
|
o The [[ and (( commands are now subject to the setting of `set -e' and the
|
|
ERR trap.
|
|
|
|
o The source/. builtin now removes NUL bytes from the file before attempting
|
|
to parse commands.
|
|
|
|
o There is a new configuration option (in config-top.h) that forces bash to
|
|
forward all history entries to syslog.
|
|
|
|
o A new variable $BASHOPTS to export shell options settable using `shopt' to
|
|
child processes.
|
|
|
|
o There is a new configure option that forces the extglob option to be
|
|
enabled by default.
|
|
|
|
o New variable $BASH_XTRACEFD; when set to an integer bash will write xtrace
|
|
output to that file descriptor.
|
|
|
|
o If the optional left-hand-side of a redirection is of the form {var}, the
|
|
shell assigns the file descriptor used to $var or uses $var as the file
|
|
descriptor to move or close, depending on the redirection operator.
|
|
|
|
o The < and > operators to the [[ conditional command now do string
|
|
comparison according to the current locale.
|
|
|
|
o Programmable completion now uses the completion for `b' instead of `a'
|
|
when completion is attempted on a line like: a $(b c.
|
|
|
|
o Force extglob on temporarily when parsing the pattern argument to
|
|
the == and != operators to the [[ command, for compatibility.
|
|
|
|
o Changed the behavior of interrupting the wait builtin when a SIGCHLD is
|
|
received and a trap on SIGCHLD is set to be Posix-mode only.
|
|
|
|
o The read builtin has a new `-N nchars' option, which reads exactly NCHARS
|
|
characters, ignoring delimiters like newline.
|
|
|
|
o The mapfile/readarray builtin no longer stores the commands it invokes via
|
|
callbacks in the history list.
|
|
|
|
o There is a new `compat40' shopt option.
|
|
|
|
o The < and > operators to [[ do string comparisons using the current locale
|
|
only if the compatibility level is greater than 40 (set to 41 by default).
|
|
|
|
o New bindable readline function: menu-complete-backward.
|
|
|
|
o In the readline vi-mode insertion keymap, C-n is now bound to menu-complete
|
|
by default, and C-p to menu-complete-backward.
|
|
|
|
o When in readline vi command mode, repeatedly hitting ESC now does nothing,
|
|
even when ESC introduces a bound key sequence. This is closer to how
|
|
historical vi behaves.
|
|
|
|
o New bindable readline function: skip-csi-sequence. Can be used as a
|
|
default to consume key sequences generated by keys like Home and End
|
|
without having to bind all keys.
|
|
|
|
o New bindable readline variable: skip-completed-text, active when
|
|
completing in the middle of a word. If enabled, it means that characters
|
|
in the completion that match characters in the remainder of the word are
|
|
"skipped" rather than inserted into the line.
|
|
|
|
o The pre-readline-6.0 version of menu completion is available as
|
|
"old-menu-complete" for users who do not like the readline-6.0 version.
|
|
|
|
o New bindable readline variable: echo-control-characters. If enabled, and
|
|
the tty ECHOCTL bit is set, controls the echoing of characters
|
|
corresponding to keyboard-generated signals.
|
|
|
|
o New bindable readline variable: enable-meta-key. Controls whether or not
|
|
readline sends the smm/rmm sequences if the terminal indicates it has a
|
|
meta key that enables eight-bit characters.
|
|
|
|
Bash-4.0 contained the following new features:
|
|
|
|
o When using substring expansion on the positional parameters, a starting
|
|
index of 0 now causes $0 to be prefixed to the list.
|
|
|
|
o There is a new variable, $BASHPID, which always returns the process id of
|
|
the current shell.
|
|
|
|
o There is a new `autocd' option that, when enabled, causes bash to attempt
|
|
to `cd' to a directory name that is supplied as the first word of a
|
|
simple command.
|
|
|
|
o There is a new `checkjobs' option that causes the shell to check for and
|
|
report any running or stopped jobs at exit.
|
|
|
|
o The programmable completion code exports a new COMP_TYPE variable, set to
|
|
a character describing the type of completion being attempted.
|
|
|
|
o The programmable completion code exports a new COMP_KEY variable, set to
|
|
the character that caused the completion to be invoked (e.g., TAB).
|
|
|
|
o The programmable completion code now uses the same set of characters as
|
|
readline when breaking the command line into a list of words.
|
|
|
|
o The block multiplier for the ulimit -c and -f options is now 512 when in
|
|
Posix mode, as Posix specifies.
|
|
|
|
o Changed the behavior of the read builtin to save any partial input received
|
|
in the specified variable when the read builtin times out. This also
|
|
results in variables specified as arguments to read to be set to the empty
|
|
string when there is no input available. When the read builtin times out,
|
|
it returns an exit status greater than 128.
|
|
|
|
o The shell now has the notion of a `compatibility level', controlled by
|
|
new variables settable by `shopt'. Setting this variable currently
|
|
restores the bash-3.1 behavior when processing quoted strings on the rhs
|
|
of the `=~' operator to the `[[' command.
|
|
|
|
o The `ulimit' builtin now has new -b (socket buffer size) and -T (number
|
|
of threads) options.
|
|
|
|
o There is a new `compopt' builtin that allows completion functions to modify
|
|
completion options for existing completions or the completion currently
|
|
being executed.
|
|
|
|
o The `read' builtin has a new -i option which inserts text into the reply
|
|
buffer when using readline.
|
|
|
|
o A new `-E' option to the complete builtin allows control of the default
|
|
behavior for completion on an empty line.
|
|
|
|
o There is now limited support for completing command name words containing
|
|
globbing characters.
|
|
|
|
o The `help' builtin now has a new -d option, to display a short description,
|
|
and a -m option, to print help information in a man page-like format.
|
|
|
|
o There is a new `mapfile' builtin to populate an array with lines from a
|
|
given file.
|
|
|
|
o If a command is not found, the shell attempts to execute a shell function
|
|
named `command_not_found_handle', supplying the command words as the
|
|
function arguments.
|
|
|
|
o There is a new shell option: `globstar'. When enabled, the globbing code
|
|
treats `**' specially -- it matches all directories (and files within
|
|
them, when appropriate) recursively.
|
|
|
|
o There is a new shell option: `dirspell'. When enabled, the filename
|
|
completion code performs spelling correction on directory names during
|
|
completion.
|
|
|
|
o The `-t' option to the `read' builtin now supports fractional timeout
|
|
values.
|
|
|
|
o Brace expansion now allows zero-padding of expanded numeric values and
|
|
will add the proper number of zeroes to make sure all values contain the
|
|
same number of digits.
|
|
|
|
o There is a new bash-specific bindable readline function: `dabbrev-expand'.
|
|
It uses menu completion on a set of words taken from the history list.
|
|
|
|
o The command assigned to a key sequence with `bind -x' now sets two new
|
|
variables in the environment of the executed command: READLINE_LINE_BUFFER
|
|
and READLINE_POINT. The command can change the current readline line
|
|
and cursor position by modifying READLINE_LINE_BUFFER and READLINE_POINT,
|
|
respectively.
|
|
|
|
o There is a new >>& redirection operator, which appends the standard output
|
|
and standard error to the named file.
|
|
|
|
o The parser now understands `|&' as a synonym for `2>&1 |', which redirects
|
|
the standard error for a command through a pipe.
|
|
|
|
o The new `;&' case statement action list terminator causes execution to
|
|
continue with the action associated with the next pattern in the
|
|
statement rather than terminating the command.
|
|
|
|
o The new `;;&' case statement action list terminator causes the shell to
|
|
test the next set of patterns after completing execution of the current
|
|
action, rather than terminating the command.
|
|
|
|
o The shell understands a new variable: PROMPT_DIRTRIM. When set to an
|
|
integer value greater than zero, prompt expansion of \w and \W will
|
|
retain only that number of trailing pathname components and replace
|
|
the intervening characters with `...'.
|
|
|
|
o There are new case-modifying word expansions: uppercase (^[^]) and
|
|
lowercase (,[,]). They can work on either the first character or
|
|
array element, or globally. They accept an optional shell pattern
|
|
that determines which characters to modify. There is an optionally-
|
|
configured feature to include capitalization operators.
|
|
|
|
o The shell provides associative array variables, with the appropriate
|
|
support to create, delete, assign values to, and expand them.
|
|
|
|
o The `declare' builtin now has new -l (convert value to lowercase upon
|
|
assignment) and -u (convert value to uppercase upon assignment) options.
|
|
There is an optionally-configurable -c option to capitalize a value at
|
|
assignment.
|
|
|
|
o There is a new `coproc' reserved word that specifies a coprocess: an
|
|
asynchronous command run with two pipes connected to the creating shell.
|
|
Coprocs can be named. The input and output file descriptors and the
|
|
PID of the coprocess are available to the calling shell in variables
|
|
with coproc-specific names.
|
|
|
|
o A value of 0 for the -t option to `read' now returns success if there is
|
|
input available to be read from the specified file descriptor.
|
|
|
|
o CDPATH and GLOBIGNORE are ignored when the shell is running in privileged
|
|
mode.
|
|
|
|
o New bindable readline functions shell-forward-word and shell-backward-word,
|
|
which move forward and backward words delimited by shell metacharacters
|
|
and honor shell quoting.
|
|
|
|
o New bindable readline functions shell-backward-kill-word and shell-kill-word
|
|
which kill words backward and forward, but use the same word boundaries
|
|
as shell-forward-word and shell-backward-word.
|
|
|
|
Bash-3.2 contained the following new features:
|
|
|
|
o Bash-3.2 now checks shell scripts for NUL characters rather than non-printing
|
|
characters when deciding whether or not a script is a binary file.
|
|
|
|
o Quoting the string argument to the [[ command's =~ (regexp) operator now
|
|
forces string matching, as with the other pattern-matching operators.
|
|
|
|
Bash-3.1 contained the following new features:
|
|
|
|
o Bash-3.1 may now be configured and built in a mode that enforces strict
|
|
POSIX compliance.
|
|
|
|
o The `+=' assignment operator, which appends to the value of a string or
|
|
array variable, has been implemented.
|
|
|
|
o It is now possible to ignore case when matching in contexts other than
|
|
filename generation using the new `nocasematch' shell option.
|
|
|
|
Bash-3.0 contained the following new features:
|
|
|
|
o Features to support the bash debugger have been implemented, and there
|
|
is a new `extdebug' option to turn the non-default options on
|
|
|
|
o HISTCONTROL is now a colon-separated list of options and has been
|
|
extended with a new `erasedups' option that will result in only one
|
|
copy of a command being kept in the history list
|
|
|
|
o Brace expansion has been extended with a new {x..y} form, producing
|
|
sequences of digits or characters
|
|
|
|
o Timestamps are now kept with history entries, with an option to save
|
|
and restore them from the history file; there is a new HISTTIMEFORMAT
|
|
variable describing how to display the timestamps when listing history
|
|
entries
|
|
|
|
o The `[[' command can now perform extended regular expression (egrep-like)
|
|
matching, with matched subexpressions placed in the BASH_REMATCH array
|
|
variable
|
|
|
|
o A new `pipefail' option causes a pipeline to return a failure status if
|
|
any command in it fails
|
|
|
|
o The `jobs', `kill', and `wait' builtins now accept job control notation
|
|
in their arguments even if job control is not enabled
|
|
|
|
o The `gettext' package and libintl have been integrated, and the shell
|
|
messages may be translated into other languages
|
|
|
|
Bash-2.05b introduced the following new features:
|
|
|
|
o support for multibyte characters has been added to both bash and readline
|
|
|
|
o the DEBUG trap is now run *before* simple commands, ((...)) commands,
|
|
[[...]] conditional commands, and for ((...)) loops
|
|
|
|
o the shell now performs arithmetic in the largest integer size the machine
|
|
supports (intmax_t)
|
|
|
|
o there is a new \D{...} prompt expansion; passes the `...' to strftime(3)
|
|
and inserts the result into the expanded prompt
|
|
|
|
o there is a new `here-string' redirection operator: <<< word
|
|
|
|
o when displaying variables, function attributes and definitions are shown
|
|
separately, allowing them to be re-used as input (attempting to re-use
|
|
the old output would result in syntax errors).
|
|
|
|
o `read' has a new `-u fd' option to read from a specified file descriptor
|
|
|
|
o the bash debugger in examples/bashdb has been modified to work with the
|
|
new DEBUG trap semantics, the command set has been made more gdb-like,
|
|
and the changes to $LINENO make debugging functions work better
|
|
|
|
o the expansion of $LINENO inside a shell function is only relative to the
|
|
function start if the shell is interactive -- if the shell is running a
|
|
script, $LINENO expands to the line number in the script. This is as
|
|
POSIX-2001 requires
|
|
|
|
Bash-2.05a introduced the following new features:
|
|
|
|
o The `printf' builtin has undergone major work
|
|
|
|
o There is a new read-only `shopt' option: login_shell, which is set by
|
|
login shells and unset otherwise
|
|
|
|
o New `\A' prompt string escape sequence; expanding to time in 24-hour
|
|
HH:MM format
|
|
|
|
o New `-A group/-g' option to complete and compgen; goes group name
|
|
completion
|
|
|
|
o New [+-]O invocation option to set and unset `shopt' options at startup
|
|
|
|
o ksh-like `ERR' trap
|
|
|
|
o `for' loops now allow empty word lists after the `in' reserved word
|
|
|
|
o new `hard' and `soft' arguments for the `ulimit' builtin
|
|
|
|
o Readline can be configured to place the user at the same point on the line
|
|
when retrieving commands from the history list
|
|
|
|
o Readline can be configured to skip `hidden' files (filenames with a leading
|
|
`.' on Unix) when performing completion
|
|
|
|
Bash-2.05 introduced the following new features:
|
|
|
|
o This version has once again reverted to using locales and strcoll(3) when
|
|
processing pattern matching bracket expressions, as POSIX requires.
|
|
o Added a new `--init-file' invocation argument as a synonym for `--rcfile',
|
|
per the new GNU coding standards.
|
|
o The /dev/tcp and /dev/udp redirections now accept service names as well as
|
|
port numbers.
|
|
o `complete' and `compgen' now take a `-o value' option, which controls some
|
|
of the aspects of that compspec. Valid values are:
|
|
|
|
default - perform bash default completion if programmable
|
|
completion produces no matches
|
|
dirnames - perform directory name completion if programmable
|
|
completion produces no matches
|
|
filenames - tell readline that the compspec produces filenames,
|
|
so it can do things like append slashes to
|
|
directory names and suppress trailing spaces
|
|
o A new loadable builtin, realpath, which canonicalizes and expands symlinks
|
|
in pathname arguments.
|
|
o When `set' is called without options, it prints function definitions in a
|
|
way that allows them to be reused as input. This affects `declare' and
|
|
`declare -p' as well. This only happens when the shell is not in POSIX
|
|
mode, since POSIX.2 forbids this behavior.
|
|
|
|
Bash-2.04 introduced the following new features:
|
|
|
|
o Programmable word completion with the new `complete' and `compgen' builtins;
|
|
examples are provided in examples/complete/complete-examples
|
|
o `history' has a new `-d' option to delete a history entry
|
|
o `bind' has a new `-x' option to bind key sequences to shell commands
|
|
o The prompt expansion code has new `\j' and `\l' escape sequences
|
|
o The `no_empty_cmd_completion' shell option, if enabled, inhibits
|
|
command completion when TAB is typed on an empty line
|
|
o `help' has a new `-s' option to print a usage synopsis
|
|
o New arithmetic operators: var++, var--, ++var, --var, expr1,expr2 (comma)
|
|
o New ksh93-style arithmetic for command:
|
|
for ((expr1 ; expr2; expr3 )); do list; done
|
|
o `read' has new options: `-t', `-n', `-d', `-s'
|
|
o The redirection code handles several filenames specially: /dev/fd/N,
|
|
/dev/stdin, /dev/stdout, /dev/stderr
|
|
o The redirection code now recognizes /dev/tcp/HOST/PORT and
|
|
/dev/udp/HOST/PORT and tries to open a TCP or UDP socket, respectively,
|
|
to the specified port on the specified host
|
|
o The ${!prefix*} expansion has been implemented
|
|
o A new FUNCNAME variable, which expands to the name of a currently-executing
|
|
function
|
|
o The GROUPS variable is no longer readonly
|
|
o A new shopt `xpg_echo' variable, to control the behavior of echo with
|
|
respect to backslash-escape sequences at runtime
|
|
o The NON_INTERACTIVE_LOGIN_SHELLS #define has returned
|
|
|
|
The version of Readline released with Bash-2.04, Readline-4.1, had several
|
|
new features as well:
|
|
|
|
o Parentheses matching is always compiled into readline, and controllable
|
|
with the new `blink-matching-paren' variable
|
|
o The history-search-forward and history-search-backward functions now leave
|
|
point at the end of the line when the search string is empty, like
|
|
reverse-search-history, and forward-search-history
|
|
o A new function for applications: rl_on_new_line_with_prompt()
|
|
o New variables for applications: rl_already_prompted, and rl_gnu_readline_p
|
|
|
|
|
|
Bash-2.03 had very few new features, in keeping with the convention
|
|
that odd-numbered releases provide mainly bug fixes. A number of new
|
|
features were added to Readline, mostly at the request of the Cygnus
|
|
folks.
|
|
|
|
A new shopt option, `restricted_shell', so that startup files can test
|
|
whether or not the shell was started in restricted mode
|
|
Filename generation is now performed on the words between ( and ) in
|
|
compound array assignments (this is really a bug fix)
|
|
OLDPWD is now auto-exported, as POSIX.2 requires
|
|
ENV and BASH_ENV are read-only variables in a restricted shell
|
|
Bash may now be linked against an already-installed Readline library,
|
|
as long as the Readline library is version 4 or newer
|
|
All shells begun with the `--login' option will source the login shell
|
|
startup files, even if the shell is not interactive
|
|
|
|
There were lots of changes to the version of the Readline library released
|
|
along with Bash-2.03. For a complete list of the changes, read the file
|
|
CHANGES in the Bash-2.03 distribution.
|
|
|
|
Bash-2.02 contained the following new features:
|
|
|
|
a new version of malloc (based on the old GNU malloc code in previous
|
|
bash versions) that is more page-oriented, more conservative
|
|
with memory usage, does not `orphan' large blocks when they
|
|
are freed, is usable on 64-bit machines, and has allocation
|
|
checking turned on unconditionally
|
|
POSIX.2-style globbing character classes ([:alpha:], [:alnum:], etc.)
|
|
POSIX.2-style globbing equivalence classes
|
|
POSIX.2-style globbing collating symbols
|
|
the ksh [[...]] extended conditional command
|
|
the ksh egrep-style extended pattern matching operators
|
|
a new `printf' builtin
|
|
the ksh-like $(<filename) command substitution, which is equivalent to
|
|
$(cat filename)
|
|
new tilde prefixes that expand to directories from the directory stack
|
|
new `**' arithmetic operator to do exponentiation
|
|
case-insensitive globbing (filename expansion)
|
|
menu completion a la tcsh
|
|
`magic-space' history expansion function like tcsh
|
|
the readline inputrc `language' has a new file inclusion directive ($include)
|
|
|
|
Bash-2.01 contained only a few new features:
|
|
|
|
new `GROUPS' builtin array variable containing the user's group list
|
|
new bindable readline commands: history-and-alias-expand-line and
|
|
alias-expand-line
|
|
|
|
Bash-2.0 contained extensive changes and new features from bash-1.14.7.
|
|
Here's a short list:
|
|
|
|
new `time' reserved word to time pipelines, shell builtins, and
|
|
shell functions
|
|
one-dimensional arrays with a new compound assignment statement,
|
|
appropriate expansion constructs and modifications to some
|
|
of the builtins (read, declare, etc.) to use them
|
|
new quoting syntaxes for ANSI-C string expansion and locale-specific
|
|
string translation
|
|
new expansions to do substring extraction, pattern replacement, and
|
|
indirect variable expansion
|
|
new builtins: `disown' and `shopt'
|
|
new variables: HISTIGNORE, SHELLOPTS, PIPESTATUS, DIRSTACK, GLOBIGNORE,
|
|
MACHTYPE, BASH_VERSINFO
|
|
special handling of many unused or redundant variables removed
|
|
(e.g., $notify, $glob_dot_filenames, $no_exit_on_failed_exec)
|
|
dynamic loading of new builtin commands; many loadable examples provided
|
|
new prompt expansions: \a, \e, \n, \H, \T, \@, \v, \V
|
|
history and aliases available in shell scripts
|
|
new readline variables: enable-keypad, mark-directories, input-meta,
|
|
visible-stats, disable-completion, comment-begin
|
|
new readline commands to manipulate the mark and operate on the region
|
|
new readline emacs mode commands and bindings for ksh-88 compatibility
|
|
updated and extended builtins
|
|
new DEBUG trap
|
|
expanded (and now documented) restricted shell mode
|
|
|
|
implementation stuff:
|
|
autoconf-based configuration
|
|
nearly all of the bugs reported since version 1.14 have been fixed
|
|
most builtins converted to use builtin `getopt' for consistency
|
|
most builtins use -p option to display output in a reusable form
|
|
(for consistency)
|
|
grammar tighter and smaller (66 reduce-reduce conflicts gone)
|
|
lots of code now smaller and faster
|
|
test suite greatly expanded
|
|
|
|
B2) Are there any user-visible incompatibilities between bash-4.3 and
|
|
previous bash versions?
|
|
|
|
There are a few incompatibilities between version 4.3 and previous
|
|
versions. They are detailed in the file COMPAT in the bash distribution.
|
|
That file is not meant to be all-encompassing; send mail to
|
|
bash-maintainers@gnu.org (or bug-bash@gnu.org if you would like
|
|
community discussion) if you find something that's not mentioned there.
|
|
|
|
Section C: Differences from other Unix shells
|
|
|
|
C1) How does bash differ from sh, the Bourne shell?
|
|
|
|
This is a non-comprehensive list of features that differentiate bash
|
|
from the SVR4.2 shell. The bash manual page explains these more
|
|
completely.
|
|
|
|
Things bash has that sh does not:
|
|
long invocation options
|
|
[+-]O invocation option
|
|
-l invocation option
|
|
`!' reserved word to invert pipeline return value
|
|
`time' reserved word to time pipelines and shell builtins
|
|
the `function' reserved word
|
|
the `select' compound command and reserved word
|
|
arithmetic for command: for ((expr1 ; expr2; expr3 )); do list; done
|
|
new $'...' and $"..." quoting
|
|
the $(...) form of command substitution
|
|
the $(<filename) form of command substitution, equivalent to
|
|
$(cat filename)
|
|
the ${#param} parameter value length operator
|
|
the ${!param} indirect parameter expansion operator
|
|
the ${!param*} prefix expansion operator
|
|
the ${param:offset[:length]} parameter substring operator
|
|
the ${param/pat[/string]} parameter pattern substitution operator
|
|
expansions to perform substring removal (${p%[%]w}, ${p#[#]w})
|
|
expansion of positional parameters beyond $9 with ${num}
|
|
variables: BASH, BASHPID, BASH_VERSION, BASH_VERSINFO, UID, EUID, REPLY,
|
|
TIMEFORMAT, PPID, PWD, OLDPWD, SHLVL, RANDOM, SECONDS,
|
|
LINENO, HISTCMD, HOSTTYPE, OSTYPE, MACHTYPE, HOSTNAME,
|
|
ENV, PS3, PS4, DIRSTACK, PIPESTATUS, HISTSIZE, HISTFILE,
|
|
HISTFILESIZE, HISTCONTROL, HISTIGNORE, GLOBIGNORE, GROUPS,
|
|
PROMPT_COMMAND, FCEDIT, FIGNORE, IGNOREEOF, INPUTRC,
|
|
SHELLOPTS, OPTERR, HOSTFILE, TMOUT, FUNCNAME, histchars,
|
|
auto_resume, PROMPT_DIRTRIM, BASHOPTS, BASH_XTRACEFD
|
|
DEBUG trap
|
|
ERR trap
|
|
variable arrays with new compound assignment syntax
|
|
redirections: <>, &>, >|, <<<, [n]<&word-, [n]>&word-, >>&
|
|
prompt string special char translation and variable expansion
|
|
auto-export of variables in initial environment
|
|
command search finds functions before builtins
|
|
bash return builtin will exit a file sourced with `.'
|
|
builtins: cd -/-L/-P/-@, exec -l/-c/-a, echo -e/-E, hash -d/-l/-p/-t.
|
|
export -n/-f/-p/name=value, pwd -L/-P,
|
|
read -e/-p/-a/-t/-n/-d/-s/-u/-i/-N,
|
|
readonly -a/-f/name=value, trap -l, set +o,
|
|
set -b/-m/-o option/-h/-p/-B/-C/-H/-P,
|
|
unset -f/-n/-v, ulimit -i/-m/-p/-q/-u/-x,
|
|
type -a/-p/-t/-f/-P, suspend -f, kill -n,
|
|
test -o optname/s1 == s2/s1 < s2/s1 > s2/-nt/-ot/-ef/-O/-G/-S/-R
|
|
bash reads ~/.bashrc for interactive shells, $ENV for non-interactive
|
|
bash restricted shell mode is more extensive
|
|
bash allows functions and variables with the same name
|
|
brace expansion
|
|
tilde expansion
|
|
arithmetic expansion with $((...)) and `let' builtin
|
|
the `[[...]]' extended conditional command
|
|
process substitution
|
|
aliases and alias/unalias builtins
|
|
local variables in functions and `local' builtin
|
|
readline and command-line editing with programmable completion
|
|
command history and history/fc builtins
|
|
csh-like history expansion
|
|
other new bash builtins: bind, command, compgen, complete, builtin,
|
|
declare/typeset, dirs, enable, fc, help,
|
|
history, logout, popd, pushd, disown, shopt,
|
|
printf, compopt, mapfile
|
|
exported functions
|
|
filename generation when using output redirection (command >a*)
|
|
POSIX.2-style globbing character classes
|
|
POSIX.2-style globbing equivalence classes
|
|
POSIX.2-style globbing collating symbols
|
|
egrep-like extended pattern matching operators
|
|
case-insensitive pattern matching and globbing
|
|
variable assignments preceding commands affect only that command,
|
|
even for builtins and functions
|
|
posix mode and strict posix conformance
|
|
redirection to /dev/fd/N, /dev/stdin, /dev/stdout, /dev/stderr,
|
|
/dev/tcp/host/port, /dev/udp/host/port
|
|
debugger support, including `caller' builtin and new variables
|
|
RETURN trap
|
|
the `+=' assignment operator
|
|
autocd shell option and behavior
|
|
command-not-found hook with command_not_found_handle shell function
|
|
globstar shell option and `**' globbing behavior
|
|
|& synonym for `2>&1 |'
|
|
;& and ;;& case action list terminators
|
|
case-modifying word expansions and variable attributes
|
|
associative arrays
|
|
coprocesses using the `coproc' reserved word and variables
|
|
shell assignment of a file descriptor used in a redirection to a variable
|
|
|
|
Things sh has that bash does not:
|
|
uses variable SHACCT to do shell accounting
|
|
includes `stop' builtin (bash can use alias stop='kill -s STOP')
|
|
`newgrp' builtin
|
|
turns on job control if called as `jsh'
|
|
$TIMEOUT (like bash $TMOUT)
|
|
`^' is a synonym for `|'
|
|
new SVR4.2 sh builtins: mldmode, priv
|
|
|
|
Implementation differences:
|
|
redirection to/from compound commands causes sh to create a subshell
|
|
bash does not allow unbalanced quotes; sh silently inserts them at EOF
|
|
bash does not mess with signal 11
|
|
sh sets (euid, egid) to (uid, gid) if -p not supplied and uid < 100
|
|
bash splits only the results of expansions on IFS, using POSIX.2
|
|
field splitting rules; sh splits all words on IFS
|
|
sh does not allow MAILCHECK to be unset (?)
|
|
sh does not allow traps on SIGALRM or SIGCHLD
|
|
bash allows multiple option arguments when invoked (e.g. -x -v);
|
|
sh allows only a single option argument (`sh -x -v' attempts
|
|
to open a file named `-v', and, on SunOS 4.1.4, dumps core.
|
|
On Solaris 2.4 and earlier versions, sh goes into an infinite
|
|
loop.)
|
|
sh exits a script if any builtin fails; bash exits only if one of
|
|
the POSIX.2 `special' builtins fails
|
|
|
|
C2) How does bash differ from the Korn shell, version ksh88?
|
|
|
|
Things bash has or uses that ksh88 does not:
|
|
long invocation options
|
|
[-+]O invocation option
|
|
-l invocation option
|
|
`!' reserved word
|
|
arithmetic for command: for ((expr1 ; expr2; expr3 )); do list; done
|
|
arithmetic in largest machine-supported size (intmax_t)
|
|
posix mode and posix conformance
|
|
command hashing
|
|
tilde expansion for assignment statements that look like $PATH
|
|
process substitution with named pipes if /dev/fd is not available
|
|
the ${!param} indirect parameter expansion operator
|
|
the ${!param*} prefix expansion operator
|
|
the ${param:offset[:length]} parameter substring operator
|
|
the ${param/pat[/string]} parameter pattern substitution operator
|
|
variables: BASH, BASH_VERSION, BASH_VERSINFO, BASHPID, UID, EUID, SHLVL,
|
|
TIMEFORMAT, HISTCMD, HOSTTYPE, OSTYPE, MACHTYPE,
|
|
HISTFILESIZE, HISTIGNORE, HISTCONTROL, PROMPT_COMMAND,
|
|
IGNOREEOF, FIGNORE, INPUTRC, HOSTFILE, DIRSTACK,
|
|
PIPESTATUS, HOSTNAME, OPTERR, SHELLOPTS, GLOBIGNORE,
|
|
GROUPS, FUNCNAME, histchars, auto_resume, PROMPT_DIRTRIM
|
|
prompt expansion with backslash escapes and command substitution
|
|
redirection: &> (stdout and stderr), <<<, [n]<&word-, [n]>&word-, >>&
|
|
more extensive and extensible editing and programmable completion
|
|
builtins: bind, builtin, command, declare, dirs, echo -e/-E, enable,
|
|
exec -l/-c/-a, fc -s, export -n/-f/-p, hash, help, history,
|
|
jobs -x/-r/-s, kill -s/-n/-l, local, logout, popd, pushd,
|
|
read -e/-p/-a/-t/-n/-d/-s/-N, readonly -a/-n/-f/-p,
|
|
set -o braceexpand/-o histexpand/-o interactive-comments/
|
|
-o notify/-o physical/-o posix/-o hashall/-o onecmd/
|
|
-h/-B/-C/-b/-H/-P, set +o, suspend, trap -l, type,
|
|
typeset -a/-F/-p, ulimit -i/-q/-u/-x, umask -S, alias -p,
|
|
shopt, disown, printf, complete, compgen, compopt, mapfile
|
|
`!' csh-style history expansion
|
|
POSIX.2-style globbing character classes
|
|
POSIX.2-style globbing equivalence classes
|
|
POSIX.2-style globbing collating symbols
|
|
egrep-like extended pattern matching operators
|
|
case-insensitive pattern matching and globbing
|
|
`**' arithmetic operator to do exponentiation
|
|
redirection to /dev/fd/N, /dev/stdin, /dev/stdout, /dev/stderr
|
|
arrays of unlimited size
|
|
TMOUT is default timeout for `read' and `select'
|
|
debugger support, including the `caller' builtin
|
|
RETURN trap
|
|
Timestamps in history entries
|
|
{x..y} brace expansion
|
|
The `+=' assignment operator
|
|
autocd shell option and behavior
|
|
command-not-found hook with command_not_found_handle shell function
|
|
globstar shell option and `**' globbing behavior
|
|
|& synonym for `2>&1 |'
|
|
;& and ;;& case action list terminators
|
|
case-modifying word expansions and variable attributes
|
|
associative arrays
|
|
coprocesses using the `coproc' reserved word and variables
|
|
shell assignment of a file descriptor used in a redirection to a variable
|
|
|
|
Things ksh88 has or uses that bash does not:
|
|
tracked aliases (alias -t)
|
|
variables: ERRNO, FPATH, EDITOR, VISUAL
|
|
co-processes (bash uses different syntax)
|
|
weirdly-scoped functions
|
|
typeset +f to list all function names without definitions
|
|
text of command history kept in a file, not memory
|
|
builtins: alias -x, cd old new, newgrp, print,
|
|
read -p/-s/var?prompt, set -A/-o gmacs/
|
|
-o bgnice/-o markdirs/-o trackall/-o viraw/-s,
|
|
typeset -H/-L/-R/-Z/-A/-ft/-fu/-fx/-t, whence
|
|
using environment to pass attributes of exported variables
|
|
arithmetic evaluation done on arguments to some builtins
|
|
reads .profile from $PWD when invoked as login shell
|
|
|
|
Implementation differences:
|
|
ksh runs last command of a pipeline in parent shell context
|
|
bash has brace expansion by default (ksh88 compile-time option)
|
|
bash has fixed startup file for all interactive shells; ksh reads $ENV
|
|
bash has exported functions
|
|
bash command search finds functions before builtins
|
|
bash waits for all commands in pipeline to exit before returning status
|
|
emacs-mode editing has some slightly different key bindings
|
|
|
|
C3) Which new features in ksh-93 are not in bash, and which are?
|
|
|
|
This list is current through ksh93v (10/08/2013)
|
|
|
|
New things in ksh-93 not in bash-4.3:
|
|
floating point arithmetic, variables, and constants
|
|
math library functions, including user-defined math functions
|
|
${!name[sub]} name of subscript for associative array
|
|
`.' is allowed in variable names to create a hierarchical namespace
|
|
more extensive compound assignment syntax
|
|
discipline functions
|
|
KEYBD trap
|
|
variables: .sh.edchar, .sh.edmode, .sh.edcol, .sh.edtext, .sh.version,
|
|
.sh.name, .sh.subscript, .sh.value, .sh.match, HISTEDIT,
|
|
.sh.sig, .sh.stats, .sh.siginfo, .sh.pwdfd, .sh.op_astbin,
|
|
.sh.pool
|
|
backreferences in pattern matching (\N)
|
|
`&' operator in pattern lists for matching (match all instead of any)
|
|
exit statuses between 0 and 255
|
|
FPATH and PATH mixing
|
|
lexical scoping for local variables in `ksh' functions
|
|
no scoping for local variables in `POSIX' functions
|
|
$'' \C[.collating-element.] escape sequence
|
|
-C/-I invocation options
|
|
print -f (bash uses printf) and rest of print builtin options
|
|
printf %(type)q, %#q
|
|
`fc' has been renamed to `hist'
|
|
`.' can execute shell functions
|
|
getopts -a
|
|
printf %B, %H, %P, %R, %Z modifiers, output base for %d, `=' flag
|
|
read -n/-N differ/-v/-S
|
|
set -o showme/-o multiline (bash default)
|
|
set -K
|
|
kill -Q/-q/-L
|
|
trap -a
|
|
`sleep' and `getconf' builtins (bash has loadable versions)
|
|
[[ -R name ]] (checks whether or not name is a nameref)
|
|
typeset -C/-S/-T/-X/-h/-s/-c/-M
|
|
experimental `type' definitions (a la typedef) using typeset
|
|
array expansions ${array[sub1..sub2]} and ${!array[sub1..sub2]}
|
|
associative array assignments using `;' as element separator
|
|
command substitution $(n<#) expands to current byte offset for fd N
|
|
new '${ ' form of command substitution, executed in current shell
|
|
new >;/<>;/<#pat/<##pat/<#/># redirections
|
|
brace expansion printf-like formats
|
|
CHLD trap triggered by SIGSTOP and SIGCONT
|
|
~{fd} expansion, which replaces fd with the corresponding path name
|
|
$"string" expanded when referenced rather than when first parsed
|
|
job "pools", which allow a collection of jobs to be managed as a unit
|
|
|
|
New things in ksh-93 present in bash-4.3:
|
|
associative arrays
|
|
[n]<&word- and [n]>&word- redirections (combination dup and close)
|
|
for (( expr1; expr2; expr3 )) ; do list; done - arithmetic for command
|
|
?:, ++, --, `expr1 , expr2' arithmetic operators
|
|
expansions: ${!param}, ${param:offset[:len]}, ${param/pat[/str]},
|
|
${!param*}
|
|
compound array assignment
|
|
negative subscripts for indexed array variables
|
|
the `!' reserved word
|
|
loadable builtins -- but ksh uses `builtin' while bash uses `enable'
|
|
new $'...' and $"..." quoting
|
|
FIGNORE (but bash uses GLOBIGNORE), HISTCMD
|
|
brace expansion and set -B
|
|
changes to kill builtin
|
|
`command', `builtin', `disown' builtins
|
|
echo -e
|
|
exec -c/-a
|
|
printf %T modifier
|
|
read -A (bash uses read -a)
|
|
read -t/-d
|
|
trap -p
|
|
`.' restores the positional parameters when it completes
|
|
set -o notify/-C
|
|
set -o pipefail
|
|
set -G (-o globstar) and **
|
|
POSIX.2 `test'
|
|
umask -S
|
|
unalias -a
|
|
command and arithmetic substitution performed on PS1, PS4, and ENV
|
|
command name completion, TAB displaying possible completions
|
|
ENV processed only for interactive shells
|
|
The `+=' assignment operator
|
|
the `;&' case statement "fallthrough" pattern list terminator
|
|
csh-style history expansion and set -H
|
|
negative offsets in ${param:offset:length}
|
|
redirection operators preceded with {varname} to store fd number in varname
|
|
DEBUG can force skipping following command
|
|
[[ -v var ]] operator (checks whether or not var is set)
|
|
typeset -n and `nameref' variables
|
|
process substitutions work without /dev/fd
|
|
|
|
Section D: Why does bash do some things differently than other Unix shells?
|
|
|
|
D1) Why does bash run a different version of `command' than
|
|
`which command' says it will?
|
|
|
|
On many systems, `which' is actually a csh script that assumes
|
|
you're running csh. In tcsh, `which' and its cousin `where'
|
|
are builtins. On other Unix systems, `which' is a perl script
|
|
that uses the PATH environment variable. Many Linux distributions
|
|
use GNU `which', which is a C program that can understand shell
|
|
aliases.
|
|
|
|
The csh script version reads the csh startup files from your
|
|
home directory and uses those to determine which `command' will
|
|
be invoked. Since bash doesn't use any of those startup files,
|
|
there's a good chance that your bash environment differs from
|
|
your csh environment. The bash `type' builtin does everything
|
|
`which' does, and will report correct results for the running
|
|
shell. If you're really wedded to the name `which', try adding
|
|
the following function definition to your .bashrc:
|
|
|
|
which()
|
|
{
|
|
builtin type "$@"
|
|
}
|
|
|
|
If you're moving from tcsh and would like to bring `where' along
|
|
as well, use this function:
|
|
|
|
where()
|
|
{
|
|
builtin type -a "$@"
|
|
}
|
|
|
|
D2) Why doesn't bash treat brace expansions exactly like csh?
|
|
|
|
The only difference between bash and csh brace expansion is that
|
|
bash requires a brace expression to contain at least one unquoted
|
|
comma if it is to be expanded. Any brace-surrounded word not
|
|
containing an unquoted comma is left unchanged by the brace
|
|
expansion code. This affords the greatest degree of sh
|
|
compatibility.
|
|
|
|
Bash, ksh, zsh, and pd-ksh all implement brace expansion this way.
|
|
|
|
D3) Why doesn't bash have csh variable modifiers?
|
|
|
|
Posix has specified a more powerful, albeit somewhat more cryptic,
|
|
mechanism cribbed from ksh, and bash implements it.
|
|
|
|
${parameter%word}
|
|
Remove smallest suffix pattern. The WORD is expanded to produce
|
|
a pattern. It then expands to the value of PARAMETER, with the
|
|
smallest portion of the suffix matched by the pattern deleted.
|
|
|
|
x=file.c
|
|
echo ${x%.c}.o
|
|
-->file.o
|
|
|
|
${parameter%%word}
|
|
|
|
Remove largest suffix pattern. The WORD is expanded to produce
|
|
a pattern. It then expands to the value of PARAMETER, with the
|
|
largest portion of the suffix matched by the pattern deleted.
|
|
|
|
x=posix/src/std
|
|
echo ${x%%/*}
|
|
-->posix
|
|
|
|
${parameter#word}
|
|
Remove smallest prefix pattern. The WORD is expanded to produce
|
|
a pattern. It then expands to the value of PARAMETER, with the
|
|
smallest portion of the prefix matched by the pattern deleted.
|
|
|
|
x=$HOME/src/cmd
|
|
echo ${x#$HOME}
|
|
-->/src/cmd
|
|
|
|
${parameter##word}
|
|
Remove largest prefix pattern. The WORD is expanded to produce
|
|
a pattern. It then expands to the value of PARAMETER, with the
|
|
largest portion of the prefix matched by the pattern deleted.
|
|
|
|
x=/one/two/three
|
|
echo ${x##*/}
|
|
-->three
|
|
|
|
|
|
Given
|
|
a=/a/b/c/d
|
|
b=b.xxx
|
|
|
|
csh bash result
|
|
--- ---- ------
|
|
$a:h ${a%/*} /a/b/c
|
|
$a:t ${a##*/} d
|
|
$b:r ${b%.*} b
|
|
$b:e ${b##*.} xxx
|
|
|
|
|
|
D4) How can I make my csh aliases work when I convert to bash?
|
|
|
|
Bash uses a different syntax to support aliases than csh does.
|
|
The details can be found in the documentation. We have provided
|
|
a shell script which does most of the work of conversion for you;
|
|
this script can be found in ./examples/misc/aliasconv.sh. Here is
|
|
how you use it:
|
|
|
|
Start csh in the normal way for you. (e.g., `csh')
|
|
|
|
Pipe the output of `alias' through `aliasconv.sh', saving the
|
|
results into `bash_aliases':
|
|
|
|
alias | bash aliasconv.sh >bash_aliases
|
|
|
|
Edit `bash_aliases', carefully reading through any created
|
|
functions. You will need to change the names of some csh specific
|
|
variables to the bash equivalents. The script converts $cwd to
|
|
$PWD, $term to $TERM, $home to $HOME, $user to $USER, and $prompt
|
|
to $PS1. You may also have to add quotes to avoid unwanted
|
|
expansion.
|
|
|
|
For example, the csh alias:
|
|
|
|
alias cd 'cd \!*; echo $cwd'
|
|
|
|
is converted to the bash function:
|
|
|
|
cd () { command cd "$@"; echo $PWD ; }
|
|
|
|
The only thing that needs to be done is to quote $PWD:
|
|
|
|
cd () { command cd "$@"; echo "$PWD" ; }
|
|
|
|
Merge the edited file into your ~/.bashrc.
|
|
|
|
There is an additional, more ambitious, script in
|
|
examples/misc/cshtobash that attempts to convert your entire csh
|
|
environment to its bash equivalent. This script can be run as
|
|
simply `cshtobash' to convert your normal interactive
|
|
environment, or as `cshtobash ~/.login' to convert your login
|
|
environment.
|
|
|
|
D5) How can I pipe standard output and standard error from one command to
|
|
another, like csh does with `|&'?
|
|
|
|
Use
|
|
command 2>&1 | command2
|
|
|
|
The key is to remember that piping is performed before redirection, so
|
|
file descriptor 1 points to the pipe when it is duplicated onto file
|
|
descriptor 2.
|
|
|
|
D6) Now that I've converted from ksh to bash, are there equivalents to
|
|
ksh features like autoloaded functions and the `whence' command?
|
|
|
|
There are features in ksh-88 and ksh-93 that do not have direct bash
|
|
equivalents. Most, however, can be emulated with very little trouble.
|
|
|
|
ksh-88 feature Bash equivalent
|
|
-------------- ---------------
|
|
compiled-in aliases set up aliases in .bashrc; some ksh aliases are
|
|
bash builtins (hash, history, type)
|
|
coprocesses named pipe pairs (one for read, one for write)
|
|
typeset +f declare -F
|
|
cd, print, whence function substitutes in examples/functions/kshenv
|
|
autoloaded functions examples/functions/autoload is the same as typeset -fu
|
|
read var?prompt read -p prompt var
|
|
|
|
ksh-93 feature Bash equivalent
|
|
-------------- ---------------
|
|
sleep, getconf Bash has loadable versions in examples/loadables
|
|
${.sh.version} $BASH_VERSION
|
|
print -f printf
|
|
hist alias hist=fc
|
|
$HISTEDIT $FCEDIT
|
|
|
|
Section E: How can I get bash to do certain things, and why does bash do
|
|
things the way it does?
|
|
|
|
E1) Why is the bash builtin `test' slightly different from /bin/test?
|
|
|
|
The specific example used here is [ ! x -o x ], which is false.
|
|
|
|
Bash's builtin `test' implements the Posix.2 spec, which can be
|
|
summarized as follows (the wording is due to David Korn):
|
|
|
|
Here is the set of rules for processing test arguments.
|
|
|
|
0 Args: False
|
|
1 Arg: True iff argument is not null.
|
|
2 Args: If first arg is !, True iff second argument is null.
|
|
If first argument is unary, then true if unary test is true
|
|
Otherwise error.
|
|
3 Args: If second argument is a binary operator, do binary test of $1 $3
|
|
If first argument is !, negate two argument test of $2 $3
|
|
If first argument is `(' and third argument is `)', do the
|
|
one-argument test of the second argument.
|
|
Otherwise error.
|
|
4 Args: If first argument is !, negate three argument test of $2 $3 $4.
|
|
Otherwise unspecified
|
|
5 or more Args: unspecified. (Historical shells would use their
|
|
current algorithm).
|
|
|
|
The operators -a and -o are considered binary operators for the purpose
|
|
of the 3 Arg case.
|
|
|
|
As you can see, the test becomes (not (x or x)), which is false.
|
|
|
|
E2) Why does bash sometimes say `Broken pipe'?
|
|
|
|
If a sequence of commands appears in a pipeline, and one of the
|
|
reading commands finishes before the writer has finished, the
|
|
writer receives a SIGPIPE signal. Many other shells special-case
|
|
SIGPIPE as an exit status in the pipeline and do not report it.
|
|
For example, in:
|
|
|
|
ps -aux | head
|
|
|
|
`head' can finish before `ps' writes all of its output, and ps
|
|
will try to write on a pipe without a reader. In that case, bash
|
|
will print `Broken pipe' to stderr when ps is killed by a
|
|
SIGPIPE.
|
|
|
|
As of bash-3.1, bash does not report SIGPIPE errors by default. You
|
|
can build a version of bash that will report such errors.
|
|
|
|
E3) When I have terminal escape sequences in my prompt, why does bash
|
|
wrap lines at the wrong column?
|
|
|
|
Readline, the line editing library that bash uses, does not know
|
|
that the terminal escape sequences do not take up space on the
|
|
screen. The redisplay code assumes, unless told otherwise, that
|
|
each character in the prompt is a `printable' character that
|
|
takes up one character position on the screen.
|
|
|
|
You can use the bash prompt expansion facility (see the PROMPTING
|
|
section in the manual page) to tell readline that sequences of
|
|
characters in the prompt strings take up no screen space.
|
|
|
|
Use the \[ escape to begin a sequence of non-printing characters,
|
|
and the \] escape to signal the end of such a sequence.
|
|
|
|
E4) If I pipe the output of a command into `read variable', why doesn't
|
|
the output show up in $variable when the read command finishes?
|
|
|
|
This has to do with the parent-child relationship between Unix
|
|
processes. It affects all commands run in pipelines, not just
|
|
simple calls to `read'. For example, piping a command's output
|
|
into a `while' loop that repeatedly calls `read' will result in
|
|
the same behavior.
|
|
|
|
Each element of a pipeline, even a builtin or shell function,
|
|
runs in a separate process, a child of the shell running the
|
|
pipeline. A subprocess cannot affect its parent's environment.
|
|
When the `read' command sets the variable to the input, that
|
|
variable is set only in the subshell, not the parent shell. When
|
|
the subshell exits, the value of the variable is lost.
|
|
|
|
Many pipelines that end with `read variable' can be converted
|
|
into command substitutions, which will capture the output of
|
|
a specified command. The output can then be assigned to a
|
|
variable:
|
|
|
|
grep ^gnu /usr/lib/news/active | wc -l | read ngroup
|
|
|
|
can be converted into
|
|
|
|
ngroup=$(grep ^gnu /usr/lib/news/active | wc -l)
|
|
|
|
This does not, unfortunately, work to split the text among
|
|
multiple variables, as read does when given multiple variable
|
|
arguments. If you need to do this, you can either use the
|
|
command substitution above to read the output into a variable
|
|
and chop up the variable using the bash pattern removal
|
|
expansion operators or use some variant of the following
|
|
approach.
|
|
|
|
Say /usr/local/bin/ipaddr is the following shell script:
|
|
|
|
#! /bin/sh
|
|
host `hostname` | awk '/address/ {print $NF}'
|
|
|
|
Instead of using
|
|
|
|
/usr/local/bin/ipaddr | read A B C D
|
|
|
|
to break the local machine's IP address into separate octets, use
|
|
|
|
OIFS="$IFS"
|
|
IFS=.
|
|
set -- $(/usr/local/bin/ipaddr)
|
|
IFS="$OIFS"
|
|
A="$1" B="$2" C="$3" D="$4"
|
|
|
|
Beware, however, that this will change the shell's positional
|
|
parameters. If you need them, you should save them before doing
|
|
this.
|
|
|
|
This is the general approach -- in most cases you will not need to
|
|
set $IFS to a different value.
|
|
|
|
Some other user-supplied alternatives include:
|
|
|
|
read A B C D << HERE
|
|
$(IFS=.; echo $(/usr/local/bin/ipaddr))
|
|
HERE
|
|
|
|
and, where process substitution is available,
|
|
|
|
read A B C D < <(IFS=.; echo $(/usr/local/bin/ipaddr))
|
|
|
|
E5) I have a bunch of shell scripts that use backslash-escaped characters
|
|
in arguments to `echo'. Bash doesn't interpret these characters. Why
|
|
not, and how can I make it understand them?
|
|
|
|
This is the behavior of echo on most Unix System V machines.
|
|
|
|
The bash builtin `echo' is modeled after the 9th Edition
|
|
Research Unix version of `echo'. It does not interpret
|
|
backslash-escaped characters in its argument strings by default;
|
|
it requires the use of the -e option to enable the
|
|
interpretation. The System V echo provides no way to disable the
|
|
special characters; the bash echo has a -E option to disable
|
|
them.
|
|
|
|
There is a configuration option that will make bash behave like
|
|
the System V echo and interpret things like `\t' by default. Run
|
|
configure with the --enable-xpg-echo-default option to turn this
|
|
on. Be aware that this will cause some of the tests run when you
|
|
type `make tests' to fail.
|
|
|
|
There is a shell option, `xpg_echo', settable with `shopt', that will
|
|
change the behavior of echo at runtime. Enabling this option turns
|
|
on expansion of backslash-escape sequences.
|
|
|
|
E6) Why doesn't a while or for loop get suspended when I type ^Z?
|
|
|
|
This is a consequence of how job control works on Unix. The only
|
|
thing that can be suspended is the process group. This is a single
|
|
command or pipeline of commands that the shell forks and executes.
|
|
|
|
When you run a while or for loop, the only thing that the shell forks
|
|
and executes are any commands in the while loop test and commands in
|
|
the loop bodies. These, therefore, are the only things that can be
|
|
suspended when you type ^Z.
|
|
|
|
If you want to be able to stop the entire loop, you need to put it
|
|
within parentheses, which will force the loop into a subshell that
|
|
may be stopped (and subsequently restarted) as a single unit.
|
|
|
|
E7) What about empty for loops in Makefiles?
|
|
|
|
It's fairly common to see constructs like this in automatically-generated
|
|
Makefiles:
|
|
|
|
SUBDIRS = @SUBDIRS@
|
|
|
|
...
|
|
|
|
subdirs-clean:
|
|
for d in ${SUBDIRS}; do \
|
|
( cd $$d && ${MAKE} ${MFLAGS} clean ) \
|
|
done
|
|
|
|
When SUBDIRS is empty, this results in a command like this being passed to
|
|
bash:
|
|
|
|
for d in ; do
|
|
( cd $d && ${MAKE} ${MFLAGS} clean )
|
|
done
|
|
|
|
In versions of bash before bash-2.05a, this was a syntax error. If the
|
|
reserved word `in' was present, a word must follow it before the semicolon
|
|
or newline. The language in the manual page referring to the list of words
|
|
being empty referred to the list after it is expanded. These versions of
|
|
bash required that there be at least one word following the `in' when the
|
|
construct was parsed.
|
|
|
|
The idiomatic Makefile solution is something like:
|
|
|
|
SUBDIRS = @SUBDIRS@
|
|
|
|
subdirs-clean:
|
|
subdirs=$SUBDIRS ; for d in $$subdirs; do \
|
|
( cd $$d && ${MAKE} ${MFLAGS} clean ) \
|
|
done
|
|
|
|
The latest updated POSIX standard has changed this: the word list
|
|
is no longer required. Bash versions 2.05a and later accept the
|
|
new syntax.
|
|
|
|
E8) Why does the arithmetic evaluation code complain about `08'?
|
|
|
|
The bash arithmetic evaluation code (used for `let', $(()), (()), and in
|
|
other places), interprets a leading `0' in numeric constants as denoting
|
|
an octal number, and a leading `0x' as denoting hexadecimal. This is
|
|
in accordance with the POSIX.2 spec, section 2.9.2.1, which states that
|
|
arithmetic constants should be handled as signed long integers as defined
|
|
by the ANSI/ISO C standard.
|
|
|
|
The POSIX.2 interpretation committee has confirmed this:
|
|
|
|
http://www.pasc.org/interps/unofficial/db/p1003.2/pasc-1003.2-173.html
|
|
|
|
E9) Why does the pattern matching expression [A-Z]* match files beginning
|
|
with every letter except `z'?
|
|
|
|
Bash-2.03, Bash-2.05 and later versions honor the current locale setting
|
|
when processing ranges within pattern matching bracket expressions ([A-Z]).
|
|
This is what POSIX.2 and SUSv3/XPG6 specify.
|
|
|
|
The behavior of the matcher in bash-2.05 and later versions depends on the
|
|
current LC_COLLATE setting. Setting this variable to `C' or `POSIX' will
|
|
result in the traditional behavior ([A-Z] matches all uppercase ASCII
|
|
characters). Many other locales, including the en_US locale (the default
|
|
on many US versions of Linux) collate the upper and lower case letters like
|
|
this:
|
|
|
|
AaBb...Zz
|
|
|
|
which means that [A-Z] matches every letter except `z'. Others collate like
|
|
|
|
aAbBcC...zZ
|
|
|
|
which means that [A-Z] matches every letter except `a'.
|
|
|
|
The portable way to specify upper case letters is [:upper:] instead of
|
|
A-Z; lower case may be specified as [:lower:] instead of a-z.
|
|
|
|
Look at the manual pages for setlocale(3), strcoll(3), and, if it is
|
|
present, locale(1). If you have locale(1), you can use it to find
|
|
your current locale information even if you do not have any of the
|
|
LC_ variables set.
|
|
|
|
My advice is to put
|
|
|
|
export LC_COLLATE=C
|
|
|
|
into /etc/profile and inspect any shell scripts run from cron for
|
|
constructs like [A-Z]. This will prevent things like
|
|
|
|
rm [A-Z]*
|
|
|
|
from removing every file in the current directory except those beginning
|
|
with `z' and still allow individual users to change the collation order.
|
|
Users may put the above command into their own profiles as well, of course.
|
|
|
|
E10) Why does `cd //' leave $PWD as `//'?
|
|
|
|
POSIX.2, in its description of `cd', says that *three* or more leading
|
|
slashes may be replaced with a single slash when canonicalizing the
|
|
current working directory.
|
|
|
|
This is, I presume, for historical compatibility. Certain versions of
|
|
Unix, and early network file systems, used paths of the form
|
|
//hostname/path to access `path' on server `hostname'.
|
|
|
|
E11) If I resize my xterm while another program is running, why doesn't bash
|
|
notice the change?
|
|
|
|
This is another issue that deals with job control.
|
|
|
|
The kernel maintains a notion of a current terminal process group. Members
|
|
of this process group (processes whose process group ID is equal to the
|
|
current terminal process group ID) receive terminal-generated signals like
|
|
SIGWINCH. (For more details, see the JOB CONTROL section of the bash
|
|
man page.)
|
|
|
|
If a terminal is resized, the kernel sends SIGWINCH to each member of
|
|
the terminal's current process group (the `foreground' process group).
|
|
|
|
When bash is running with job control enabled, each pipeline (which may be
|
|
a single command) is run in its own process group, different from bash's
|
|
process group. This foreground process group receives the SIGWINCH; bash
|
|
does not. Bash has no way of knowing that the terminal has been resized.
|
|
|
|
There is a `checkwinsize' option, settable with the `shopt' builtin, that
|
|
will cause bash to check the window size and adjust its idea of the
|
|
terminal's dimensions each time a process stops or exits and returns control
|
|
of the terminal to bash. Enable it with `shopt -s checkwinsize'.
|
|
|
|
E12) Why don't negative offsets in substring expansion work like I expect?
|
|
|
|
When substring expansion of the form ${param:offset[:length} is used,
|
|
an `offset' that evaluates to a number less than zero counts back from
|
|
the end of the expanded value of $param.
|
|
|
|
When a negative `offset' begins with a minus sign, however, unexpected things
|
|
can happen. Consider
|
|
|
|
a=12345678
|
|
echo ${a:-4}
|
|
|
|
intending to print the last four characters of $a. The problem is that
|
|
${param:-word} already has a well-defined meaning: expand to word if the
|
|
expanded value of param is unset or null, and $param otherwise.
|
|
|
|
To use negative offsets that begin with a minus sign, separate the
|
|
minus sign and the colon with a space.
|
|
|
|
E13) Why does filename completion misbehave if a colon appears in the filename?
|
|
|
|
Filename completion (and word completion in general) may appear to behave
|
|
improperly if there is a colon in the word to be completed.
|
|
|
|
The colon is special to readline's word completion code: it is one of the
|
|
characters that breaks words for the completer. Readline uses these characters
|
|
in sort of the same way that bash uses $IFS: they break or separate the words
|
|
the completion code hands to the application-specific or default word
|
|
completion functions. The original intent was to make it easy to edit
|
|
colon-separated lists (such as $PATH in bash) in various applications using
|
|
readline for input.
|
|
|
|
This is complicated by the fact that some versions of the popular
|
|
`bash-completion' programmable completion package have problems with the
|
|
default completion behavior in the presence of colons.
|
|
|
|
The current set of completion word break characters is available in bash as
|
|
the value of the COMP_WORDBREAKS variable. Removing `:' from that value is
|
|
enough to make the colon not special to completion:
|
|
|
|
COMP_WORDBREAKS=${COMP_WORDBREAKS//:}
|
|
|
|
You can also quote the colon with a backslash to achieve the same result
|
|
temporarily.
|
|
|
|
E14) Why does quoting the pattern argument to the regular expression matching
|
|
conditional operator (=~) cause regexp matching to stop working?
|
|
|
|
In versions of bash prior to bash-3.2, the effect of quoting the regular
|
|
expression argument to the [[ command's =~ operator was not specified.
|
|
The practical effect was that double-quoting the pattern argument required
|
|
backslashes to quote special pattern characters, which interfered with the
|
|
backslash processing performed by double-quoted word expansion and was
|
|
inconsistent with how the == shell pattern matching operator treated
|
|
quoted characters.
|
|
|
|
In bash-3.2, the shell was changed to internally quote characters in single-
|
|
and double-quoted string arguments to the =~ operator, which suppresses the
|
|
special meaning of the characters special to regular expression processing
|
|
(`.', `[', `\', `(', `), `*', `+', `?', `{', `|', `^', and `$') and forces
|
|
them to be matched literally. This is consistent with how the `==' pattern
|
|
matching operator treats quoted portions of its pattern argument.
|
|
|
|
Since the treatment of quoted string arguments was changed, several issues
|
|
have arisen, chief among them the problem of white space in pattern arguments
|
|
and the differing treatment of quoted strings between bash-3.1 and bash-3.2.
|
|
Both problems may be solved by using a shell variable to hold the pattern.
|
|
Since word splitting is not performed when expanding shell variables in all
|
|
operands of the [[ command, this allows users to quote patterns as they wish
|
|
when assigning the variable, then expand the values to a single string that
|
|
may contain whitespace. The first problem may be solved by using backslashes
|
|
or any other quoting mechanism to escape the white space in the patterns.
|
|
|
|
Bash-4.0 introduces the concept of a `compatibility level', controlled by
|
|
several options to the `shopt' builtin. If the `compat31' option is enabled,
|
|
bash reverts to the bash-3.1 behavior with respect to quoting the rhs of
|
|
the =~ operator.
|
|
|
|
E15) Tell me more about the shell compatibility level.
|
|
|
|
Bash-4.0 introduced the concept of a `shell compatibility level', specified
|
|
as a set of options to the shopt builtin (compat31, compat32, compat40 at
|
|
this writing). There is only one current compatibility level -- each
|
|
option is mutually exclusive. This list does not mention behavior that is
|
|
standard for a particular version (e.g., setting compat32 means that quoting
|
|
the rhs of the regexp matching operator quotes special regexp characters in
|
|
the word, which is default behavior in bash-3.2 and above).
|
|
|
|
compat31 set
|
|
- the < and > operators to the [[ command do not consider the current
|
|
locale when comparing strings
|
|
- quoting the rhs of the regexp matching operator (=~) has no
|
|
special effect
|
|
|
|
compat32 set
|
|
- the < and > operators to the [[ command do not consider the current
|
|
locale when comparing strings
|
|
|
|
compat40 set
|
|
- the < and > operators to the [[ command do not consider the current
|
|
locale when comparing strings
|
|
- interrupting a command list such as "a ; b ; c" causes the execution
|
|
of the entire list to be aborted (in versions before bash-4.0,
|
|
interrupting one command in a list caused the next to be executed)
|
|
|
|
compat41 set
|
|
- interrupting a command list such as "a ; b ; c" causes the execution
|
|
of the entire list to be aborted (in versions before bash-4.1,
|
|
interrupting one command in a list caused the next to be executed)
|
|
- when in posix mode, single quotes in the `word' portion of a
|
|
double-quoted parameter expansion define a new quoting context and
|
|
are treated specially
|
|
|
|
compat42 set
|
|
- the replacement string in double-quoted pattern substitution is not
|
|
run through quote removal, as in previous versions
|
|
|
|
Section F: Things to watch out for on certain Unix versions
|
|
|
|
F1) Why can't I use command line editing in my `cmdtool'?
|
|
|
|
The problem is `cmdtool' and bash fighting over the input. When
|
|
scrolling is enabled in a cmdtool window, cmdtool puts the tty in
|
|
`raw mode' to permit command-line editing using the mouse for
|
|
applications that cannot do it themselves. As a result, bash and
|
|
cmdtool each try to read keyboard input immediately, with neither
|
|
getting enough of it to be useful.
|
|
|
|
This mode also causes cmdtool to not implement many of the
|
|
terminal functions and control sequences appearing in the
|
|
`sun-cmd' termcap entry. For a more complete explanation, see
|
|
that file examples/suncmd.termcap in the bash distribution.
|
|
|
|
`xterm' is a better choice, and gets along with bash much more
|
|
smoothly.
|
|
|
|
If you must use cmdtool, you can use the termcap description in
|
|
examples/suncmd.termcap. Set the TERMCAP variable to the terminal
|
|
description contained in that file, i.e.
|
|
|
|
TERMCAP='Mu|sun-cmd:am:bs:km:pt:li#34:co#80:cl=^L:ce=\E[K:cd=\E[J:rs=\E[s:'
|
|
|
|
Then export TERMCAP and start a new cmdtool window from that shell.
|
|
The bash command-line editing should behave better in the new
|
|
cmdtool. If this works, you can put the assignment to TERMCAP
|
|
in your bashrc file.
|
|
|
|
F2) I built bash on Solaris 2. Why do globbing expansions and filename
|
|
completion chop off the first few characters of each filename?
|
|
|
|
This is the consequence of building bash on SunOS 5 and linking
|
|
with the libraries in /usr/ucblib, but using the definitions
|
|
and structures from files in /usr/include.
|
|
|
|
The actual conflict is between the dirent structure in
|
|
/usr/include/dirent.h and the struct returned by the version of
|
|
`readdir' in libucb.a (a 4.3-BSD style `struct direct').
|
|
|
|
Make sure you've got /usr/ccs/bin ahead of /usr/ucb in your $PATH
|
|
when configuring and building bash. This will ensure that you
|
|
use /usr/ccs/bin/cc or acc instead of /usr/ucb/cc and that you
|
|
link with libc before libucb.
|
|
|
|
If you have installed the Sun C compiler, you may also need to
|
|
put /usr/ccs/bin and /opt/SUNWspro/bin into your $PATH before
|
|
/usr/ucb.
|
|
|
|
F3) Why does bash dump core after I interrupt username completion or
|
|
`~user' tilde expansion on a machine running NIS?
|
|
|
|
This is a famous and long-standing bug in the SunOS YP (sorry, NIS)
|
|
client library, which is part of libc.
|
|
|
|
The YP library code keeps static state -- a pointer into the data
|
|
returned from the server. When YP initializes itself (setpwent),
|
|
it looks at this pointer and calls free on it if it's non-null.
|
|
So far, so good.
|
|
|
|
If one of the YP functions is interrupted during getpwent (the
|
|
exact function is interpretwithsave()), and returns NULL, the
|
|
pointer is freed without being reset to NULL, and the function
|
|
returns. The next time getpwent is called, it sees that this
|
|
pointer is non-null, calls free, and the bash free() blows up
|
|
because it's being asked to free freed memory.
|
|
|
|
The traditional Unix mallocs allow memory to be freed multiple
|
|
times; that's probably why this has never been fixed. You can
|
|
run configure with the `--without-gnu-malloc' option to use
|
|
the C library malloc and avoid the problem.
|
|
|
|
F4) I'm running SVR4.2. Why is the line erased every time I type `@'?
|
|
|
|
The `@' character is the default `line kill' character in most
|
|
versions of System V, including SVR4.2. You can change this
|
|
character to whatever you want using `stty'. For example, to
|
|
change the line kill character to control-u, type
|
|
|
|
stty kill ^U
|
|
|
|
where the `^' and `U' can be two separate characters.
|
|
|
|
F5) Why does bash report syntax errors when my C News scripts use a
|
|
redirection before a subshell command?
|
|
|
|
The actual command in question is something like
|
|
|
|
< file ( command )
|
|
|
|
According to the grammar given in the POSIX.2 standard, this construct
|
|
is, in fact, a syntax error. Redirections may only precede `simple
|
|
commands'. A subshell construct such as the above is one of the shell's
|
|
`compound commands'. A redirection may only follow a compound command.
|
|
|
|
This affects the mechanical transformation of commands that use `cat'
|
|
to pipe a file into a command (a favorite Useless-Use-Of-Cat topic on
|
|
comp.unix.shell). While most commands of the form
|
|
|
|
cat file | command
|
|
|
|
can be converted to `< file command', shell control structures such as
|
|
loops and subshells require `command < file'.
|
|
|
|
The file CWRU/sh-redir-hack in the bash distribution is an
|
|
(unofficial) patch to parse.y that will modify the grammar to
|
|
support this construct. It will not apply with `patch'; you must
|
|
modify parse.y by hand. Note that if you apply this, you must
|
|
recompile with -DREDIRECTION_HACK. This introduces a large
|
|
number of reduce/reduce conflicts into the shell grammar.
|
|
|
|
F6) Why can't I use vi-mode editing on Red Hat Linux 6.1?
|
|
|
|
The short answer is that Red Hat screwed up.
|
|
|
|
The long answer is that they shipped an /etc/inputrc that only works
|
|
for emacs mode editing, and then screwed all the vi users by setting
|
|
INPUTRC to /etc/inputrc in /etc/profile.
|
|
|
|
The short fix is to do one of the following: remove or rename
|
|
/etc/inputrc, set INPUTRC=~/.inputrc in ~/.bashrc (or .bash_profile,
|
|
but make sure you export it if you do), remove the assignment to
|
|
INPUTRC from /etc/profile, add
|
|
|
|
set keymap emacs
|
|
|
|
to the beginning of /etc/inputrc, or bracket the key bindings in
|
|
/etc/inputrc with these lines
|
|
|
|
$if mode=emacs
|
|
[...]
|
|
$endif
|
|
|
|
F7) Why do bash-2.05a and bash-2.05b fail to compile `printf.def' on
|
|
HP/UX 11.x?
|
|
|
|
HP/UX's support for long double is imperfect at best.
|
|
|
|
GCC will support it without problems, but the HP C library functions
|
|
like strtold(3) and printf(3) don't actually work with long doubles.
|
|
HP implemented a `long_double' type as a 4-element array of 32-bit
|
|
ints, and that is what the library functions use. The ANSI C
|
|
`long double' type is a 128-bit floating point scalar.
|
|
|
|
The easiest fix, until HP fixes things up, is to edit the generated
|
|
config.h and #undef the HAVE_LONG_DOUBLE line. After doing that,
|
|
the compilation should complete successfully.
|
|
|
|
Section G: How can I get bash to do certain common things?
|
|
|
|
G1) How can I get bash to read and display eight-bit characters?
|
|
|
|
This is a process requiring several steps.
|
|
|
|
First, you must ensure that the `physical' data path is a full eight
|
|
bits. For xterms, for example, the `vt100' resources `eightBitInput'
|
|
and `eightBitOutput' should be set to `true'.
|
|
|
|
Once you have set up an eight-bit path, you must tell the kernel and
|
|
tty driver to leave the eighth bit of characters alone when processing
|
|
keyboard input. Use `stty' to do this:
|
|
|
|
stty cs8 -istrip -parenb
|
|
|
|
For old BSD-style systems, you can use
|
|
|
|
stty pass8
|
|
|
|
You may also need
|
|
|
|
stty even odd
|
|
|
|
Finally, you need to tell readline that you will be inputting and
|
|
displaying eight-bit characters. You use readline variables to do
|
|
this. These variables can be set in your .inputrc or using the bash
|
|
`bind' builtin. Here's an example using `bind':
|
|
|
|
bash$ bind 'set convert-meta off'
|
|
bash$ bind 'set meta-flag on'
|
|
bash$ bind 'set output-meta on'
|
|
|
|
The `set' commands between the single quotes may also be placed
|
|
in ~/.inputrc.
|
|
|
|
The script examples/scripts.noah/meta.bash encapsulates the bind
|
|
commands in a shell function.
|
|
|
|
G2) How do I write a function `x' to replace builtin command `x', but
|
|
still invoke the command from within the function?
|
|
|
|
This is why the `command' and `builtin' builtins exist. The
|
|
`command' builtin executes the command supplied as its first
|
|
argument, skipping over any function defined with that name. The
|
|
`builtin' builtin executes the builtin command given as its first
|
|
argument directly.
|
|
|
|
For example, to write a function to replace `cd' that writes the
|
|
hostname and current directory to an xterm title bar, use
|
|
something like the following:
|
|
|
|
cd()
|
|
{
|
|
builtin cd "$@" && xtitle "$HOST: $PWD"
|
|
}
|
|
|
|
This could also be written using `command' instead of `builtin';
|
|
the version above is marginally more efficient.
|
|
|
|
G3) How can I find the value of a shell variable whose name is the value
|
|
of another shell variable?
|
|
|
|
Versions of Bash newer than Bash-2.0 support this directly. You can use
|
|
|
|
${!var}
|
|
|
|
For example, the following sequence of commands will echo `z':
|
|
|
|
var1=var2
|
|
var2=z
|
|
echo ${!var1}
|
|
|
|
For sh compatibility, use the `eval' builtin. The important
|
|
thing to remember is that `eval' expands the arguments you give
|
|
it again, so you need to quote the parts of the arguments that
|
|
you want `eval' to act on.
|
|
|
|
For example, this expression prints the value of the last positional
|
|
parameter:
|
|
|
|
eval echo \"\$\{$#\}\"
|
|
|
|
The expansion of the quoted portions of this expression will be
|
|
deferred until `eval' runs, while the `$#' will be expanded
|
|
before `eval' is executed. In versions of bash later than bash-2.0,
|
|
|
|
echo ${!#}
|
|
|
|
does the same thing.
|
|
|
|
This is not the same thing as ksh93 `nameref' variables, though the syntax
|
|
is similar. Namerefs are available bash version 4.3, and work as in ksh93.
|
|
|
|
G4) How can I make the bash `time' reserved word print timing output that
|
|
looks like the output from my system's /usr/bin/time?
|
|
|
|
The bash command timing code looks for a variable `TIMEFORMAT' and
|
|
uses its value as a format string to decide how to display the
|
|
timing statistics.
|
|
|
|
The value of TIMEFORMAT is a string with `%' escapes expanded in a
|
|
fashion similar in spirit to printf(3). The manual page explains
|
|
the meanings of the escape sequences in the format string.
|
|
|
|
If TIMEFORMAT is not set, bash acts as if the following assignment had
|
|
been performed:
|
|
|
|
TIMEFORMAT=$'\nreal\t%3lR\nuser\t%3lU\nsys\t%3lS'
|
|
|
|
The POSIX.2 default time format (used by `time -p command') is
|
|
|
|
TIMEFORMAT=$'real %2R\nuser %2U\nsys %2S'
|
|
|
|
The BSD /usr/bin/time format can be emulated with:
|
|
|
|
TIMEFORMAT=$'\t%1R real\t%1U user\t%1S sys'
|
|
|
|
The System V /usr/bin/time format can be emulated with:
|
|
|
|
TIMEFORMAT=$'\nreal\t%1R\nuser\t%1U\nsys\t%1S'
|
|
|
|
The ksh format can be emulated with:
|
|
|
|
TIMEFORMAT=$'\nreal\t%2lR\nuser\t%2lU\nsys\t%2lS'
|
|
|
|
G5) How do I get the current directory into my prompt?
|
|
|
|
Bash provides a number of backslash-escape sequences which are expanded
|
|
when the prompt string (PS1 or PS2) is displayed. The full list is in
|
|
the manual page.
|
|
|
|
The \w expansion gives the full pathname of the current directory, with
|
|
a tilde (`~') substituted for the current value of $HOME. The \W
|
|
expansion gives the basename of the current directory. To put the full
|
|
pathname of the current directory into the path without any tilde
|
|
substitution, use $PWD. Here are some examples:
|
|
|
|
PS1='\w$ ' # current directory with tilde
|
|
PS1='\W$ ' # basename of current directory
|
|
PS1='$PWD$ ' # full pathname of current directory
|
|
|
|
The single quotes are important in the final example to prevent $PWD from
|
|
being expanded when the assignment to PS1 is performed.
|
|
|
|
G6) How can I rename "*.foo" to "*.bar"?
|
|
|
|
Use the pattern removal functionality described in D3. The following `for'
|
|
loop will do the trick:
|
|
|
|
for f in *.foo; do
|
|
mv $f ${f%foo}bar
|
|
done
|
|
|
|
G7) How can I translate a filename from uppercase to lowercase?
|
|
|
|
The script examples/functions/lowercase, originally written by John DuBois,
|
|
will do the trick. The converse is left as an exercise.
|
|
|
|
G8) How can I write a filename expansion (globbing) pattern that will match
|
|
all files in the current directory except "." and ".."?
|
|
|
|
You must have set the `extglob' shell option using `shopt -s extglob' to use
|
|
this:
|
|
|
|
echo .!(.|) *
|
|
|
|
A solution that works without extended globbing is given in the Unix Shell
|
|
FAQ, posted periodically to comp.unix.shell. It's a variant of
|
|
|
|
echo .[!.]* ..?* *
|
|
|
|
(The ..?* catches files with names of three or more characters beginning
|
|
with `..')
|
|
|
|
Section H: Where do I go from here?
|
|
|
|
H1) How do I report bugs in bash, and where should I look for fixes and
|
|
advice?
|
|
|
|
Use the `bashbug' script to report bugs. It is built and
|
|
installed at the same time as bash. It provides a standard
|
|
template for reporting a problem and automatically includes
|
|
information about your configuration and build environment.
|
|
|
|
`bashbug' sends its reports to bug-bash@gnu.org, which
|
|
is a large mailing list gatewayed to the usenet newsgroup gnu.bash.bug.
|
|
|
|
Bug fixes, answers to questions, and announcements of new releases
|
|
are all posted to gnu.bash.bug. Discussions concerning bash features
|
|
and problems also take place there.
|
|
|
|
To reach the bash maintainers directly, send mail to
|
|
bash-maintainers@gnu.org.
|
|
|
|
H2) What kind of bash documentation is there?
|
|
|
|
First, look in the doc directory in the bash distribution. It should
|
|
contain at least the following files:
|
|
|
|
bash.1 an extensive, thorough Unix-style manual page
|
|
builtins.1 a manual page covering just bash builtin commands
|
|
bashref.texi a reference manual in GNU tex`info format
|
|
bashref.info an info version of the reference manual
|
|
FAQ this file
|
|
article.ms text of an article written for The Linux Journal
|
|
readline.3 a man page describing readline
|
|
|
|
Postscript, HTML, and ASCII files created from the above source are
|
|
available in the documentation distribution.
|
|
|
|
There is additional documentation available for anonymous FTP from host
|
|
ftp.cwru.edu in the `pub/bash' directory.
|
|
|
|
Cameron Newham and Bill Rosenblatt have written a book on bash, published
|
|
by O'Reilly and Associates. The book is based on Bill Rosenblatt's Korn
|
|
Shell book. The title is ``Learning the Bash Shell'', and the ISBN number
|
|
of the third edition, published in March, 2005, is 0-596-00965-8. Look for
|
|
it in fine bookstores near you. This edition of the book has been updated
|
|
to cover bash-3.0.
|
|
|
|
The GNU Bash Reference Manual has been published as a printed book by
|
|
Network Theory Ltd (Paperback, ISBN: 0-9541617-7-7, Nov. 2006). It covers
|
|
bash-3.2 and is available from most online bookstores (see
|
|
http://www.network-theory.co.uk/bash/manual/ for details). The publisher
|
|
will donate $1 to the Free Software Foundation for each copy sold.
|
|
|
|
Arnold Robbins and Nelson Beebe have written ``Classic Shell Scripting'',
|
|
published by O'Reilly. The first edition, with ISBN number 0-596-00595-4,
|
|
was published in May, 2005.
|
|
|
|
Chris F. A. Johnson, a frequent contributor to comp.unix.shell and
|
|
gnu.bash.bug, has written ``Shell Scripting Recipes: A Problem-Solution
|
|
Approach,'' a new book on shell scripting, concentrating on features of
|
|
the POSIX standard helpful to shell script writers. The first edition from
|
|
Apress, with ISBN number 1-59059-471-1, was published in May, 2005.
|
|
|
|
H3) What's coming in future versions?
|
|
|
|
These are features I hope to include in a future version of bash.
|
|
|
|
Rocky Bernstein's bash debugger (support is included with bash-4.0)
|
|
|
|
H4) What's on the bash `wish list' for future versions?
|
|
|
|
These are features that may or may not appear in a future version of bash.
|
|
|
|
breaking some of the shell functionality into embeddable libraries
|
|
a module system like zsh's, using dynamic loading like builtins
|
|
a bash programmer's guide with a chapter on creating loadable builtins
|
|
a better loadable interface to perl with access to the shell builtins and
|
|
variables (contributions gratefully accepted)
|
|
ksh93-like `xx.yy' variables (including some of the .sh.* variables) and
|
|
associated discipline functions
|
|
Some of the new ksh93 pattern matching operators, like backreferencing
|
|
|
|
H5) When will the next release appear?
|
|
|
|
The next version will appear sometime in 2015. Never make predictions.
|
|
|
|
This document is Copyright 1995-2014 by Chester Ramey.
|
|
|
|
Permission is hereby granted, without written agreement and
|
|
without license or royalty fees, to use, copy, and distribute
|
|
this document for any purpose, provided that the above copyright
|
|
notice appears in all copies of this document and that the
|
|
contents of this document remain unaltered.
|