faq

android-w.song.android.widget

	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)

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 /us