ChatGPT Prompts for Writing Bash Scripts and Cron Jobs

This page may contain affiliate links.

If you run anything on Linux — a Raspberry Pi, a VPS, a NAS, a home server tucked under the stairs — you already know the deal. You want a script that backs up a folder, rotates logs, or pings you when a service dies. You open nano, type #!/bin/bash, and twenty minutes later you're on Stack Overflow wondering why your quotes are being eaten.

ChatGPT is genuinely good at this. Bash is a well-documented, heavily-Stack-Overflowed language, which means the model has seen millions of examples. But the quality of what you get back depends almost entirely on how you ask. Vague prompts get you vague scripts that half-work. The prompts below are the ones I actually use.

Start with context, not with the task

The single biggest mistake is opening with "write me a bash script to back up my files." You'll get something generic that assumes paths you don't have and tools you haven't installed.

Instead, front-load the environment. Something like:

You are helping me write a bash script for a Raspberry Pi 4 running Raspberry Pi OS (Debian-based, bash 5.1). I am comfortable with the command line but not a bash expert. Assume standard GNU coreutils are available. Write a script that copies /home/pi/documents to an external drive mounted at /mnt/backup, only copying files changed in the last 24 hours, and logs the result to /var/log/backup.log. Add comments explaining each section.

That prompt gives the model three things it needs: the target platform, your skill level, and the constraints. The output will be dramatically more usable.

Two things to add to almost every bash prompt:

• "Use set -euo pipefail at the top and explain what each flag does." This is the difference between a script that fails loudly and one that silently corrupts your data.
• "Quote all variables and explain where quoting matters." Unquoted variables are the number one source of bash bugs, especially with filenames containing spaces.

Ask for the script in stages, not all at once

A 200-line script generated in one shot is hard to review and harder to trust. Break it up.

Prompt one: Outline the structure of this script as a list of steps with brief descriptions. Do not write code yet.

Read the outline. Fix the logic before it becomes code. Then prompt two: Good. Now write step 3 only, with error handling for a missing source directory.

This staged approach does two things. It keeps each response short enough that you actually read it, and it forces you to think about the design rather than accepting whatever comes out. It also means when something breaks, you know which chunk to debug.

For anything touching files, add: Before deleting or overwriting anything, show me exactly what would be affected and ask for confirmation. You want your first run to be a dry run.

Use ChatGPT as a debugger, not just a generator

This is where most people underuse it. When a script fails, paste the error and the relevant code back in:

This script exits with 'line 14: [: missing ]'. Here is the script [paste]. Here is the exact output [paste]. Explain what is wrong, why bash behaves this way, and give me the corrected line. Then tell me how to test it without running the risky part.

Asking why matters as much as asking what. You'll learn that [ ] and [[ ]] behave differently, that $(...) strips trailing newlines, and that cd failing silently can send your script deleting the wrong directory. That knowledge compounds.

A useful follow-up prompt: What are the three most likely ways this script could fail in production, and how would I detect each one?

If you're running this on a home server or a Pi in a 3D-printed case on the shelf, it's worth having a reliable way to get a terminal to it — a decent USB keyboard and a short HDMI cable will save you a lot of swearing when SSH decides not to cooperate. You can find both via Amazon UK here.

Cron prompts: be paranoid about environment

Cron is where good scripts go to die. The classic failure is that a script works perfectly when you run it and does nothing under cron, because cron runs with a minimal environment and a different working directory.

Use a prompt like this:

I have a bash script at /home/pi/scripts/backup.sh that runs fine manually but fails under cron. Write me a cron entry that runs it daily at 02:30, and explain what environment differences could cause it to fail. Show me how to set PATH explicitly inside the crontab and how to redirect both stdout and stderr to a log file with timestamps.

Then ask the model to sanity-check your timing:

Explain this cron expression in plain English and tell me the next five times it will run: 30 2 * * 1-5

ChatGPT is reliable at translating cron syntax — far more reliable than you'll be at counting asterisks at 11pm. But always verify with a tool or by checking the log after the first run. And remember cron uses the system timezone, which on a fresh VPS is often UTC, not Europe/London. That's a classic source of "why did my backup run at 3:30am" confusion during British Summer Time.

Two more cron prompts worth saving:

• Add flock locking to this cron job so it can't overlap if a run takes longer than expected.
• Rewrite this crontab entry to use a systemd timer instead, and explain the trade-offs.

That second one is genuinely useful — systemd timers log properly, handle dependencies, and are easier to debug than cron. For anything important, they're usually the better choice on modern Linux.

If you'd rather skip the prompt-crafting entirely, the Home Lab & Automation Pack collects ready-made AI prompts for exactly this kind of work — scripting, troubleshooting, documenting your setup — so you can paste, adapt and move on. It starts at £9, which is less than an hour of your evening spent fighting cron.

Make it document itself

The final prompt, and the one people forget: Add a header comment block to this script explaining what it does, what it depends on, how to run it, and how to restore from the backup it creates. Then write a short README section for it.

Six months from now you will not remember why that script exists or what that one weird conditional does. A generated header block costs you nothing and saves you an hour. Ask for it every time.

You can also ask ChatGPT to convert the finished script into a plain-English explanation you can paste into your notes: Explain this script line by line as if to a beginner, in a numbered list. That's your documentation done.

The common thread across all of this: give context, work in stages, ask why, and always verify before you let anything delete a file. ChatGPT will write you a perfectly plausible bash script that quietly does the wrong thing — your job is to read it, understand it, and test it on a copy first. Do that, and you'll go from dreading the terminal to writing scripts that actually earn their keep.