If Bash is your login shell, and you log in to the system from a terminal or terminal emulator, then it will start in interactive mode. In this mode, Bash will present a prompt when it's ready to accept a command from your terminal. This differs from non-interactive or batch mode, where commands are read from some other source, such as a script file. We will use interactive mode in this chapter to experiment with the basics of shell script command line grammar.

Nearly all of the features available to Bash in scripts are also available on the interactive command line, and they behave essentially the same way as if you ran them from a script. This allows you to treat the interactive command line as a live scripting environment: you can assign variables, create functions, and manage control flow and processes.

In this book, we won't focus too much on the interactive keyboard shortcuts in Bash. This is because it's more useful to know the syntax of the shell scripting language than it is to know key bindings.

To read more about Bash key bindings, after you have finished this book, consult the Bash manual under the READLINE section, and the GNU Readline manual:

$ man bash
$ man 3 readline

At an interactive Bash prompt, you can enter a command line for Bash to execute. Most often while in interactive mode, you would issue only one simple command at a time, ending each command with Enter. You would then wait for each command to finish before entering the next one, examining any output or errors that it passes to your terminal after each command.

A simple command consists of at least a command name, possibly with one or more arguments, each separated by at least one space. The full definition can also include environment variable assignments and redirection operators, which we'll explore in later chapters.

Let's consider the following command:

$ mkdir -p New/bash

This simple command consists of three shell words:

• mkdir: The command name, referring to the mkdir program that creates a directory
• -p: An option string for mkdir that specifies...

So far, all of our examples of commands and arguments have been single unquoted shell words. However, there is a set of metacharacters that have a different meaning to Bash, and trying to use them as part of a word causes problems.

For example, suppose you want to create (touch) a new file named important file. Note that there's a space in the name. If you try to create it as follows, you get unexpected results:

$ touch important file

If we list the files in the directory after running this, using ls -1 to put all the names on separate lines, we can see we've actually created two files; one named important, and one named file:

$ ls -1
file
important

This happened because the space between the two words separated them into two separate arguments. Space, tab, and newline are all metacharacters. So are | (pipe), & (ampersand), ; (semicolon), ( and...

The way you can reliably include characters that are special to Bash literally in a command line is to quote them. Quoting special characters makes Bash ignore any special meaning they may otherwise have to the shell, and instead use them as plain characters, like a-z or 0-9. This works for almost any special character.

Quoting is the most important thing that even experienced people who write shell script sometimes get wrong. Even a lot of very popular documentation online fails to quote correctly in example scripts! If you learn to quote correctly, you will save yourself a lot of trouble down the line. The way quoting in shell script works very often surprises people coming from other programming languages.

We will look at...

You can send an interactive command line with more than one simple command in it, separating them with a semicolon, one of several possible control operators. Bash will then execute the commands in sequence, waiting for each simple command to finish before it starts the next one. For example, we could write the following command line and issue it in an interactive Bash session:

$ cd ; ls -a ; mkdir New

For this command line, note that even if one of the commands fails, Bash will still keep running the next command. To demonstrate this, we can write a command line to include a command that we expect to fail, such as the rmdir call here:

$ cd ; rmdir ~/nonexistent ; echo &apos...

We can tell it was the rmdir command in the previous section that failed, because rmdir is the first word of the error message output. We can test the command in isolation, and look at the value of the special $? parameter with echo, to see its exit status:

$ rmdir ~/nonexistent
rmdir: failed to remove '/home/bashuser/nonexistent': No such file or directory
$ echo $?
1

The rmdir program returned an exit value of 1, because it could not delete a directory that didn't exist. If we create a directory first, and then remove it, both commands succeed, and the value of $? for both steps is 0:

$ mkdir ~/existent
$ echo $?
0
$ rmdir ~/existent
$ echo $?
0

Examining the exit values for the true and false built-in Bash commands is instructive; true always succeeds, and false always fails:

$ true ; echo $?
0
$ false ; echo $?
1

Bash will also raise an exit status...

Most of the time when programming in Bash, you will not actually want to test $? directly, but instead test it implicitly as success or failure, with language features in Bash itself.

If you wanted to issue a set of commands on one command line, but only to continue if every command worked, you would use the double-ampersand (&&) control operator, instead of the semicolon (;):

$ cd && rmdir ~/nonexistent && ls

When we run this command line, we see that the final ls never runs, because the rmdir command before it failed:

rmdir: failed to remove '/home/user/nonexistent': No such file or directory

Similarly, if we changed the cd command at the start of the command line to change into a directory that didn't exist, the command line would stop even earlier:

bash$ cd ~/nonexistent && rmdir ~/nonexistent...

There are some situations in which you might want to continue running other commands as you wait for another one to complete, to run more than one job in parallel. You can arrange for a command to run in the background by ending it with a single ampersand (&) control operator.

You can try this out by issuing a sleep command in the background. The sleep built-in Bash command accepts a number of seconds to wait as an argument. If you enter such a command without the &, Bash won't accept further commands until the command exits:

$ sleep 10
# Ten seconds pass...
$

However, if you add the & terminator to start the job in the background, the behavior is different: you get a job control number and a process ID, and you are returned immediately to your prompt:

$ sleep 10 &
[1] 435
$

You can continue running other commands as normal...

Even if you feel that you already know the basic structure of a Bash command well, carefully looking at the structure of a typical command line and knowing the rules of string quoting can make it much clearer what's wrong when something doesn't behave as expected. We use single quotes to keep characters literal, and double quotes to safely perform expansion for variables and substitutions. Developing disciplined habits with quoting and understanding how Bash runs commands in sequence is helpful not just for scripting, but for interactive command line work as well.

Having learned the structure of a Bash command line, in the next chapter we'll apply it to learning some essential commands that will form the basis of many shell scripts.