← Back to course

Your First Bash Script

Your First Bash Script

Welcome back.

In the previous lesson, you learned about environment variables, aliases, and shell basics.

Now it is time to make the terminal do more than one thing at a time.

We are going to write a script.

A script is basically a small file with commands inside.

Instead of typing the same commands again and again like a very obedient robot, you write them once and run them whenever you want.

This is where the terminal starts working for you.

Finally.

What You’ll Learn

In this lesson, you’ll learn how to:

The Mission

Your mission is simple:

Create your first Bash script, run it, improve it, and make it useful.

Not huge.

Not scary.

Just a small automation.

A tiny terminal servant.

But ethical.

What Is a Script?

A script is a text file that contains commands.

For example, instead of typing:

pwd
ls
date

you can put those commands in a file and run them together.

That file becomes your script.

Scripts are useful for:

Boring tasks are not a punishment.

They are a target.

Create a Scripts Folder

Go to your practice folder:

cd ~/terminal-practice

If it does not exist, create it:

mkdir -p ~/terminal-practice
cd ~/terminal-practice

Create a folder for scripts:

mkdir scripts
cd scripts

Now we have a clean place to work.

A clean folder is like a clean desk.

Rare, suspicious, but very useful.

Create Your First Script

Create a file called hello.sh:

nano hello.sh

Add this content:

#!/usr/bin/env bash

echo "Hello from my first Bash script!"
echo "Today I am learning automation."
echo "The current date is:"
date

Save and exit.

In nano:

Understanding the Shebang

The first line is:

#!/usr/bin/env bash

This is called a shebang.

It tells Linux which program should run the script.

In this case, it says:

Use Bash to run this file.

Without the shebang, the script may still work sometimes, but it is better to be explicit.

The terminal appreciates clarity.

It has enough drama already.

Try to Run the Script

Try:

./hello.sh

You may see:

Permission denied

That is normal.

The file exists, but Linux does not know yet that it is allowed to execute it.

Linux does not trust random files immediately.

Honestly, that is a healthy attitude.

Make the Script Executable

Add execute permission:

chmod +x hello.sh

Now run it again:

./hello.sh

You should see:

Hello from my first Bash script!
Today I am learning automation.
The current date is:
...

Congratulations.

You wrote and ran your first Bash script.

The terminal has officially started doing your boring work.

A historic moment.

Probably no fireworks.

But still historic.

Use Variables in a Script

Create a new script:

nano info.sh

Add:

#!/usr/bin/env bash

name="Viktor"
course="Linux Terminal"

echo "Hello, $name!"
echo "Welcome to the $course course."
echo "Your current directory is:"
pwd

Make it executable:

chmod +x info.sh

Run it:

./info.sh

Variables in scripts work like variables in the shell.

But remember:

name="Viktor"

is correct.

This is wrong:

name = "Viktor"

No spaces around =.

Bash sees spaces and immediately begins emotional damage.

Use Arguments

Scripts can receive arguments.

Create:

nano greet.sh

Add:

#!/usr/bin/env bash

name="$1"

echo "Hello, $name!"

Make it executable:

chmod +x greet.sh

Run it with an argument:

./greet.sh Viktor

You should see:

Hello, Viktor!

$1 means “the first argument”.

Try:

./greet.sh Linux

You should see:

Hello, Linux!

Your script is now flexible.

Not genius yet.

But flexible.

Multiple Arguments

Create:

nano introduce.sh

Add:

#!/usr/bin/env bash

name="$1"
language="$2"

echo "Hello, my name is $name."
echo "I am learning $language."

Make it executable:

chmod +x introduce.sh

Run:

./introduce.sh Viktor Bash

You should see:

Hello, my name is Viktor.
I am learning Bash.

$1 is the first argument.

$2 is the second argument.

Bash counts arguments like a strict accountant with no coffee break.

Check If an Argument Exists

What happens if someone runs your script without an argument?

Try:

./greet.sh

You may see:

Hello, !

Not beautiful.

Let’s fix that.

Edit greet.sh:

nano greet.sh

Replace the content with:

#!/usr/bin/env bash

name="$1"

if [ -z "$name" ]; then
  echo "Please provide a name."
  echo "Example: ./greet.sh Viktor"
  exit 1
fi

echo "Hello, $name!"

Run:

./greet.sh

Now it gives a useful message.

Run:

./greet.sh Viktor

Now it works normally.

Good scripts explain what went wrong.

Bad scripts fail silently and leave you staring at the screen like a confused potato.

Understanding the if Statement

This part checks if name is empty:

if [ -z "$name" ]; then

-z means “is empty”.

So this means:

If the variable name is empty, then do something.

This line ends the condition:

fi

In Bash, if ends with fi.

Yes, it is if backwards.

Bash has jokes.

Dry jokes, but jokes.

Create a Simple Backup Script

Now let’s create something more useful.

Create:

nano backup-practice.sh

Add:

#!/usr/bin/env bash

source_dir="$1"
backup_dir="$2"

if [ -z "$source_dir" ] || [ -z "$backup_dir" ]; then
  echo "Usage: ./backup-practice.sh SOURCE_DIR BACKUP_DIR"
  echo "Example: ./backup-practice.sh ~/terminal-practice ~/backup"
  exit 1
fi

mkdir -p "$backup_dir"

archive_name="backup-$(date +%Y-%m-%d-%H-%M-%S).tar.gz"

tar -czf "$backup_dir/$archive_name" "$source_dir"

echo "Backup created:"
echo "$backup_dir/$archive_name"

Make it executable:

chmod +x backup-practice.sh

Run it:

./backup-practice.sh ~/terminal-practice ~/terminal-backups

Check:

ls ~/terminal-backups

You should see a .tar.gz backup.

Now we are automating.

This is where the terminal begins to look dangerous in a good way.

Common Mistakes

Forgetting the executable permission

If you see:

Permission denied

run:

chmod +x script-name.sh

Then try again.

Forgetting ./

This may not work:

hello.sh

Use:

./hello.sh

./ means “run the script from the current directory”.

The shell does not automatically run files from the current folder unless you tell it clearly.

The shell is powerful, but not your babysitter.

Forgetting quotes around variables

This is risky:

mkdir -p $backup_dir

This is better:

mkdir -p "$backup_dir"

Quotes protect paths with spaces.

Even if you avoid spaces like a wise person, quotes are a good habit.

Editing but not saving

If nothing changes, maybe you forgot to save the file.

It happens.

Nano does not read your mind.

Neither does Bash.

Neither does your cat.

Practice

Create and run these scripts:

hello.sh
info.sh
greet.sh
introduce.sh
backup-practice.sh

Then answer:

  1. What is a Bash script?
  2. What does the shebang line do?
  3. Why do we use chmod +x?
  4. What does $1 mean?
  5. What does -z check?
  6. Why should variables be quoted?

Mini Challenge

Create a script called project-info.sh.

It should:

  1. Print your username.
  2. Print the current directory.
  3. Print the current date.
  4. List files in the current directory.
  5. Accept one argument: project name.
  6. If no project name is provided, show a helpful error message.

Example usage:

./project-info.sh innomarts-platform

Example output:

Project: innomarts-platform
User: viktor
Current directory: /home/viktor/terminal-practice/scripts
Date: ...
Files:
...

No mouse.

The mouse now works only as a historical artifact.

Summary

Today you learned:

This is a big step.

You are no longer just using commands.

You are combining commands into tools.

That is how automation begins.

Tiny script today.

DevOps wizard tomorrow.

Maybe.

With enough coffee.

Next Lesson

In the next lesson, we’ll learn how to combine commands with pipes, redirects, and command chaining.

That is where small commands become powerful workflows.