1.3 Installing Bash

Then, as user rootIn the field of computing, root is a term with several possible meanings. Root as a filesystem term For root as the base of the file system's directory structure, see Root directory. Root as a user account name In Unix style computer operating systems, ro, install Bash by executing the following command in the bash-3.0 directory:

make install

By default, Bash will be installed as /usr/local/bin/bash. This can be changed by passing the option "--prefix=/some/other/directory" to the configure script. A variety of other configuration options are available — to see them run this command:

./configure --help

1.4 How to make Bash your login shell

Your login shell is the shell that UNIX runs when you first login. On a Windows system, your login shell is Explorer, which is a graphical application. Since Bash is not a graphical application, it cannot be a Windows login shell. To see the pathname of your UNIX login shell, run this command:

grep '^YOURUSERID:' /etc/passwd | cut -d: -f7

replacing YOURUSERID with your UNIX user id.

After you build and install Bash, if it is not your login shell, you can make it your login shell by editting the file /etc/passwd, which requires that you become user root. When you edit /etc/passwd, find the line that begins with your user id and edit the seventh colon-separated field of that line. For example, you might find a line that looks like the following (assuming your user id is bsmith:

bsmith:x:502:502:Bob Smith:/home/bsmith:/bin/sh

In the above line, bsmith's login shell is /bin/sh, the Bourne shell. Changing /bin/sh to /usr/local/bin/bash in the above line permanently changes bsmith's login shell. After you do this, you may also have to add /usr/local/bin/bash to the file /etc/shells, if that file exists. Not every UNIX system requires you to edit /etc/shells.

Some UNIX systems allow you to change your login shell using the chsh command, but it may not work on all UNIX systems.

2 Bash syntax highlights

Bash's command syntax is a superset of the Bourne shell's command syntax. The definitive specification of Bash's command syntax is the man page that's installed along with Bash. This section highlights some of Bash's unique syntax features.

The vast majority of Bourne shell scripts can be executed without alteration by Bash, with the exception of those Bourne shell scripts that accidentally reference a Bash special variable or that accidentally use a Bash builtin command. The Bash command syntax includes ideas drawn from the Korn shellThe Korn shell ksh is a Unix shell which was developed by David Korn ( AT&T Bell Laboratories) in the mid 1980s. It is wholly upwards compatible with the Bourne shell and includes many features of the C shell as well, such as a command history, which was (ksh) and the C shellThe C shell csh is a Unix shell developed by Bill Joy for the BSD Unix system. It was originally derived from the 6th Edition Unix /bin/sh, the predecessor of the Bourne shell. Its syntax is modeled after the C programming language. The C shell added many (csh), such as command-line editting, command history, the directory stack, the $RANDOM and $PPID variables, and POSIX command substitution syntax: $(...). When being used as an interactive command shell, Bash supports completion of partly typed-in program names, filenames, variable names, etc. when the user presses the TAB key.

Bash syntax has many extensions that the Bourne shell lacks. Several of those extensions are enumerated here.

2.1 Integer math

A major limitation of the Bourne shell is that it cannot perform integer math without spawning an external process. Bash can perform in-process integer math using the ((...)) command and the $[...] variable syntax, as follows:

VAR=55 # Assign integer 55 to variable VAR. ((VAR = VAR + 1)) # Add one to variable VAR. Note the absense of the '$' character. ((++VAR)) # Another way to add one to VAR. Performs C-style pre-increment. ((VAR++)) # Another way to add one to VAR. Performs C-style post-increment. echo $[VAR * 22] # Multiple VAR by 22 and substitute the result into the command. echo $((VAR * 22)) # Another way to do the above.

The ((...)) command can also be used in conditional statements, because its exit status is 0 or 1 depending on whether the condition is true or false:

if ((VAR == Y * 3 + X * 2)) then echo Yes fi ((Z > 23)) && echo Yes

The ((...)) command supports the following relational operators: '==', '!=', '>', '<', '>=', and '<='.

Bash cannot perform in-process floating point math, but neither can any other UNIX command shell.

2.2 I/O redirection

Bash has several I/O redirection syntaxes that the traditional Bourne shell lacks. Bash can redirect standard output and standard error at the same time using this syntax:

command &> file

which is simpler to type than the equivalent Bourne shell syntax, "command > file 2>&1". Bash can redirect standard input from a string using the following syntax:

command <<< "string to be read as standard input"

If the string contains whitespace, it must be quoted.

2.3 In-process regular expressions

Bash 3.0 supports in-process regular expression matching using the following syntax, reminiscent of Perl:

string =~ regex

The regular expression syntax is the same as that documented by the regex(3) man page. The exit status of the above command is 0 if the regex matches the string, 1 if it does not match. Parenthesized subexpressions in the regular expression can be accessed using the shell variable BASH_REMATCH, as follows:

if abcfoobarbletch =~ 'foo(bar)bl(.*)' then echo The regex matches! echo $BASH_REMATCH -- outputs: foobarbletch echo ${BASH_REMATCH[1]} -- outputs: bar echo ${BASH_REMATCH[2]} -- outputs: etch fi

This syntax gives performance superior to spawning a separate process to run a grep command, because the regular expression matching takes place within the Bash process. If the regular expression or the string contain whitespace or shell metacharacters (such as '*' or '?'), they should be quoted.

2.4 Backslash escapes

Words of the form $'string' are treated specially. The word expands to string, with backslash-escaped characters replaced as specifed by the C programming language. Backslash escape sequences, if present, are decoded as follows:

Backslash Escapes

Backslash Escape	Expands To ...
\a	An alert (bell) character
\b	A backspace character
\e	An escape character
\f	A form feed character
\n	A new line character
\r	A carriage return character
\t	A horizontal tab character
\v	A vertical tab character
\\	A backslash character
\'	A single quote character
\nnn	The eight-bit character whose value is the octal value nnn (one to three digits)
\xHH	The eight-bit character whose value is the hexadecimal value HH (one or two hex digits)
\cx	A control-X character

The expanded result is single-quoted, as if the dollar sign had not been present.

A double-quoted string preceded by a dollar sign ($"...") will cause the string to be translated according to the current locale. If the current locale is C or POSIX, the dollar sign is ignored. If the string is translated and replaced, the replacement is double-quoted.

3 Bash startup scripts

When Bash starts, it executes the commands in a variety of different scripts.

When Bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior.

When a login shell exits, Bash reads and executes commands from the file ~/.bash_logout, if it exists.

When an interactive shell that is not a login shell is started, Bash reads and executes commands from ~/.bashrc, if that file exists. This may be inhibited by using the --norc option. The --rcfile file option will force Bash to read and execute commands from file instead of ~/.bashrc.

When Bash is started non-interactively, to run a shell script, for example, it looks for the variable BASH_ENV in the environment, expands its value if it appears there, and uses the expanded value as the name of a file to read and execute. Bash behaves as if the following command were executed:

if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi

but the value of the PATH variable is not used to search for the file name.

If Bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well. When invoked as an interactive login shell, or a non-interactive shell with the --login option, it first attempts to read and execute commands from /etc/profile and ~/.profile, in that order. The --noprofile option may be used to inhibit this behavior. When invoked as an interactive shell with the name sh, Bash looks for the variable ENV, expands its value if it is defined, and uses the expanded value as the name of a file to read and execute. Since a shell invoked as sh does not attempt to read and execute commands from any other startup files, the --rcfile option has no effect. A non-interactive shell invoked with the name sh does not attempt to read any other startup files. When invoked as sh, Bash enters posix mode after the startup files are read.

When Bash is started in posix mode, as with the --posix command line option, it follows the POSIX standard for startup files. In this mode, interactive shells expand the ENV variable and commands are read and executed from the file whose name is the expanded value. No other startup files are read.

Bash attempts to determine when it is being run by the remote shell daemon, usually rshd. If Bash determines it is being run by rshd, it reads and executes commands from ~/.bashrc, if that file exists and is readable. It will not do this if invoked as sh. The --norc option may be used to inhibit this behavior, and the --rcfile option may be used to force another file to be read, but rshd does not generally invoke the shell with those options or allow them to be specified.

4 External links

• Bash home page
• The GNU Bash Reference Manual by Chet Ramey and Brian Fox , BooksEnthsiast.com
• Advanced Bash-Scripting Guide.
• Wikibooks' Bourne Shell Scripting module
• FAQ
• Beginners Bash Tutorial
• Scripting Tutorial
• Bash 3.0 Announcement

Domain-specific programming languages Scripting languages UNIX-shell programming language family GNU project software

<Hide>