How I Learned Bash Scripting Faster with GitHub Copilot

The first scripts were simple system information scripts. They included commands to print uptime, memory usage, and disk usage. This was useful because it showed how Bash scripts are just a sequence of shell commands written in a reusable format.

#!/bin/bash

echo "System Information"
uptime
free -m
df -h

Even from a simple script like this, GitHub Copilot started suggesting additional sections such as CPU usage, network information, and running processes. That was the first time I saw how AI can speed up scripting when the structure is already clear.

I used Vagrant virtual machines for testing. Instead of manually copying scripts every time, I placed them in the synced folder. Inside the VM, the scripts became available through the /vagrant directory.

cd /vagrant
ls

This made the workflow much easier. I could edit the script in VS Code, save it, and then test it directly from the VM. It felt much closer to a real automation workflow than just writing shell commands in one local terminal.

One of the most useful features was selecting the entire script and asking Copilot to improve it according to development best practices. This was not only about getting a better script, but also about learning what a better script looks like.

A common improvement it suggested was this line:

set -euo pipefail

At first this looked small, but it is actually very important in Bash scripting.

• -e makes the script exit immediately if a command fails.
• -u stops the script when an undefined variable is used.
• pipefail makes a pipeline fail if any command inside it fails.

This taught me that production-style scripts should fail early instead of silently continuing in a broken state.

Another big improvement was using functions. Instead of repeating the same echo lines and setup blocks, I learned to group reusable tasks into functions.

log() {
  echo "########################"
  echo "$1"
  echo "########################"
}

install_dependencies() {
  log "Installing packages"
  yum install -y httpd wget unzip
}

With functions, the script became much easier to read. Each part had a clear purpose, and the main execution section simply called those functions in order.

main() {
  install_dependencies
  setup_webfiles
  start_service
}

main

This was one of the most useful structural lessons for me. Instead of writing one long script from top to bottom, I learned to think in blocks of responsibility.

I also learned that variable usage in Bash can be risky if you are not careful. For example, writing this is not ideal:

yum install $PACKAGE

A better version is:

yum install "$PACKAGE"

The double quotes help prevent word splitting and globbing issues. This may seem minor, but it can prevent weird bugs, especially when variables come from user input or contain spaces.

One great lesson was that scripts should not assume everything is valid. For example, a command like this can be dangerous:

cd $TEMP_DIR

If the variable is empty or the path is wrong, the script may continue running in the wrong location. The safer approach is:

cd "$TEMP_DIR" || exit 1

This means the script will stop immediately if it cannot change to the expected directory.

The same idea applies to checking files before using them:

if [ ! -f "$HOSTS_FILE" ]; then
  echo "Hosts file not found"
  exit 1
fi

Some older Bash syntax still works, but there are cleaner and more recommended ways to write things today. A good example is command substitution.

Older style:

DATE=`date`

Recommended style:

DATE=$(date)

The newer syntax is easier to read and better when commands become more complex.

When reading user input, I learned that this is not the safest form:

read name

A better version is:

read -r name

Using -r helps prevent backslashes from being interpreted in unexpected ways. This is one of those small improvements that makes input handling safer.

One of the most interesting parts of this learning journey was working with a remote setup script that could deploy changes to multiple machines. This was much closer to real DevOps work.

The script first read a list of hosts from a file and stored them in an array:

mapfile -t hosts < hosts.txt

Then it looped over each host:

for host in "${hosts[@]}"; do
  echo "Working on $host"
done

This was especially useful because I learned why arrays and loops matter in automation. Instead of repeating the same steps manually, the script can apply them server by server.

The remote deployment workflow used tools like scp and ssh. The basic idea was simple:

scp setup.sh user@$host:/tmp/
ssh user@$host "bash /tmp/setup.sh"

This means the automation script can copy another script to a remote machine and then run it there. That felt like an important shift from basic Bash practice to actual environment setup automation.

Another useful lesson was that not all Linux systems are the same. Package names and package managers may differ between Ubuntu and RPM-based systems.

if grep -qi ubuntu /etc/os-release; then
  PACKAGE="apache2"
else
  PACKAGE="httpd"
fi

This kind of operating system check makes scripts more flexible and reusable across environments.

One of the most impressive parts of the learning process was asking Copilot to generate a complete Tomcat setup project. The request included two setup scripts, one for Ubuntu and one for RPM-based systems, plus a deployment script that reads hosts from a file.

AI was able to generate a full project structure quickly, including a README and deployment flow. But the biggest lesson was not that AI can generate code. The real lesson was that I still needed to review it, question it, and test it in my VMs before trusting it.