AI Prompts for Writing Bash Scripts

A developer asked an AI for a bash script to clean up a build directory. The script had one unquoted variable. When that variable was empty — because an earlier step failed — the line

rm -rf $BUILD_DIR/

rm -rf /

What Are AI Prompts for Writing Bash Scripts?

AI prompts for writing bash scripts are structured requests that get a model to generate shell scripts with bash's many footguns disarmed — proper quoting, strict error modes, and safe handling of the empty and unexpected inputs that turn a helpful script into a destructive one.

Bash is uniquely dangerous among common languages because it's permissive by default. Unquoted variables split on whitespace. Undefined variables expand to empty strings silently. A failed command doesn't stop the script unless you tell it to. Each of these defaults is a trap, and generated bash walks into them constantly unless the prompt says otherwise.

⚡ Pro tip: Always ask for

set -euo pipefail

-e

-u

-o pipefail

Why It Matters

The consequences of a bash bug are often immediate and irreversible. Unlike a web app bug that shows a broken page, a bash bug can delete files, overwrite data, or misconfigure a server in the time it takes to press Enter. And bash scripts often run with elevated permissions — as deployment scripts, cron jobs, or setup automation — which multiplies the damage a bug can do.

The intro story isn't rare. The unquoted-variable-becomes-

rm -rf /

Getting bash right compounds because bash scripts tend to stick around. That "temporary" deploy script runs for three years. A script written safely — quoted, strict-mode, error-handled — runs quietly the whole time. A script written carelessly is a landmine waiting for the one edge case that sets it off, usually at the worst possible moment.

Prompting for Safe Bash

The core of safe bash prompting is asking for the protections bash doesn't give by default.

Here's a weak bash prompt and its risk:

Write a bash script to back up my project folder and
delete the old backups.

"Delete the old backups" with no safety framing is how you get an unquoted

rm

Write a bash script to back up ~/project to
~/backups/project-TIMESTAMP. Requirements:
- Start with set -euo pipefail
- Quote ALL variable expansions ("$var", not $var)
- Verify source exists before backing up; exit if not
- For deleting old backups, keep the 5 newest, and print
  what will be deleted before deleting (with a confirm
  prompt or --force flag)
- Never construct rm paths from possibly-empty variables
- Trap errors and print a clear message with the line number
Explain each safety measure in a comment.

What this does: It turns on strict mode, requires quoting, guards the destructive

rm

⚡ Pro tip: For any

rm

[[ -n "$dir" ]]

rm -rf "$dir"

Prompting for Portability and Clarity

Beyond safety, generated bash often has portability and readability issues worth prompting against.

Bash scripts that work on Linux sometimes break on macOS because of differences in tools like

sed

date

This needs to run on both macOS and Linux. Avoid GNU-only
flags on sed/date, or detect the OS and branch. Note any
command that behaves differently across the two.

What this does: It surfaces the tool differences that silently break "portable" scripts, so you find out at write time instead of when a teammate on a different OS runs it.

A platform engineer I know always adds the cross-platform note because his team is split between Mac laptops and Linux servers, and the

sed -i

⚡ Pro tip: Ask the model to add a

usage()

Common Mistakes

The biggest mistake is running a generated bash script with elevated permissions before reading it line by line. Bash does exactly what's written, instantly, and

sudo

rm

mv

⚠️ Common mistake: Trusting unquoted variable expansions in generated bash. Unquoted

$var

$variable

"$variable"

Another frequent error is ignoring exit codes. A script that doesn't check whether a command succeeded will happily continue after a failure, compounding the problem. Strict mode (

set -e

A subtler mistake is building file paths by concatenating variables without validation. If any part is empty or unexpected, you get a path pointing somewhere dangerous. Validate the pieces before using them in destructive operations, and never let an unchecked variable land inside an

rm

Conclusion

AI prompts for writing bash scripts succeed when they explicitly disarm bash's footguns — strict mode, quoted expansions, guarded destructive commands, and clear error handling. Bash won't protect you by default, so the prompt has to do the protecting.

The developers who write bash they can trust with

sudo

set -euo pipefail

set -euo pipefail

One habit ties all of this together: read generated bash like it's trying to hurt you, because in a sense it is. Bash's permissiveness means the model can hand you a script that looks fine and contains a subtle footgun — an unquoted variable, a missing existence check, a pipeline whose failure goes unnoticed. Slowing down to read every destructive line, and asking "what if this variable is empty?" at each one, is the single most valuable review habit in shell scripting. It takes a minute and prevents the disasters that make bash infamous.

⚡ Pro tip: For any bash script you'll run more than once, ask the model to make it pass shellcheck cleanly. Shellcheck is a static analyzer that catches most common bash mistakes automatically, and prompting for shellcheck-clean code means the model applies those rules while writing rather than leaving you to find the problems after. It's like having a bash expert review every line before you run it.

It's worth internalizing that bash's danger and its usefulness come from the same source: it does precisely what you say, immediately, with full system access. That power is why bash remains the glue of the computing world decades after fancier languages arrived, and it's why a careless line can be catastrophic. Respecting bash means treating every generated script as something to read carefully rather than run blindly, and building the safety in at the prompt so the model does most of the careful thinking for you. Do that, and bash becomes the reliable workhorse it's meant to be instead of the footgun it's infamous for. Make strict mode and quoting your defaults, read every destructive line, and bash will serve you reliably for years instead of surprising you once in a way you never forget. That trade — a little care up front for a lot of safety over time — is one every experienced engineer eventually learns to make. The safety net you build into your prompts today is the disaster you never have to explain tomorrow. Careful bash is quiet bash, and quiet bash is the kind you can finally stop worrying about entirely.