Theory
Bundling commands into a program
So far you have typed commands one at a time. But the backup task, make a folder, copy files, timestamp them, is several commands you will run again and again. Typing them each time is tedious and error-prone.
The answer is a shell script: a text file containing those commands, which you run as a single program. This is where Linux turns from a set of commands into a programming environment. This lesson covers how to create a script, the one line that goes at the top, and the step beginners most often forget: making it executable.
Theory
Writing a script: editor and shebang
You create a script in a text editor in the terminal. nano is the friendly choice for beginners (on-screen hints, easy to save and quit); vi (or vim) is more powerful and found on every system, but modal and trickier to learn.
The first line of a script is special: the shebang, written #!/bin/bash. It tells the system which interpreter should run the file, here, Bash. After that, you write ordinary commands, one per line, exactly as you would type them. Save the file with a .sh name by convention, and you have a script.
Practical
A first script, and running it (verified)
# In nano, create backup.sh containing:
#!/bin/bash
echo "Backing up..."
# Back at the shell, a new file is NOT executable yet:
$ ls -l backup.sh
-rw-r--r-- 1 riya riya ... backup.sh # no x bits!
$ chmod +x backup.sh # add execute permission
$ ls -l backup.sh
-rwxr-xr-x 1 riya riya ... backup.sh # now executable
$ ./backup.sh # run it (note the ./)
Backing up...Watch out
The classic trap: chmod +x, and the ./
A brand-new script is created without execute permission (rw-r--r--). If you try to run it, you get 'Permission denied'. The fix is `chmod +x script.sh`, which adds the execute bit (linking straight back to the permissions lesson).
Also note you run it as `./script.sh`, with the leading ./. That says 'the script right here in this directory'. Without it, the shell looks only on its PATH and does not find your script. Two small steps, chmod +x, then ./, trip up nearly every beginner at least once.
Quiz
You just created backup.sh in nano and typed ./backup.sh , but got 'Permission denied'. What is the fix?
- Rename the file to backup.exe
- Run chmod +x backup.sh to add execute permission, then ./backup.sh again
- Reboot the server
- Add more commands to the script
Show the answer
Run chmod +x backup.sh to add execute permission, then ./backup.sh again
A new script is created without the execute bit (permissions rw-r--r--), so trying to run it gives 'Permission denied'. The fix is chmod +x backup.sh, which adds execute permission (turning it into rwxr-xr-x), after which ./backup.sh runs. Option A is wrong: Linux does not use .exe extensions; the execute permission, not the name, decides runnability. Option C is nonsense: a reboot does not change file permissions. Option D misses the point: the script's contents are irrelevant to the permission error; it simply is not marked executable yet. Remember the two-step ritual for a new script: chmod +x once, then run with ./.
Think first
Why must you type ./script.sh instead of just script.sh?
Commands like ls run without any ./ in front. Why does your own script need the ./ ? Then tap.
Show the answer
Because of how the shell FINDS commands, using a list of directories called the PATH, and your current directory is normally NOT on it. When you type ls, the shell searches the directories in PATH (like /bin and /usr/bin), finds ls there, and runs it. Your new script sits in your current directory, which is deliberately left OUT of PATH for security reasons, if the current directory were searched automatically, an attacker could drop a malicious file named like a common command into a folder and have you run it by accident. So to run a script in the current directory, you must tell the shell explicitly where it is, and ./ means 'right here in this directory' (recall . is the current directory). ./backup.sh therefore says 'run the backup.sh that is here', bypassing the PATH search. If you wanted to run it without the ./, you would either move it into a PATH directory (like /usr/local/bin) or add its directory to PATH. The ./ is a small safety feature, not a nuisance: it keeps the shell from silently running files just because you happen to be standing in their folder.
Summary
Key takeaways
- A shell script is a text file of commands run as a single program, ideal for repeated tasks like backups.
- Write scripts in an editor: nano (beginner-friendly) or vi/vim (powerful, on every system).
- The first line is the shebang, #!/bin/bash, naming the interpreter that runs the file.
- A new script is created without execute permission, so you must run chmod +x script.sh first.
- Run a script in the current directory as ./script.sh; the leading ./ says 'right here'.
- You need ./ because the current directory is not on PATH (a security choice), so the shell will not find the script otherwise.
- Memory hook: shebang at the top, chmod +x once, run with ./.