Introduction

All the information here is presented without any warranty or guarantee of accuracy. Use it at your own risk. When in doubt, please consult the man pages or the GNU info pages as the authoritative references.

["BASH"] is a BourneShell compatible shell, which adds many new features to its ancestor. Most of them are available in the 'KornShell', too.

TableOfContents

Anchor(about)

About This Guide

This guide aims to become a point of reference for people interested in learning to work with ["BASH"]. It aspires to teach its readers good practice techniques in developing scripts for the ["BASH"] interpreter and educate them about the internal operation of ["BASH"].

This guide is targetted at beginning users. It assumes no basic knowledge, but rather expects you to have enough common sense to put two and two together. If something is unclear to you, you should report this so that it may be clearified in this document for future readers.

You are invited to contribute to the development of this document by extending it or correcting invalid or incomplete information.

Anchor(definition)

A Definition

["BASH"] is an acronym for Bourne Again Shell. It is based on the Bourne shell and is mostly compatible with its features.

Shells are applications that provide users with the ability to give commands to their operating system interactively, or to allow them to execute batch processes quickly. In no way are they required for execution of processes, they are merely a layer between system function calls and the user.

Anchor(using)

Using Bash

Most users that think of ["BASH"] think of it as a prompt and a commandline. That is ["BASH"] in interactive mode. ["BASH"] can also run in non-interactive mode through scripts. We can use scripts to automate certain logic. Scripts are basically lists of commands that you can type on the commandline. When such a script is executed, all these commands are executed sequentially; one after another.

We'll start with the basics in an interactive shell. Once you're familiar with those, you can put them together in scripts.

Anchor(basics)

The Basics

Anchor(commands)

Commands And Arguments

["BASH"] takes commands on the commandline. Commands can be different things. They can be application executables, aliases, function names, etc.

• Application Executables: ["BASH"] keeps a variable that tells it where to find the executables for certain applications. This variable is called PATH, and it usually contains /bin:/usr/bin. This is a string of pathnames separated by colons. Each path can contain executables. When a command is specified in ["BASH"] without a pathname (e.g. ls), ["BASH"] searches these paths for the executable for this command.

• Aliases: ["BASH"] can use aliases to make it easier to quickly execute complex commands. An alias is a name that is mapped to a certain string. Whenever that name is used as a command in bash, it is replaced by the string.

• Functions: Functions in ["BASH"] are much like aliases. When a command is executed by the name of a function, the code of that function is executed instead.

Each command can be followed by arguments. It is very important that you understand how this works exactly. If you don't grasp these concepts well, the quality of your code will degrade significantly and you will introduce very dangerous bugs. So, pay close attention in the next few chapters.

    $ ls
    a  b  c

ls is a command that lists files in the current directory.

    $ mkdir d
    $ cd d
    $ ls

mkdir is a command that creates a new directory. We specified the argument d to that command. This way, the application mkdir is instructed to create a directory called d. After that, we use the application cd to change the current directory to d. ls shows us that the current directory (which is now d) is empty, since it doesn't display any filenames.

• Tip: BR You can use the type command to figure out the type of a command. BR For example:

    $ type rm
    rm is hashed (/bin/rm)
    $ type cd
    cd is a shell builtin'''

    $ ls
    $ touch a b c
    $ ls
    a  b  c

    $ rm *
    $ ls
    $ touch a   b c
    $ ls
    a  b  c

    $ echo This is a test.
    This is a test.
    $ echo This    is    a    test.
    This is a test.

    $ echo "This    is    a    test."
    This    is    a    test.

    $ ls
    The secret voice in your head.mp3  secret
    $ rm The secret voice in your head.mp3
    rm: cannot remove `The': No such file or directory
    rm: cannot remove `voice': No such file or directory
    rm: cannot remove `in': No such file or directory
    rm: cannot remove `your': No such file or directory
    rm: cannot remove `head.mp3': No such file or directory
    $ ls
    The secret voice in your head.mp3

• Good Practice: BR You should always quote sentences or strings that belong together; even if it's not absolutely necessary. This will keep you alert and reduce the risk of human error in your scripts. BR For example, you should always quote arguments to the echo command.

Anchor(globs)

Globs

• *: Matches any string, including the null string.

• ?: Matches any single character.

• [...]: Matches any one of the enclosed characters.

Here's an example of how we can use glob patterns to expand to filenames:

    $ ls
    a  abc  b  c
    $ echo *
    a abc b c
    $ echo a*
    a abc

    $ touch "a b.txt"
    $ ls
    a b.txt
    $ rm *
    $ ls

Here, rm * is expanded into rm a\ b.txt. This makes sure that the string a b.txt is passed as a single argument to rm, since it represents a single file. It is important to understand that using globs to enumerate files is nearly always a better idea than using ls for that purpose. Here's an example with some more complex syntax which we will cover later on, but it will illustrate the problem very well:

    $ ls
    a b.txt
    $ for file in `ls`; do rm "$file"; done
    rm: cannot remove `a': No such file or directory
    rm: cannot remove `b.txt': No such file or directory
    $ for file in *; do rm "$file"; done
    $ ls

Here we use the for command to go through the output of the ls command. The ls command results in a string a b.txt. The for command splits that string into arguments over which it iterates. As a result, for iterates over a and b.txt. Naturally, this is not what we want. The glob however expands in the proper form. It results in the string a\ b.txt, which for takes as a single argument.

["BASH"] also supports a feature called Extended Globs. These globs are more powerful in nature. This feature is turned off by default, but can be turned on with the shopt command, which is used to toggle shell options:

    $ shopt -s extglob

• ?(list): Matches zero or one occurrence of the given patterns.

• *(list): Matches zero or more occurrences of the given patterns.

• +(list): Matches one or more occurrences of the given patterns.

• @(list): Matches one of the given patterns.

• !(list): Matches anything except one of the given patterns.

The list inside the parentheses is a list of globs separated by the | character. Here's an example:

    $ ls
    names.txt  tokyo.jpg  california.bmp
    $ echo !(*jpg|*bmp)
    names.txt

    $ echo th{e,a}n
    then than
    $ echo {/home/*,/root}/.*profile
    /home/axxo/.bash_profile /home/lhunath/.profile /root/.bash_profile /root/.profile
    $ echo {1..9}
    1 2 3 4 5 6 7 8 9
    $ echo {0,1}{0..9}
    00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

• Good Practice: BR You should always use globs in favor of ls (or similar) to enumerate files. Globs will always expand safely and minimize the risk for bugs. BR You can sometimes end up with some very weird filenames. Generally speaking, scripts aren't always tested against all the odd cases that it may end up being used with.

Anchor(characters)

Special Characters

• "text": Double quotes. Double quotes protect the text inside from being split into multiple words or arguments. They also prevent the special meaning of single quotes inside.

• 'text': Single quotes. Single quotes protect the text inside from any kind of expansion by the shell and keeps it from being split into multiple words or arguments. They also prevent the special meaning of all special characters inside.

• # text: Comment character. Any text that follows until the first newline is not processed as shell commands or arguments.

• ;: Command separator. The colon is used to separate multiple commands from each other if the user chooses to keep them on the same line. It's basically the same thing as a newline.

• \: Escape character. The escape character protects the next character from being used in any special sort of way.

• > or <: Redirection character. These characters are used to modify (redirect) the input and/or output of a command.

• expression: Test expression. This evaluates the conditional expression.

• { commands; }: Command Group. This executes the commands inside the braces as though they were only one command. It is convenient for places where ["BASH"] syntax requires only one command to be present.

• command, $(command): Command substitution (The latter form is highly preferred). Command substitution executes the command inside the substitution form first, and replaces itself by that command's output.

• (command): Subshell Execution. This executes the command in a new bash shell, instead of in the current.

• ((expression)): Arithmetic Evaluation. Inside the parentheses, operators such as +, -, * and / are seen as mathematical operators.

• $((expression)): Arithmetic Expansion. Comparable to the above, however this expression is replaced the result of its arithmetic evaluation.

• $: Expansion character. This character is used for any form of parameter expansion. More about this later.

Some examples:

    $ echo "I am $USER"
    I am lhunath
    $ echo 'I am $USER'
    I am $USER
    $ # boo
    $ echo An open\ \ \ space
    An open   space
    $ echo "My computer is $(hostname)"
    My computer is Lyndir
    $ echo boo > file
    $ echo $(( 5 + 5 ))
    10
    $ (( 5 > 0 )) && echo "Five is bigger than zero."
    Five is bigger than zero.

    $ # Some parameters that aren't variables:
    $ echo My shell is $0, and was started with these options: $-
    My shell is -bash, and was started with these options: himB
    $ # Some parameters that ARE variables:
    $ echo I am $USER, and I live at $HOME.
    I am lhunath, and I live at /home/lhunath.

Please note: Unlike PHP/Perl/... parameters do NOT start with a $-sign. The $-sign you see in the examples merely causes the parameter that follows it to be expanded. Expansion basically means that the shell replaces it by its content. As such, USER is the parameter (variable), that contains your username. $USER will be replaced with its content; which in my case, is lhunath.

I think you've got the drift now. Here's a summary of most non-variable parameters:

• Positional Parameters: 0, 1, 2, ...; They contain the n'th argument that was passed to the current script.

• Special Parameters:

  • *: Expands to a string enumerating all positional parameters.

  • @: Depending on the context in which it is used, expands to either a string enumerating all positional parameters, or several strings; one for each parameter.

  • #: Expands to the amount of positional parameters that are currently set.

  • ?: Expands to the exit code of the most recently completed foreground application.

  • $: Expands to the ["PID"] of the current shell.

  • !: Expands to the ["PID"] of the application most recently executed in the background.

  • _: Expands to the last argument of the last command that was executed.

And here are some examples of variables that the shell initializes for you:

• BASH_VERSION: Contains a string describing the version of ["BASH"].

• HOSTNAME: Contains the hostname of your computer, I swear.

• PPID: Contains the ["PID"] of the process that started this shell.

• PWD: Contains the current directory.

• RANDOM: Each time you expand this variable, a random number between 0 and 32767 is generated.

• UID: The integer ID of the current user.

• COLUMNS: The amount of characters fit on one line in your terminal. (The width of your terminal in characters.)

• LINES: The amount of lines that fit in your terminal. (The height of your terminal in lines.)

• HOME: The current user's home directory.

• PATH: A colon-separated list of paths that will be searched to find the executable for a command that is executed, if it is not an alias or a function (or absolutely referenced).

• PS1: Contains a string that describes the format of your shell prompt.

• TMPDIR: Contains the directory that is used to store temporary files (by the shell).

Of course, you aren't restricted to only these variables. Feel free to define your own:

    $ country=Canada
    $ echo "I am $USER and I currently live in $country."
    I am lhunath and I currently live in Canada.

Notice what we did to assign the value Canada to the variable country. Remember that you are NOT allowed to have any spaces before or after that equals sign!

    $ language = PHP
    -bash: language: command not found
    $ language=PHP
    $ echo "I'm far too used to $language."
    I'm far too used to PHP.

Remember that ["BASH"] is not Perl or PHP. You need to be very well aware of how expansion works to avoid big trouble. If you don't, you'll end up creating very dangerous situations in your scripts, especially when making this mistake with rm:

    $ ls
    no secret  secret
    $ file='no secret'
    $ rm $file
    rm: cannot remove `no': No such file or directory

Imagine we have two files, no secret and secret. The first contains nothing useful, but the second contains the secret that will save the world from impending doom. Unthoughtful as you are, you forgot to quote your parameter expansion of file. ["BASH"] expands the parameter and the result is rm no secret. ["BASH"] splits the arguments up by their whitespace as it normally does, and rm is passed two arguments; 'no' and 'secret'. As a result, it fails to find the file no and it deletes the file secret. You doomed the world, you should be proud.

• Good Practice: BR You should always keep parameter expansions well quoted. This prevents the whitespace or the possible globs inside of them to give you gray hair or unexpectedly wipe stuff off your computer. The only good PE, is a quoted PE.

Anchor(conditionals)

Tests and Conditionals

From the ping manual:

• If ping does not receive any reply packets at all it will exit with code 1. If a packet count and deadline are both specified, and fewer than count packets are received by the time the deadline has arrived, it will also exit with code 1. On other error it exits with code 2. Otherwise it exits with code 0.

  This makes it possible to use the exit code to see if a host is alive or not.

The parameter ? shows us the exit code of the last foreground process that terminated. Let's play around a little with ping to see it's exit codes:

    $ ping God
    ping: unknown host God
    $ echo $?
    2

    $ ping -c 1 -W 1 1.1.1.1
    PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
    
    --- 1.1.1.1 ping statistics ---
    1 packets transmitted, 0 received, 100% packet loss, time 0ms
    $ echo $?
    1

• Good Practice: BR You should make sure that your scripts always return a non-zero exit code if something unexpected happened in its execution. You can do this with the exit builtin: BR rm file || { echo "Could not delete file!"; exit 1; }

Anchor(operators)

Control Operators

    $ mkdir d && cd d

    $ rm /etc/some_file.conf || echo "I couldn't remove the file!"

    rm: cannot remove `/etc/some_file.conf': No such file or directory
    I couldn't remove the file!

|| is much like &&, but it does the exact opposite. It only executes the next command if the first failed. As such, the message is only echoed if the rm command was unsuccessful.

You can make a sequence with these operators, but you have to be very careful when you do. Remember what exit code the operator is really going to be checking against! Here's an example that might cause confusion:

    $ false && true || echo "Riddle, riddle?"
    Riddle, riddle?

    $ true && false || echo "Riddle, riddle?"
    Riddle, riddle?

    $ rm file && touch file || echo "File not found!"

Perhaps you guessed, perhaps not, but here's a hint: Imagine we're in a directory where we don't have permission to create a file? It won't stop us from deleting the file if the file happens to be ours. rm will succeed in deleting our file, but touch will fail to create it anew because of permission issues. As a result, we get a strange error message saying that the file wasn't found while we were actually trying to create it. What's up with that?

• Good Practice: BR It's best not to get overcourageous when dealing with conditional operators. They can make your script hard to understand, especially for a person that's assigned to maintain it and didn't write it himself.

Anchor(if)

If-statements

    $ if true
    > then echo "It was true."
    > else echo "It was false!"
    > fi

    It was true.

    $ if [ a = b ]
    > then echo "a is the same as b."
    > else echo "a is not the same as b."
    > fi

    a is not the same as b.

    $ if [ my dad = my dog ]
    > then echo "I have a problem."
    > fi

    -bash: [: too many arguments

Can you guess what caused the problem? BR [ was executed with the arguments 'my', 'dad', '=', 'my', 'dog' and ']'. [ doesn't understand what test it's supposed to execute, because it expects the second argument to be the operator. In our case, the operator is the third argument. Yet another reason why quotes are so terribly important. Whenever we type whitespace in bash that belongs together with the words before or after it, we need to quote the whole string:

    $ if [ 'my dad' = 'my dog' ]
    > then echo "I have a problem."
    > fi

    $ dad='my dad'; dog='my dog'
    $ if [ $dad = $dog ]
    > then echo "I have a problem."
    > fi

    -bash: [: too many arguments

    $ if [ "$dad" = "$dog" ]
    > then echo "I have a problem."
    > fi

    $ if [[ $dad = $dog ]]
    > then echo "I have a problem."
    > fi
    $ if [[ I want $dad = I want $dog ]]
    > then echo "I want too much."
    > fi

    -bash: conditional binary operator expected
    -bash: syntax error near `want'

    $ if [[ "I want $dad" = "I want $dog" ]]
    > then echo "I want too much."
    > fi

• Tests supported by [ (also known as test):

  • -e FILE: True if file exists.

  • -f FILE: True if file is a regular file.

  • -d FILE: True if file is a directory.

  • -h FILE: True if file is a symbolic link.

  • -r FILE: True if file is readable by you.

  • -s FILE: True if file exists and is not empty.

  • -t FD : True if FD is opened on a terminal.

  • -w FILE: True if the file is writable by you.

  • -x FILE: True if the file is executable by you.

  • -O FILE: True if the file is effectively owned by you.

  • -G FILE: True if the file is effectively owned by your group.

  • FILE -nt FILE: True if the first file is newer than the second.

  • FILE -ot FILE: True if the first file is older than the second.

  • -z STRING: True if the string is empty (it's length is zero).

  • -n STRING: True if the string is not empty (it's length is not zero).

  • STRING = STRING: True if the first string is identical to the second.

  • STRING != STRING: True if the first string is not identical to the second.

  • STRING < STRING: True if the first string sorts before the second.

  • STRING > STRING: True if the first string sorts after the second.

  • EXPR -a EXPR: True if both expressions are true (logical AND).

  • EXPR -o EXPR: True if either expression is true (logical OR).

  • INT -eq INT: True if both integers are identical.

  • INT -ne INT: True if the integers are not identical.

  • INT -lt INT: True if the first integer is less than the second.

  • INT -gt INT: True if the first integer is greater than the second.

  • INT -le INT: True if the first integer is less than or equal to the second.

  • INT -ge INT: True if the first integer is greater than or equal to the second.

• Additional tests supported only by [[:

  • STRING = (or ==) PATTERN: Not string comparison like with [ (or test), but pattern matching is performed. True if the string matches the glob pattern.

  • STRING =~ REGEX: True if the string matches the regex pattern.

  • ( EXPR ): Parantheses can be used to change the evaluation precedence.

  • EXPR && EXPR: Much like the '-a' operator of test, but does not evaluate the second expression if the first already turns out to be false.

  • EXPR || EXPR: Much like the '-o' operator of test, but does not evaluate the second expression if the first already turns out to be true.

  • ! EXPR: Inverses the result of the expression.

You want some examples? Sure:

    $ test -e /etc/X11/xorg.conf && echo "Your Xorg is configured!"
    Your Xorg is configured!
    $ test -n "$HOME" && echo "Your homedir is set!"
    Your homedir is set!
    $ [[ boar != bear ]] && echo "Boars aren't bears!"
    Boars aren't bears!
    $ [[ boar != b?ar ]] && echo "Boars don't look like bears!"
    $ [[ $DISPLAY ]] && echo "Your DISPLAY variable is not empty, you probably have Xorg running."
    Your DISPLAY variable is not empty, you probably have Xorg running.
    $ [[ ! $DISPLAY ]] && echo "Your DISPLAY variable is not not empty, you probably don't have Xorg running."

• Good Practice: BR Whenever you're making a ["BASH"] script, you should always use [[ (unless if for some reason you need very specific and rare functionality from [). BR Whenever you're making a Shell script, which may end up being used in an environment where ["BASH"] is not available, you should use [, because it is far more compatible (it's an application, not built into ["BASH"], like [[).

Anchor(loops)

Conditional Loops

• while [command]: Repeat so long as command is executed successfully (exit code: 0).

• for [variable] in [words]: Repeat the loop for each word after putting it into the variable.

• for (( [expression]; [expression]; [expression] )): Starts by evaluating the first expression, repeats the loop so long as the second expression is valid and at the end of each loop evaluates the third expression.

Let's put that in practice; here are some examples to illustrate the differences but also the similarities between the loops:

    $ while true
    > do echo "Infinite loop!
    > done

    $ (( i=10 )); while (( i > 0 ))
    > do echo "$i empty cans of beer."
    > (( i-- ))
    > done

    $ for (( i=10; i > 0; i-- ))
    > do echo "$i empty cans of beer."
    > done

    $ for i in {10..0}
    > do echo "$i empty cans of beer."
    > done

    $ for i in 10 9 8 7 6 5 4 3 2 1 0
    > do echo "$i empty cans of beer."
    > done

As a result; be VERY careful not to make the following mistake:

    $ ls
    The best song in the world.mp3
    $ for file in $(ls *.mp3)
    > do rm "$file"
    > done

    rm: cannot remove `The': No such file or directory
    rm: cannot remove `best': No such file or directory
    rm: cannot remove `song': No such file or directory
    rm: cannot remove `in': No such file or directory
    rm: cannot remove `the': No such file or directory
    rm: cannot remove `world.mp3': No such file or directory

    $ ls
    The best song in the world.mp3  The worst song in the world.mp3
    $ for file in "$(ls *.mp3)"
    > do rm "$file"
    > done
    rm: cannot remove `The best song in the world.mp3  The worst song in the world.mp3': No such file or directory

Quotes will indeed protect the whitespace in your filenames; but it will do more than that. The quotes will protect all the whitespace from the output of ls. There is no way ["BASH"] can know which parts of the output of ls represent filenames; it's not psychic. The output of ls is a simple string, and ["BASH"] treats it as that for lack of better. The for puts the whole quoted output in i and runs the rm command with it. Damn, dead again.

So what do we do? As suggested earlier; globs are your best friend:

    $ for file in *.mp3
    > do rm "$file"
    > done

This time, ["BASH"] does know which are filenames, and it does know what the filenames are and as such it can split them up nicely. The result of expanding the glob is this: for file in "The best song in the world.mp3" "The worst song in the world.mp3". Problem resolved.

Let's talk about changing that delimiter. Say, you've got yourself a nice cooking recipe, and you want to write a script that tells you how to use it. Sure, let's get right at it:

    $ recipe='2 c. all purpose flour
    > 6 tsp. baking powder
    > 2 eggs
    > 2 c. milk
    > 1/3 c. oil'

    $ for ingredient in $recipe
    > do echo "Take $ingredient; mix well."
    > done

    $ recipe='2 c. all purpose flour
    > 6 tsp. baking powder
    > 2 eggs
    > 2 c. milk
    > 1/3 c. oil'
    $ IFS=$'\n'

    $ for ingredient in $recipe
    > do echo "Take $ingredient; mix well."
    > done

    Take 2 c. all purpose flour; mix well.
    Take 6 tsp. baking powder; mix well.
    Take 2 eggs; mix well.
    Take 2 c. milk; mix well.
    Take 1/3 c. oil; mix well.

Note: This delimiter is only used when the words consist of an expansion. Not when they're literal. Literal words are always split at spaces:

    $ PATH=/bin:/usr/bin
    $ IFS=:

    $ for i in $PATH
    > do echo "$i"
    > done
    /bin
    /usr/bin

    $ for i in $PATH:/usr/local/bin
    > do echo "$i"
    > done
    /bin
    /usr/bin
    /usr/local/bin

    $ for i in /bin:/usr/bin:/usr/local/bin
    > do echo "$i"
    > done
    /bin:/usr/bin:/usr/local/bin