Hello, World

By the end of this lesson you can write a bash script that prints text, explain why quoting changes what a command receives, and make a script pass its own input through to another command.

Bash is a command interpreter that grew into a language. Its statements are programs, its values are text, and a script is a list of command invocations with control flow around them. It is unbeatable for gluing programs together and miserable for data structures, so this course teaches the part you will use for the rest of your career: short, safe scripts.

The script

#!/usr/bin/env bash
echo "build started"

• Line 1 is the shebang: #! followed by the interpreter's path. When you run the file directly, the operating system reads those two bytes, starts the named program, and hands it your file. /usr/bin/env bash means "find bash on the PATH", which is more portable than hardcoding /bin/bash. On this platform the file is run as bash script.sh, so the shebang is a habit here, but a real server needs it.
• echo prints its arguments followed by a newline. It is not a keyword. It is a command, the same species as ls or git.
• A # starts a comment that runs to the end of the line.

To run a script yourself: bash notes.sh, or chmod +x notes.sh once (sets the executable permission bit) and then ./notes.sh.

Words are the unit of everything

Bash cuts every line into words separated by whitespace. The first word is the command, the rest are its arguments. Runs of spaces are just separators, so they disappear:

echo one      two        # prints: one two
echo "one      two"      # prints: one      two

The first line gives echo two arguments. The second gives it one, and the spaces inside the quotes belong to that one argument. The habit that prevents a hundred bugs: when the exact text matters, quote it.

Commands share your input

A script has a standard input (stdin): the stream of text fed to it, either typed at a terminal or supplied by the grader. Every command the script starts inherits that same stream. cat with no arguments copies stdin to stdout until the input ends:

#!/usr/bin/env bash
cat
echo "-- end of input --"

Given the two input lines alpha and beta, this prints:

alpha
beta
-- end of input --

Commands run top to bottom, so output appears in the order the commands run. Two facts to hold onto:

• Input is consumed once. A second cat after the first would find nothing left to read and print nothing.
• echo never reads stdin. A script made only of echo commands ignores its input completely.

Common mistakes

• Unquoted spacing. echo Hello, Bash! prints Hello, Bash! with a single space. The extra spaces were separators, not text.
• Wrong order. Putting cat before echo prints the input first and your own line last. The order of the commands is the order of the output.
• A typo in the text. The grader compares exactly: hello, bash! and Hello, Bash are both wrong.
• Expecting echo to forward input. echo prints only the words you give it, so it cannot copy a stream of lines. That is cat's job.

Your exercise

Print the line Hello, Bash!, then everything that arrives on stdin, unchanged. The input may be empty, and its lines may start with spaces or be blank, so an approach that rebuilds the text word by word will not survive the hidden tests.