Your First Script

In one line

A shell script is just a text file of commands you'd otherwise type one by one — the shebang line, execute permission, and running it are the entire ceremony required to turn any command sequence into a saved, reusable tool.

0/4 · 0%

Think of it like this

A recipe card versus cooking from memory each time — once you've written the steps down in order, ANYONE (including future you) can follow them exactly, in the same order, without re-deriving them from scratch every single time.

Key ideas

01
A script is a plain text file containing a sequence of commands, run top to bottom exactly as if you'd typed each one into the terminal yourself — nothing about a script is fundamentally different from typing commands interactively, it's simply commands saved to a file instead of your memory.
02
The SHEBANG line (#!/bin/bash or #!/usr/bin/env bash) must be the very first line of the file — it tells the system which interpreter should run this script when it's executed directly. #!/usr/bin/env bash is generally preferred over a hardcoded #!/bin/bash since it finds bash wherever it happens to be installed on the PATH, rather than assuming one fixed location.
03
A script needs EXECUTE permission (Phase 1's chmod +x script.sh) before it can be run directly as ./script.sh — without it, you'd get a 'permission denied' error, and running it as bash script.sh instead sidesteps the need for execute permission entirely by explicitly invoking the interpreter yourself.
04
Comments start with # (except the shebang's own #!, which is a special case) — genuinely important in scripts more than a few lines long, since a script that made perfect sense while writing it can be genuinely confusing to reread even a few weeks later.
05
echo prints text to the terminal — the most basic form of output a script can produce, used constantly both for genuinely informing whoever's running it and, during development, as a quick way to check that a variable holds what you expect.

In your stack

→
A build-and-run.sh script that runs mvn clean package && java -jar target/app.jar turns a two-step manual process into one command — a genuinely common first script for any Java project, saving exactly the kind of repetitive typing this entire phase is about eliminating.

Code & diagrams

first-script.shbash

The complete minimal ceremony: shebang, comment, commands, execute permission, run.

#!/usr/bin/env bash
# A minimal first script — prints a greeting and today's date

echo "Hello from a script!"
echo "Today is: $(date)"
echo "You are: $(whoami)"
echo "Current directory: $(pwd)"

run-it.shmarkdown

Making the script executable and running it, two different ways.

# Give it execute permission
chmod +x first-script.sh

# Run it directly
./first-script.sh

# Or, without needing execute permission at all, invoke bash explicitly
bash first-script.sh

Explain it without notes

What does the shebang line actually do, and what would happen if you forgot to include it?

Why does bash script.sh work even without execute permission on the file, while ./script.sh does not?

Practice

Write a 5-line script that prints your username, the current date, and the number of files in the current directory, then chmod it and run it directly.

Deliberately remove the shebang line from a working script and run it both as ./script.sh and as bash script.sh — notice which one still behaves correctly.

Trade-offs

↔
A one-off script saved to a file is barely more effort than typing the commands directly, but the payoff compounds every single time you run it again — the break-even point is usually just the SECOND time you'd otherwise have retyped or copy-pasted the same sequence of commands.

Done when you can

I can write a basic bash script with a proper shebang line.
I know how to make a script executable with chmod +x and run it directly.
I understand why bash script.sh works even without execute permission.

Command Palette