[EnglishFrontPage] [TitleIndex] [WordIndex

Bash Reference Sheet


Basic Structures

See BashSheet#Examples:_Basic_Structures for some examples of the syntax below.

1. Compound Commands

Compound commands are statements that can execute several commands but are considered as a sort of command group by Bash.

1.1. Command Lists

1.2. Expressions

1.3. Loops

If you're new to loops or are looking for more details, explanation and/or examples of their usage, go read the BashGuide's section on Conditional Loops.

2. Builtins

Builtins are commands that perform a certain function that has been compiled into Bash. Understandably, they are also the only types of commands (other than those above) that can modify the Bash shell's environment.

2.1. Dummies

2.2. Declarative

2.3. Input

2.4. Output

2.5. Execution

2.6. Jobs/Processes

2.7. Conditionals And Loops

2.8. Script Arguments


If you're new to handling input and output in bash or are looking for more examples, details and/or explanations, go read BashGuide/InputAndOutput.

Bash is an excellent tool for managing streams of data between processes. Thanks to its excellent operators for connecting file descriptors, we take data from almost anywhere and send it to almost anywhere. Understanding streams and how you manipulate them in Bash is key to the vastness of Bash's power.

1. File Descriptors

A file descriptor is like a road between a file and a process. It's used by the process to send data to the file or read data from the file. A process can have a great many file descriptors, but by default, there are three that are used for standard tasks.

2. Redirection

3. Piping

4. Expansions

5. Common Combinations


If you're new to bash, don't fully understand what commands and exit codes are or want some details, explanation and/or examples on testing commands, strings or files, go read the BashGuide's section on Tests and Conditionals.

1. Exit Codes

An Exit Code or Exit Status is an unsigned 8-bit integer returned by a command that indicates how its execution went. It is agreed that an Exit Code of 0 indicates the command was successful at what it was supposed to do. Any other Exit Code indicates that something went wrong. Applications can choose for themselves what number indicates what went wrong; so refer to the manual of the application to find out what the application's Exit Code means.

1.1. Testing The Exit Code

2. Patterns

Bash knows two types of patterns. Glob Patterns is the most important, most used and best readable one. Later versions of Bash also support the "trendy" Regular Expressions. However, it is ill-advised to use regular expressions in scripts unless you have absolutely no other choice or the advantages of using them are far greater than when using globs. Generally speaking, if you need a regular expression, you'll be using awk(1), sed(1), or grep(1) instead of Bash.

If you're new to bash or want some details, explanation and/or examples on pattern matching, go read the BashGuide's section on Patterns.

2.1. Glob Syntax

2.2. Testing Patterns


Parameters are what Bash uses to store your script data in. There are Special Parameters and Variables.

Any parameters you create will be variables, since special parameters are read-only parameters managed by Bash. It is recommended you use lower-case names for your own parameters so as not to confuse them with the all-uppercase variable names used by Bash internal variables and environment variables. It is also recommended you use clear and transparent names for your variables. Avoid x, i, t, tmp, foo, etc. Instead, use the variable name to describe the kind of data the variable is supposed to hold.

It is also important that you understand the need for quoting. Generally speaking, whenever you use a parameter, you should quote it: echo "The file is in: $filePath". If you don't, bash will tear the contents of your parameter to bits, delete all the whitespace from it, and feed the bits as arguments to the command. Yes, Bash mutilates your parameter expansions by default - it's called Word Splitting - so use quotes to prevent this.
The exception is keywords and assignment. After myvar= and inside [[, case, etc, you don't need the quotes, but they won't do any harm either - so if you're unsure: quote!

Last but not least: Remember that parameters are the data structures of bash. They hold your application data. They should NOT be used to hold your application logic. So while many ill-written scripts out there may use things like GREP=/usr/bin/grep, or command='mplayer -vo x11 -ao alsa', you should NOT do this. The main reason is because you cannot possibly do it completely right and safe and readable/maintainable.
If you want to avoid retyping the same command multiple times, or make a single place to manage the command's command line, use a function instead. Not parameters.

1. Special Parameters

If you're new to bash or want some details, explanation and/or examples on parameters, go read the BashGuide's section on Special Parameters.

2. Parameter Operations

If you're new to bash or want some details, explanation and/or examples on parameter operations, go read the BashGuide's section on Parameter Expansion and BashFAQ/073.

3. Arrays

Arrays are variables that contain multiple strings. Whenever you need to store multiple items in a variable, use an array and NOT a string variable. Arrays allow you to keep the elements nicely separated and allow you to cleanly expand the elements into separate arguments. This is impossible to do if you mash your items together in a string!

If you're new to bash or don't fully grasp what arrays are and why one would use them in favor of normal variables, or you're looking for more explanation and/or examples on arrays, go read the BashGuide's section on Arrays and BashFAQ/005

3.1. Creating Arrays

3.2. Using Arrays

Examples: Basic Structures

1. Compound Commands

1.1. Command Lists

1.2. Expressions

1.3. Loops

2. Builtins

2.1. Dummies

2.2. Declarative

2.3. Input

2.4. Output

2.5. Execution


2012-07-01 04:05