Hi There! Hope you're doing well and still enjoying the ride — because I’ve got something exciting to share in this next part of my learning journey.

If you’ve been following along, you might remember the last blog where we explored how Linux works — not just memorizing commands, but understanding what’s happening under the hood. That was a big moment for me because it made Linux feel a little less intimidating and a lot more interesting.

Since then, I’ve been spending more time inside the terminal — creating files, setting permissions, checking logs… and doing it all over again.

Over time, a thought kept bubbling up:

“Is there a way to make this easier? Faster? Smarter?”

Turns out, there is — and that’s where shell scripting comes in.
It’s the answer to those repetitive tasks. A way to teach your system how to do something once, and let it take care of it from there.

And there is.
That “better way” is what we’re diving into today: Shell Scripting.

So in today’s blog, I’m inviting you to walk this path with me — from what shell scripting even is, to how to write your first script, and onto deeper topics like variables, conditionals, loops, and functions. But more importantly, I want to help you see why each of these things matters — especially if you're just getting started.

Let’s get into it.

What Is Automation (And Why Do We Care)?

Let’s zoom out for a moment.

When people hear the word automation, it often sounds like something reserved for seasoned DevOps engineers or enterprise-level workflows.

But in reality?
Automation just means reducing manual effort. That’s it.

And chances are, you're already doing it without even thinking:

• Setting an alarm once instead of doing it manually every morning → automation.

• Running a dishwasher instead of scrubbing every plate → automation.

• Using an email auto-reply → still automation.

At its core, automation is just about avoiding repetitive tasks — and that instinct is built into us. We look for shortcuts. We want efficiency.

Now take that same logic into your Linux terminal — whether it’s a VM on your laptop, an AWS instance, or a WSL session on Windows.

Suppose someone says:
“Print numbers from 1 to 10.”
You’d probably type:

echo 1  
echo 2  
echo 3  
...

Job done.

But what if they ask:
“Print numbers from 1 to 1000.”
or
“Create 500 folders.”
“Add 200 users.”

Doing this manually would be exhausting — not to mention slow and error-prone.

If you knew shell scripting — and you were Yoda — you could say:

It’s like teaching your Linux system how to do something once — and letting it take care of the rest. Whether it’s setting up files, managing users, cleaning up logs, or automating deployments, shell scripting gives you the power to say: “Hey Linux, do this — and please don’t make me do it again.”

But before we start writing scripts, it helps to understand where this all fits in — what the shell actually is, and how scripting plugs into the Linux ecosystem.

Let’s take a quick look.

A Quick Recap: Where Does Shell Scripting Fit into Linux?

Before we dive into writing scripts, it helps to know where this whole "shell scripting" thing actually lives inside the world of Linux.

Let’s go back to that basic structure we explored in the Linux blog:

+---------------------------------------------+
| User Applications (Vim, Docker, Nginx...)   |
+---------------------------------------------+
| Shell (Bash, Zsh, etc.)                     |
+---------------------------------------------+
| System Libraries & Utilities                |
+---------------------------------------------+
| Linux Kernel                                |
+---------------------------------------------+
| Hardware (CPU, RAM, Disk, etc.)             |
+---------------------------------------------+

Here’s how the layers work, from bottom to top:

• The hardware does the actual work — storing data, running processes.

• Above that is the Linux kernel, which speaks directly to the hardware.

• Then comes System Libraries and Utils

• Then comes the shell — Bash, Zsh, and others — translating human-readable commands into system-level instructions.

• And finally, we have applications like Vim, Docker, or Nginx, sitting on top of everything else.

Now here’s the powerful part: instead of typing commands one by one, what if you could save them in a file — and ask the shell to run them all in sequence?

That’s what shell scripting is at its core — a way to capture a sequence of commands and hand them off to the system to run for you. No more copy-pasting, no more doing the same thing every time.

Once that idea sinks in, scripting stops feeling like some advanced skill only power users need. It starts to feel like a natural next step — especially if you’ve already found yourself typing the same commands again and again.

So how do you actually start?

Fortunately, getting your first script up and running is easier than most people think. If you’ve got a terminal and a text editor — that’s all you need.

Let’s try it out.

Setting the Stage: Writing Your First Shell Script

There are plenty of text editors to choose from — nano for simplicity, gedit for a GUI, or vim if you want something lightweight and usually already installed.

Let’s start with vim.

In your terminal, type:

vim hello.sh

You’ll see a blank screen. Press i to begin writing, and type:

#!/bin/bash
echo "Hello, world!"

That first line is a shebang — #!/bin/bash. It tells Linux to use the Bash shell to run this file. Like choosing the right translator before giving instructions.

Now press Esc, then type :wq! and hit Enter to save and exit.

You’ve written your first script — but it won’t run just yet.

First, give it permission to execute:

chmod +x hello.sh

Then run it:

./hello.sh

And just like that, your script speaks.

It’s a small start, but now we’re ready to go deeper — to teach our scripts how to remember things, take input, and respond.

The moment your first script prints “Hello, world!” — you know it works. But one line of text isn’t why shell scripting exists.

What makes scripting powerful is its ability to adapt: to remember values, accept user input, make decisions, and repeat tasks without being told each time. That’s what turns a basic script into something reusable and smart.

Let’s walk through those building blocks — step by step.

Variables — Giving Scripts a Memory

Imagine you’re writing a greeting message. You want the script to say hello to different names. Instead of hardcoding the name every time, you store it in a variable — like a label stuck to a value.

name="Alice"

Now, anytime you want to reuse “Alice”, you just refer to $name.

Variables let you:

• Change values in one place and affect many lines

• Make your scripts cleaner and more flexible

• Avoid hardcoding, especially when working with filenames, paths, or usernames

You can even build new values from old ones:

greeting="Hello"
name="Bob"
echo "$greeting, $name"

This prints: Hello, Bob

It may not seem like much now, but once your script has multiple moving parts, using variables instead of repeating yourself will keep everything manageable.

Input — Asking Questions Inside a Script

Hardcoding values works — until it doesn’t.

What if you want your script to behave differently each time it runs, depending on who’s using it or what they want to do?

That’s where input comes in.

Using read, you can pause and wait for the user to respond.

echo "Enter your name:"
read name

Now the script waits, accepts what the user types, and stores it in the name variable — ready to be used anywhere.

This interaction makes scripts dynamic. They respond based on input rather than requiring manual edits every time.

Arguments — Passing Data from the Outside

While input (read) is great when you want a script to pause and ask the user something, it doesn’t always fit the situation — especially when you want your script to run automatically or be used by other scripts, tools, or systems.

That’s where arguments come in.

Arguments let you pass information directly when launching the script, without needing to pause and wait for input. It's like handing your script some quick facts right at the start, so it can get to work immediately.

Let’s see a simple example:

./greet.sh Bob

Here, greet.sh is your script, and Bob is the argument you’re passing in.

Inside the script, you can access this value using a special variable called $1.

#!/bin/bash
echo "Hello, $1!"

When you run it, the output will be:

Hello, Bob!

What’s happening here?

• $1 grabs the first argument passed to the script.

• If you pass more arguments, you can access them with $2, $3, and so on.

• $0 is reserved for the name of the script itself.

For example, a script to onboard a user might look like:

echo "Welcome, $1!"
echo "Department: $2"

Run it like this:

./onboard.sh Angela Accounting

And it outputs:

Welcome, Angela!
Department: Accounting

So far, we’ve explored how to make our scripts a little more flexible — using variables to store values, and read to interact with users directly. Then we took it a step further with arguments, which let us pass information into a script right when we run it — like saying, “Hey script, here’s everything you need, now go do your job.”

That alone opens up a whole new level of automation. Your script doesn’t have to pause and wait — it just picks up the values you give it and runs. Clean, fast, and adaptable.

But there’s still something missing.

What if your script needs to think?
What if it needs to check something before continuing?

Like:

• Does a folder already exist?

• Did the user forget to pass an argument?

• Is a service already running?

That’s where conditionals come in — they give your script the ability to make decisions on the fly, based on the current situation.

Let’s dive in.

Conditionals — Teaching Scripts to Decide

Now that your script remembers and listens, the next step is teaching it to think.

What if a folder already exists?
What if a user forgot to enter something?
What if a service is already running?

With conditionals, your script checks a situation and decides what to do.

The simplest form is:

if [[ condition ]]; then
   # do this
else
   # do that
fi

Let’s say a folder should only be created if it doesn’t already exist:

if [[ -d "logs" ]]; then
    echo "Folder already exists."
else
    mkdir logs
    echo "Folder created."
fi

Here’s what’s happening:

• -d "logs" checks if a directory named logs exists

• If it does, you skip creation

• If not, you create it

Scripts like this make your logic smarter. And hey —

But being smart isn’t just about making decisions…It’s also about avoiding repetition.

Because sometimes, the task at hand isn’t complicated — it’s just tedious.
Maybe you need to create 10 folders. Or send 50 emails. Or process 100 files.

That’s where loops come in — letting your script say:

“I know what to do. Just tell me how many times.”

Loops — Doing the Same Thing, the Smart Way

Scripts often need to do one task — many times. Think:

• Creating 10 folders

• Sending 5 emails

• Backing up every file in a folder

You could write the same command 10 times... or use a loop.

Let’s say you want to create folders named backup1 to backup5.

A loop does the trick:

for i in {1..5}; do
  mkdir "backup$i"
done

This runs mkdir five times — changing the number each time.

Loops save time, reduce repetition, and make your scripts shorter and smarter. Whether it's for backups, monitoring, or creating users in bulk — you'll use loops everywhere.

Wrapping Up — What Comes Next?

By now, scripting might feel a little less like “just code” and a bit more like talking to your system — teaching it how to handle the repetitive stuff for you. Of course, this is just the beginning. Shell scripting goes far beyond what we’ve covered — from error handling to advanced string operations, and even integration with cron jobs and cloud automation.

This blog was meant to plant those first seeds: understanding what scripting is, why we use it, and how even simple ideas — like input and loops — can make a difference.

I hope that by now, you’re starting to see them not just as lines of code or syntax — but as ideas.

From here, you can start building small tools of your own:

• A script that creates project folders

• A backup tool that zips and stores logs

• A script that checks if services are running

My focus throughout this post wasn’t just on how to write commands, but on why we write them. Because I believe once we understand the reasoning behind something, the learning becomes both easier and more purposeful.

But for now — just keep tinkering. Let the curiosity guide you.

Thanks for walking through this with me — and as always, happy scripting. 🐧