Writing Your First Shell or Batch Script

What a script is

A script is a plain text file containing commands that you would otherwise type one at a time. When you run the file, the computer carries out the commands in order. That is all. If you can type a command, you can put it in a script, and if you can put it in a script, you can run it again tomorrow without retyping it.

Two families are common for beginners:

• Shell scripts run on Linux and macOS, and also on Windows with suitable tools installed. They are written for a program called a shell, which interprets typed commands.
• Batch files run on Windows through its older command prompt. They usually end in .bat or .cmd.

Windows also has a more capable scripting environment of its own, and many people use it for serious work, but a batch file is a gentle first step. The concepts here, such as variables, conditions and loops, carry over to every scripting language.

If you are not yet comfortable typing commands, spend a little time on command line basics first. A script is only as good as your understanding of each command inside it.

Pick a small, useful task

A good first script does something you already do by hand and which is low risk. Some ideas:

• Create a dated folder to hold today’s files.
• Copy a set of files to another location.
• List files older than a certain age, without deleting them.
• Display disk space and a few details about the machine.
• Check whether a handful of servers respond.

Resist starting with something that deletes or changes many files. Reading and reporting are the safest ways to learn.

A first shell script

Here is a small script for Linux or macOS that copies a folder into a dated backup location. The folder names are examples; change them to suit your machine.

#!/bin/bash
#Copy the Documents folder into a dated folder under Backups

source_dir="$HOME/Documents"
today=$(date +%Y-%m-%d)
target_dir="$HOME/Backups/documents-$today"

mkdir -p "$target_dir"
cp -r "$source_dir/." "$target_dir"

echo "Copied $source_dir to $target_dir"

Going through it line by line:

• The first line, beginning with #!, tells the system which program should run the file.
• Lines starting with # are comments. They are ignored by the computer and written for humans. Use them generously.
• source_dir=... creates a variable, a named place to store a value. Using a variable means you only need to change the folder in one place.
• $(date +%Y-%m-%d) runs the date command and stores its output, such as 2026-10-29, in the variable today.
• mkdir -p makes the target folder, and does not complain if it already exists.
• cp -r copies files and folders recursively.
• echo prints a message so you can see what happened.

To run it, save it as backup.sh, give it permission to run with chmod +x backup.sh, and start it with ./backup.sh.

The same idea as a batch file

On Windows, a batch file doing something similar might look like this:

@echo off
rem Copy the Documents folder into a dated folder under Backups

set source=%USERPROFILE%\Documents
set target=%USERPROFILE%\Backups\documents-copy

mkdir "%target%"
xcopy "%source%" "%target%" /E /I

echo Copied %source% to %target%

Here rem marks a comment, set creates a variable that is used by wrapping its name in percent signs, and xcopy copies files. Building a date into the folder name is possible but is fiddly in a batch file, and it depends on regional date settings, so this example keeps a fixed name. That awkwardness is one reason people move to richer scripting tools as their needs grow.

The building blocks

Almost every script uses the same few ideas.

Variables store values for reuse.

Conditions let a script make decisions: if a folder exists, do one thing, otherwise do another. This is how you add checks, such as stopping if the source folder is missing.

Loops repeat actions, for example for each file in a folder or each server in a list.

Arguments let you pass values when you run the script, so one script can handle different inputs without being edited.

Exit codes are small numbers that commands return to say whether they succeeded. Checking them lets a script stop when something fails instead of plowing on.

Testing safely

Scripts do exactly what they are told, including the wrong thing, very quickly. Some habits protect you.

• Test on copies or in a scratch folder. Never try a new script on real data first.
• Print before you act. Start by displaying the files or commands the script would use, and look at them. Only then add the part that changes things.
• Be extremely careful with delete commands, especially with variables. If a variable is empty by mistake, a command can end up pointing at somewhere much bigger than you intended. Check that variables hold what you expect before using them.
• Use quotes around paths, since names containing spaces are a common source of bugs.
• Do not run unfamiliar scripts from the internet without reading them. Treat a script as a program with all your permissions.
• Avoid administrator rights unless the task truly needs them.

If your script will run unattended later, think about which account it runs under. Dedicated service accounts with limited permissions are better than a personal administrator account.

Common beginner mistakes

• Forgetting the permission to run the file, or running it from the wrong folder, so relative paths point at the wrong place.
• Mixing up the styles of the two families, such as using $variable in a batch file.
• Editing a file with a word processor, which can insert special characters. Use a plain text editor.
• Writing no comments, then not understanding the script a month later.
• Ignoring errors, so that a failed first step is followed by steps that make things worse.

When something goes wrong, read the error message carefully, then simplify: run the commands one at a time, as a method of troubleshooting, to find the line that fails.

Where to go next

Once a script works, keep it in a known place, ideally under version control, and add a comment at the top saying what it does. Schedule it to run at a set time if that suits the task. As scripts grow, you may find a general-purpose language, such as the one in Python basics, easier to manage than a long shell or batch file.

Start with one small, useful script and improve it a little each time you use it. That steady habit is the real beginning of automating repetitive tasks.