Tag: scripting

A Basic Improvement in My rsync Script

rsync is used for efficient file synchronization and backup. It copies only the differences between source and destination, saving time and bandwidth.

And it is preinstalled on Ubuntu.

I use rsync to back up some of my folders to external storage like this:

#!/bin/bash

rsync -avh --delete --progress /home/fakhri/Documents/LinguistWork/ /media/fakhri/32Gobkup/LinguistWork_backup/ && \
rsync -avh --delete --progress /home/fakhri/Documents/LinguistWork/ /media/fakhri/8GO/LinguistWork_backup/ && \
rsync -avh --delete --progress /home/fakhri/Documents/LinguistWork/ /media/fakhri/"SAMSUNG SSD"/LinguistWork_backup/ && \
rsync -avh --delete --progress /home/fakhri/Documents/LibreWriter/ /media/fakhri/"SAMSUNG SSD"/LibreWriter_backup/ && \
rsync -avh --delete --progress /home/fakhri/Documents/LibreWriter/ /media/fakhri/8GO/LibreWriter_backup/ && \
rsync -avh --delete --progress /home/fakhri/Documents/LibreWriter/ /media/fakhri/32Gobkup/LibreWriter_backup/ && \
rsync -avh --delete --progress /home/fakhri/Documents/LinguistWork/l10n  /media/fakhri/8GO/LinguistWork_backup/l10n 

As you can see, I use && and \.

• && is used to combine two bash commands and run the second command only if the first command succeeds (exits with status 0).
• \ is used for line continuation – it tells the shell that the command continues on the next line, making long commands more readable.

We could use ; instead of &&, but ; would run the second command regardless of whether the first command succeeded or failed. && is safer for backup operations because if the first backup fails, the second won’t run, preventing incomplete or corrupted backups.

The Improved Script with a Loop

The problem with my original approach is that I had to manually write a line for each external drive. If I added a new drive, I had to update the script. Also, if a drive wasn’t connected, rsync would still try to run and throw an error.

Here’s my improved script that automatically handles multiple drives and checks if they’re connected:

#!/bin/bash

# Define all four backup locations
DRIVES=("/media/fakhri/32Go" "/media/fakhri/8GO" "/media/fakhri/SAMSUNG SSD" "/media/fakhri/500Go")

for DRIVE in "${DRIVES[@]}"; do
    # Check if the drive is actually plugged in before starting
    if [ -d "$DRIVE" ]; then
        echo "-----------------------------------------------"
        echo "Backing up to: $DRIVE"
        echo "-----------------------------------------------"

        # Syncs the entire folder and all its subfolders
        rsync -avh --delete --progress "/home/fakhri/Documents/LinguistWork/" "$DRIVE/LinguistWork_backup/"
        rsync -avh --delete --progress "/home/fakhri/Documents/LibreWriter/" "$DRIVE/LibreWriter_backup/"
    else
        echo "Skipping $DRIVE (Drive not connected)"
    fi
done

echo "Backup process finished!"

DRIVES=("/media/fakhri/32Go" "/media/fakhri/8GO" "/media/fakhri/SAMSUNG SSD" "/media/fakhri/500Go")

Array definition. Creates an array variable named DRIVES containing four paths (one per drive). The parentheses () define an array, and each quoted string is an element. Using an array allows us to loop through all drives without repeating code.

for DRIVE in "${DRIVES[@]}"; do

The Very Important Symbol: [@]

The critically important symbol is [@] (at-sign with brackets).

Why [@] is So Important

What it does:

${DRIVES[@]} expands to all elements of the array DRIVES, with each element treated as a separate word.

The Danger of NOT using [@]

If you wrote this incorrectly as:

for DRIVE in ${DRIVES[@]}; do   # Missing quotes - WRONG!

Or worse:

for DRIVE in $DRIVES; do        # Just wrong - treats array as single string

Here’s what happens with a drive path containing spaces, like "/media/fakhri/SAMSUNG SSD":

The Three Array Expansion Options Compared

The Golden Rule

Always use "${ARRAY[@]}" with quotes when iterating over arrays containing file paths.

The quotes + [@] combination ensures:

1. Each array element stays intact (spaces preserved)
2. Empty elements are preserved
3. Special characters (like * or ?) are not expanded

Without this, your backup script will fail silently and try to write to completely wrong locations!

Every Important Symbol Explained

Here’s the breakdown of every critical symbol in these lines:

if [ -d "$DRIVE" ]; then
    # ... backup commands ...
else
    echo "Skipping $DRIVE (Drive not connected)"
fi
done

if [ -d "$DRIVE" ]; then

else

echo "Skipping $DRIVE (Drive not connected)"

fi

done

The Most Critical Symbol: [ ] (Test Command)

The brackets [ ] are NOT syntax – they are a command!

Mental model:

if [ -d "$DRIVE" ]; then

Is equivalent to:

if test -d "$DRIVE"; then

The [ command is just an alias for test that requires a closing ].

Common Mistakes with [ ]:

Symbol Hierarchy in Context

if [ -d "$DRIVE" ]; then
│  │ │ │        │  │
│  │ │ │        │  └── ends the "then" block start
│  │ │ │        └── separates test from "then"
│  │ │ └── variable expands to actual path
│  │ └── tests if path is a directory
│  └── starts test command
└── begins conditional

then
│
└── marks true block

else
│
└── marks false block

echo "Skipping $DRIVE (Drive not connected)"
│    │                    │
│    │                    └── variable inside quotes expands
│    └── quotes keep everything as one argument
└── prints to terminal

fi
│
└── closes if

done
│
└── closes for loop

Quick Reference Card

The most important takeaway: [ ] needs spaces inside and outside, and always quote your variables inside tests!

Final Note: Use [[ ]] Instead of [ ]

For Bash scripts, the double-bracket [[ ]] is superior to the single-bracket [ ] used in this article. Unlike [ ] (a command that requires spaces and quoted variables), [[ ]] is a Bash keyword that prevents word splitting and pathname expansion. This means you can write [[ -d $DRIVE ]] without quotes, even if the path contains spaces. [[ ]] also supports pattern matching (== *.txt), regex matching (=~), and natural logical operators (&&, ||). Stick with [ ] only if you need portability to other shells like sh; otherwise, always prefer [[ ]] for cleaner, safer, and more readable conditional tests.

To see why exit 1 and exit 0 are so important, we have to look at what happens when a script lies to the computer.

If you omit them, Bash simply reports the exit status of the very last command that ran. This can lead to a “False Success.”

1. The “Broken” Script (No Exit Codes)

Save this as broken_backup.sh. Notice there is no exit 1.

Bash

#!/bin/bash

# We pretend to check for a folder that DOES NOT exist
if [ ! -d "/folder/does/not/exist" ]; then
    echo "ERROR: Folder missing!"
    # We forgot to write 'exit 1' here!
fi

# This is the last command. It will always succeed.
echo "Backup process finished."

2. The “Good” Script (With Exit Codes)

Save this as good_backup.sh.

Bash

#!/bin/bash

if [ ! -d "/folder/does/not/exist" ]; then
    echo "ERROR: Folder missing!"
    exit 1  # Stop and report failure
fi

echo "Backup process finished."
exit 0

3. How to Test Them (The “Truth” Test)

Run these commands in your terminal one after the other. We will use the && operator, which only runs the second command if the first one reports Success (0).

Testing the Broken Script:

Bash

bash broken_backup.sh && echo "THE COMPUTER THINKS WE SUCCEEDED! ✅"

Result: Even though the script printed “ERROR,” the computer saw the final echo succeeded, so it ran the “SUCCEEDED” message. This is dangerous because a backup could fail and you wouldn’t know!

Testing the Good Script:

Bash

bash good_backup.sh && echo "THE COMPUTER THINKS WE SUCCEEDED! ✅" || echo "THE COMPUTER DETECTED THE FAILURE! ❌"

Result: The script stops at exit 1. The computer sees the 1, skips the && part, and triggers the || (failure) part.

Here are the results as copied from my terminal:

fakhri@ThinkAct:~/Documents/LibreWriter/scripts$ ./badtestexit.sh 
ERROR: Folder missing!
Backup process finished.
fakhri@ThinkAct:~/Documents/LibreWriter/scripts$ ./goodtestexit.sh 
ERROR: Folder missing!

Why this matters in the real world

Imagine you have a script that:

1. Deletes your old files.
2. Copies your new files (The Backup).
3. Cleans up the temporary folder.

If Step 2 (The Backup) fails because the disk is full, but you didn’t write exit 1, the script will continue to Step 3 and delete your only remaining copies, thinking everything is fine!

Summary: * With exit 1: The script “screams” when there is a problem.

• Without it: The script “whispers” an error but smiles at the computer, pretending everything is perfect.

Note: about the use of “bash” at the start of the command below:

bash good_backup.sh && echo "THE COMPUTER THINKS WE SUCCEEDED! ✅" || echo "THE COMPUTER DETECTED THE FAILURE! ❌"

1. Manual Interpreter: Typing bash before your filename manually tells the system to use the Bash program to translate and run your script’s code.

2. Bypasses Permissions: It allows you to execute a script immediately without needing to set “executable” permissions via chmod +x.

3. Ensures Compatibility: It guarantees the script runs in the full Bash environment rather than a limited shell (like sh) that might misunderstand your syntax.

4. Testing Logic: It is the most reliable way to test if your exit 0 and exit 1 codes are working correctly before finalizing the script for automation.