Writing Your First Bash Script

A Bash script is simply a text file containing a sequence of shell commands that Bash executes in order, exactly as if you had typed them interactively. Scripting turns repetitive manual work — backups, deployments, log rotation, environment setup — into a single reliable, version-controllable command. The barrier to writing your first script is low: you need a text file, a shebang line telling the kernel which interpreter to use, executable permission, and a location the shell can find. From there, everything you already know about running commands at the prompt applies inside the script.

The first line of a script, #!/bin/bash (or the more portable #!/usr/bin/env bash), is called the shebang. The kernel reads these first two bytes (#!) and uses the rest of the line to determine which interpreter should run the file — this is how ./script.sh knows to invoke Bash rather than trying to execute the text as a binary. #!/usr/bin/env bash is preferred in portable scripts because it locates bash via the user's PATH rather than assuming it lives at /bin/bash, which matters on systems (like some macOS setups or containers) where Bash is installed elsewhere. If you omit the shebang and instead run the script as bash script.sh, the shebang line is ignored and treated as a comment.

Newly created scripts are not executable by default; chmod +x script.sh adds the executable bit for the owner (and typically group/other depending on umask). Once executable, ./script.sh runs it from the current directory — the leading ./ is required unless the script's directory is in your PATH, because Bash does not search the current directory for commands by default (a deliberate security measure). Alternatively, bash script.sh or sh script.sh runs it by explicitly invoking an interpreter, bypassing both the shebang and the need for the executable bit, though sh may interpret Bash-specific syntax differently.

Good scripts start with a comment block describing purpose and usage, use set -euo pipefail near the top, quote variables, and prefer functions for anything reused more than once. Comments begin with # and run to the end of the line; there is no native multi-line comment syntax, though a : <<'END' here-document is sometimes used as a workaround. Keeping scripts under version control (even a small personal Git repo of ~/.local/bin scripts) is standard practice once you have more than a handful.