DEV Community: Malhar Gupte

Shell Scripting for Beginners: Control Flow, Functions and Real Automation (Part 2)

Malhar Gupte — Fri, 13 Mar 2026 05:41:18 +0000

Series: Shell Scripting for Beginners | Part: 2 of 2
Level: Beginner–Intermediate | Time to read: ~18 minutes
Part 1: Shell Scripting for Beginners: From Zero to Automating Your First Tasks

Quick Recap of Part 1

In Part 1, we covered the building blocks:

Writing and running your first script (chmod +x, ./script.sh)
The shebang line (#!/bin/bash) and what it does
Variables, curly brace syntax, and command substitution
Passing arguments with $1, $2, $#
Reading user input with read and read -p
Arithmetic using $(( ))

If any of that sounds unfamiliar, go through Part 1 first — everything in this article builds on it.

In Part 2, we're adding the logic layer. By the end of this, your scripts will be able to make decisions, repeat tasks, handle errors, and be structured enough that you'd actually want to maintain them.

Let's get into it.

Conditional Logic (if Statements)

A script that just runs commands top to bottom is useful. A script that can decide what to do based on conditions is powerful.

Basic `if`

#!/bin/bash

age=20

if [ $age -ge 18 ]; then
  echo "You're an adult."
fi

The structure is always:

if [ condition ]; then
  # commands to run if condition is true
fi

The spaces inside [ ] are not optional. [$age -ge 18] will fail. Always write [ $age -ge 18 ] with spaces.

`if-else`

#!/bin/bash

read -p "Enter your age: " age

if [ $age -ge 18 ]; then
  echo "Access granted."
else
  echo "Access denied. Come back in a few years."
fi

`if-elif-else`

#!/bin/bash

read -p "Enter your score: " score

if [ $score -ge 90 ]; then
  echo "Grade: A"
elif [ $score -ge 75 ]; then
  echo "Grade: B"
elif [ $score -ge 60 ]; then
  echo "Grade: C"
else
  echo "Grade: F — study harder."
fi

Comparison Operators

Bash uses different operators for numbers and strings — this trips people up constantly.

For numbers:

Operator	Meaning
`-eq`	equal to
`-ne`	not equal to
`-gt`	greater than
`-lt`	less than
`-ge`	greater than or equal
`-le`	less than or equal

For strings:

Operator	Meaning
`=`	equal
`!=`	not equal
`-z`	is empty
`-n`	is not empty

#!/bin/bash

name="Malhar"

if [ "$name" = "Malhar" ]; then
  echo "Hey, I know you."
fi

if [ -z "$name" ]; then
  echo "Name is empty."
else
  echo "Name is: $name"
fi

For files and directories:

Operator	Meaning
`-f`	file exists
`-d`	directory exists
`-e`	file or directory exists
`-r`	file is readable
`-w`	file is writable
`-x`	file is executable

#!/bin/bash

if [ -f "/etc/passwd" ]; then
  echo "File exists."
fi

if [ -d "/tmp" ]; then
  echo "/tmp directory exists."
fi

Tip: Always quote your variables inside [ ]. Write [ "$name" = "Malhar" ], not [ $name = "Malhar" ]. If $name is empty or has spaces, the unquoted version breaks.

Double Brackets `[[ ]]`

Bash also supports [[ ]] — a more modern, forgiving syntax that handles edge cases better:

#!/bin/bash

name="Malhar Gupte"

# This works safely with spaces in the variable
if [[ $name == *"Malhar"* ]]; then
  echo "Name contains Malhar"
fi

[[ ]] also supports && and || directly inside it, while [ ] doesn't. Once you're comfortable with the basics, prefer [[ ]] for new scripts.

For Loops

When you need to repeat something a fixed number of times or iterate over a list — that's a for loop.

Looping Through a List of Values

#!/bin/bash

for language in Python Bash Java Go Rust; do
  echo "Language: $language"
done

Output:

Language: Python
Language: Bash
Language: Java
Language: Go
Language: Rust

Looping Through a Number Range

#!/bin/bash

for i in {1..5}; do
  echo "Iteration: $i"
done

Or with a step:

for i in {0..20..5}; do
  echo "$i"   # 0, 5, 10, 15, 20
done

C-Style For Loop

#!/bin/bash

for ((i=1; i<=5; i++)); do
  echo "Count: $i"
done

Looping Through Files

This is where for loops get genuinely useful:

#!/bin/bash

# Loop through all .log files in a directory
for file in /var/log/*.log; do
  echo "Processing: $file"
  echo "Size: $(du -sh "$file" | cut -f1)"
done

Practical Example: Batch Rename Files

#!/bin/bash

# Add a "backup_" prefix to all .txt files in current directory
for file in *.txt; do
  mv "$file" "backup_${file}"
  echo "Renamed: $file → backup_${file}"
done

Tip: Always test loops with echo first before running destructive commands like mv, rm, or cp. Replace the actual command with echo "would run: mv $file ..." and verify the output looks right.

While Loops

while loops keep running as long as a condition is true. They're perfect when you don't know in advance how many iterations you need.

Basic While Loop

#!/bin/bash

count=1

while [ $count -le 5 ]; do
  echo "Count: $count"
  ((count++))
done

Output:

Count: 1
Count: 2
Count: 3
Count: 4
Count: 5

Reading a File Line by Line

One of the most common uses of while in real scripts:

#!/bin/bash

while IFS= read -r line; do
  echo "Line: $line"
done < /etc/hosts

IFS= prevents leading/trailing whitespace from being stripped. -r prevents backslashes from being interpreted. Both are good habits.

Waiting for Something to Happen

#!/bin/bash

echo "Waiting for server to come online..."

while ! curl -s http://localhost:8080 > /dev/null; do
  echo "Not ready yet. Retrying in 3 seconds..."
  sleep 3
done

echo "Server is up!"

This kind of loop is legitimately useful in deployment scripts where you need to wait for a service to start before proceeding.

Tip: Always make sure your while loop has a way to end. A missing increment or a condition that never becomes false will give you an infinite loop that you'll have to kill with Ctrl+C.

Case Statements

When you have one variable and multiple possible values to check against, case is far cleaner than a chain of if-elif statements.

The Problem `case` Solves

Imagine checking what day of the week it is:

# Verbose and repetitive with if-elif
if [ "$day" = "Monday" ]; then
  ...
elif [ "$day" = "Tuesday" ]; then
  ...
elif [ "$day" = "Wednesday" ]; then
  ...

With case:

#!/bin/bash

read -p "Enter day: " day

case $day in
  Monday)
    echo "Start of the week. Let's go." ;;
  Tuesday | Wednesday | Thursday)
    echo "Mid-week grind." ;;
  Friday)
    echo "Almost there." ;;
  Saturday | Sunday)
    echo "Weekend. Close the laptop." ;;
  *)
    echo "That's not a valid day." ;;
esac

Each pattern ends with ), the commands end with ;;, and *) is the catch-all default (like else). The block ends with esac — that's case backwards, a classic Unix move.

Practical Example: Script Menu

#!/bin/bash

echo "==============================="
echo "     Server Management Menu"
echo "==============================="
echo "1) Check disk usage"
echo "2) Check memory usage"
echo "3) List running processes"
echo "4) Exit"
echo ""

read -p "Choose an option: " option

case $option in
  1)
    df -h ;;
  2)
    free -h ;;
  3)
    ps aux | head -20 ;;
  4)
    echo "Goodbye."
    exit 0 ;;
  *)
    echo "Invalid option." ;;
esac

This kind of menu-driven script is a pattern you'll see all over real DevOps tooling.

Exit Codes

Every command you run in a terminal exits with a number. That number is the exit code, and it tells you whether the command succeeded or failed.

0 = success
Any non-zero value = failure (the specific number often indicates the type of error)

Checking `$?`

$? holds the exit code of the last command that ran:

#!/bin/bash

ls /tmp
echo "Exit code: $?"   # 0 — /tmp exists

ls /nonexistent_directory
echo "Exit code: $?"   # 2 — directory not found

Using Exit Codes in Conditionals

#!/bin/bash

ping -c 1 google.com > /dev/null 2>&1

if [ $? -eq 0 ]; then
  echo "Internet is up."
else
  echo "No internet connection."
fi

Or more concisely — you can use the command directly in the if:

#!/bin/bash

if ping -c 1 google.com > /dev/null 2>&1; then
  echo "Internet is up."
else
  echo "No internet connection."
fi

Setting Exit Codes in Your Scripts

When writing scripts that other scripts or tools will call, always set meaningful exit codes:

#!/bin/bash

backup_file="/backups/db.sql"

if [ ! -f "$backup_file" ]; then
  echo "ERROR: Backup file not found." >&2
  exit 1
fi

echo "Backup file found. Proceeding..."
exit 0

>&2 redirects error messages to stderr instead of stdout — the right place for errors. exit 1 signals failure to whatever called your script.

Tip: In CI/CD pipelines, exit codes are everything. A script that exits with 0 tells the pipeline "all good, move on." A non-zero exit code stops the pipeline and flags the step as failed. Always think about your exit codes when writing automation scripts.

Functions in Bash

Once your scripts get longer than 30-40 lines, repeating the same blocks of code starts to hurt. Functions let you name a block of code and call it whenever you need it.

Defining and Calling a Function

#!/bin/bash

greet() {
  echo "Hello, $1!"
}

greet "Malhar"
greet "World"

Output:

Hello, Malhar!
Hello, World!

The function is defined first, then called by name. Arguments passed to the function are available as $1, $2, etc. — just like script arguments, but scoped to the function.

A More Realistic Function

#!/bin/bash

log() {
  local level=$1
  local message=$2
  local timestamp=$(date "+%Y-%m-%d %H:%M:%S")
  echo "[$timestamp] [$level] $message"
}

log "INFO"  "Script started."
log "INFO"  "Checking disk usage..."
log "WARN"  "Disk usage above 80%."
log "ERROR" "Backup directory not found."

Output:

[2025-03-10 10:42:01] [INFO] Script started.
[2025-03-10 10:42:01] [INFO] Checking disk usage...
[2025-03-10 10:42:01] [WARN] Disk usage above 80%.
[2025-03-10 10:42:01] [ERROR] Backup directory not found.

This log function is something you'd actually copy into real scripts.

`local` Variables

Notice the local keyword. Variables inside functions are global by default in Bash, which can cause bugs in longer scripts. Declaring them with local keeps them scoped to the function:

#!/bin/bash

count=10   # global

increment() {
  local count=0   # local — doesn't touch the global $count
  ((count++))
  echo "Inside function: $count"
}

increment
echo "Outside function: $count"

Output:

Inside function: 1
Outside function: 10

Functions with Return Values

Bash functions don't return values the way other languages do. They return exit codes (0-255). To "return" a value, you either echo it and capture it with $(), or use a global variable:

#!/bin/bash

get_disk_usage() {
  local path=${1:-"/"}
  df -h "$path" | awk 'NR==2 {print $5}' | tr -d '%'
}

usage=$(get_disk_usage "/")
echo "Disk usage on /: ${usage}%"

if [ "$usage" -gt 80 ]; then
  echo "Warning: disk usage is high."
fi

Real Automation Script: System Health Check

Let's put everything together — conditionals, loops, functions, exit codes — into something you'd actually run on a server.

This script performs a basic system health check and prints a summary report.

#!/bin/bash

# ─────────────────────────────────────────────────────
# system_health_check.sh
# Checks disk, memory, CPU load, and running services
# Usage: ./system_health_check.sh
# ─────────────────────────────────────────────────────

# ── Thresholds ────────────────────────────────────────
DISK_THRESHOLD=80
MEM_THRESHOLD=85
SERVICES=("nginx" "ssh")

# ── Colors (optional but makes output readable) ───────
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m'   # No Color (reset)

# ── Logging Function ──────────────────────────────────
log() {
  local level=$1
  local message=$2
  local timestamp=$(date "+%Y-%m-%d %H:%M:%S")

  case $level in
    INFO)  echo -e "${GREEN}[$timestamp] [INFO]${NC}  $message" ;;
    WARN)  echo -e "${YELLOW}[$timestamp] [WARN]${NC}  $message" ;;
    ERROR) echo -e "${RED}[$timestamp] [ERROR]${NC} $message" ;;
  esac
}

# ── Check Disk Usage ──────────────────────────────────
check_disk() {
  log "INFO" "Checking disk usage..."

  while IFS= read -r line; do
    usage=$(echo "$line" | awk '{print $5}' | tr -d '%')
    mount=$(echo "$line" | awk '{print $6}')

    if [ "$usage" -ge "$DISK_THRESHOLD" ]; then
      log "WARN" "Disk usage on $mount is at ${usage}% — above threshold of ${DISK_THRESHOLD}%"
    else
      log "INFO" "Disk usage on $mount: ${usage}% — OK"
    fi
  done < <(df -h | awk 'NR>1 && $1 ~ /^\/dev/')
}

# ── Check Memory Usage ────────────────────────────────
check_memory() {
  log "INFO" "Checking memory usage..."

  local total=$(free | awk '/^Mem:/ {print $2}')
  local used=$(free | awk '/^Mem:/ {print $3}')
  local usage=$(( used * 100 / total ))

  if [ "$usage" -ge "$MEM_THRESHOLD" ]; then
    log "WARN" "Memory usage is at ${usage}% — above threshold of ${MEM_THRESHOLD}%"
  else
    log "INFO" "Memory usage: ${usage}% — OK"
  fi
}

# ── Check CPU Load ────────────────────────────────────
check_cpu() {
  log "INFO" "Checking CPU load..."

  local load=$(uptime | awk -F'load average:' '{print $2}' | awk -F',' '{print $1}' | xargs)
  log "INFO" "1-minute load average: $load"
}

# ── Check Services ────────────────────────────────────
check_services() {
  log "INFO" "Checking critical services..."

  for service in "${SERVICES[@]}"; do
    if systemctl is-active --quiet "$service" 2>/dev/null; then
      log "INFO" "Service [$service] is running — OK"
    else
      log "ERROR" "Service [$service] is NOT running!"
    fi
  done
}

# ── Main ──────────────────────────────────────────────
main() {
  echo ""
  echo "=============================================="
  echo "       System Health Check"
  echo "       $(date)"
  echo "       Host: $(hostname)"
  echo "=============================================="
  echo ""

  check_disk
  echo ""
  check_memory
  echo ""
  check_cpu
  echo ""
  check_services

  echo ""
  echo "=============================================="
  echo "  Health check complete."
  echo "=============================================="
  echo ""
}

main
exit 0

Make it executable and run it:

chmod +x system_health_check.sh
./system_health_check.sh

Sample output:

==============================================
       System Health Check
       Mon Mar 10 10:45:01 IST 2025
       Host: dev-server
==============================================

[2025-03-10 10:45:01] [INFO]  Checking disk usage...
[2025-03-10 10:45:01] [INFO]  Disk usage on /: 43% — OK
[2025-03-10 10:45:01] [WARN]  Disk usage on /data is at 87% — above threshold of 80%

[2025-03-10 10:45:01] [INFO]  Checking memory usage...
[2025-03-10 10:45:01] [INFO]  Memory usage: 61% — OK

[2025-03-10 10:45:01] [INFO]  Checking CPU load...
[2025-03-10 10:45:01] [INFO]  1-minute load average: 0.42

[2025-03-10 10:45:01] [INFO]  Checking critical services...
[2025-03-10 10:45:01] [INFO]  Service [nginx] is running — OK
[2025-03-10 10:45:01] [ERROR] Service [ssh] is NOT running!

==============================================
  Health check complete.
==============================================

This is the kind of script that runs daily via cron on real servers. Add an email or Slack notification at the end and you have a basic monitoring system.

Best Practices for Shell Scripts

Writing a script that works is one thing. Writing a script that someone else (or future you) can read, debug, and maintain is another.

Always Quote Your Variables

# Bad — breaks if filename has spaces
rm $filename

# Good
rm "$filename"

This is the single most common source of bugs in shell scripts. Filenames, paths, and user input can all contain spaces. Always quote.

Use Meaningful Names

# Hard to read
for f in *.log; do
  s=$(wc -l < "$f")
  echo "$f: $s"
done

# Clear
for log_file in *.log; do
  line_count=$(wc -l < "$log_file")
  echo "$log_file: $line_count lines"
done

Use `set -e` and `set -u` at the Top

#!/bin/bash
set -e   # Exit immediately if any command fails
set -u   # Treat unset variables as errors

set -e means your script won't silently continue after a failed command. set -u catches typos in variable names. Add these to every script you write seriously.

Use ShellCheck

ShellCheck is a free static analysis tool for shell scripts. Paste your script in and it'll catch bugs, bad practices, and portability issues before you even run the script.

You can also install it locally:

# Ubuntu/Debian
sudo apt install shellcheck

# Then run it on your script
shellcheck your_script.sh

It's the bash equivalent of a linter. Use it.

Add a Usage Comment at the Top

#!/bin/bash
# ─────────────────────────────────────────
# backup.sh
# Description: Backs up a directory to a target location
# Usage: ./backup.sh <source_dir> <target_dir>
# Author: Malhar Gupte
# Last updated: 2025-03-10
# ─────────────────────────────────────────

Takes 30 seconds and saves a lot of confusion when you revisit the script months later.

Redirect Error Messages to stderr

# Good practice for error messages
echo "ERROR: File not found." >&2
exit 1

This means error messages won't pollute the stdout output of your script, which matters when other scripts or pipelines consume your script's output.

Final Thoughts

If you've made it through both parts of this series, you can now write scripts that:

Make decisions with if, elif, case
Repeat tasks with for and while
Handle success and failure with exit codes
Stay organized with functions
Check real system health on a live server

That's not beginner knowledge anymore.

For DevOps, shell scripting is the connective tissue between tools. It's how you glue together Docker commands, AWS CLI calls, database backups, log rotations, and deployment steps into a single automated workflow. Even if you work primarily with Python or Go for automation eventually, knowing how to read and write Bash means you can work on any server, in any environment, without needing anything installed.

The best way to get better at this is to find something you do manually and automate it. Clean up old files? Script it. SSH into a server and run the same three commands? Script it. Check if your services are running? You just wrote that script.

Start small. The scripts you write for yourself are the ones you'll actually learn from.

That's a wrap on this series. If something wasn't clear or you ran into an issue, drop a comment — happy to help debug. And if you're building something interesting with what you learned, share it.

Part 1 is here if you missed it: Shell Scripting for Beginners — Part 1

Shell Scripting for Beginners: From Zero to Automating Your First Tasks (Part 1)

Malhar Gupte — Tue, 10 Mar 2026 05:22:21 +0000

Series: Shell Scripting for Beginners | Part: 1 of 2
Level: Beginner | Time to read: ~15 minutes

Introduction

There's a moment every developer eventually hits — you find yourself doing the same repetitive task for the tenth time that week. Maybe it's renaming a batch of files, SSHing into servers and running the same commands, or cleaning up log directories. You do it manually, again, and somewhere in the back of your head a little voice says: "There has to be a better way."

That better way is shell scripting.

Shell scripting is one of those foundational skills that quietly separates developers who feel comfortable on a Linux system from those who feel like they're just guessing. It's not glamorous. It won't land you on the front page of Hacker News. But the ability to write a script that saves you 20 minutes every day? Over a year, that's more than 120 hours back in your pocket.

For DevOps engineers and sysadmins, scripting isn't optional — it's oxygen. Deployments, backups, health checks, log rotation, user provisioning — all of it gets automated with shell scripts. But even if you're a backend developer or just getting started with Linux, learning to write basic scripts will make your day-to-day dramatically more efficient.

This guide is Part 1 of a two-part series. We're going to go from "what even is a shell?" to writing a working script that takes arguments, reads user input, and does real arithmetic — all from scratch. No experience needed.

Let's get into it.

What is a Shell Script?

Before we write anything, let's get the vocabulary straight.

The Shell

When you open a terminal on Linux or macOS, you're not talking directly to the operating system kernel. There's a program sitting in between — that's the shell. It reads the commands you type, interprets them, and tells the OS what to do.

Think of it like a translator. You speak "human command language," the shell translates it, and the OS executes it.

Bash

There are several shell programs out there — sh, zsh, fish, dash — but the one you'll encounter most in the wild, especially on Linux servers, is Bash (Bourne Again SHell). It's been around since 1989, it's installed on virtually every Linux system, and it's what most shell scripting tutorials (including this one) use.

When you open a terminal and start typing commands, there's a very good chance you're already using Bash.

# Check which shell you're currently using
echo $SHELL

# Check your bash version
bash --version

What is a Shell Script?

A shell script is just a plain text file that contains a series of commands — the same commands you'd type in a terminal, but saved in a file so they can be run all at once, on demand, automatically.

That's it. There's no compiling, no special runtime. It's text that the shell reads and executes line by line.

Why is Scripting So Powerful?

Repeatability — Run the exact same sequence of commands every time, with no typos or forgotten steps.
Automation — Schedule scripts to run at 3am without you being there.
Speed — What takes you 10 manual commands takes a script half a second.
Portability — A script that works on one Linux server will usually work on another.

Creating Your First Script

Time to write something. Open your terminal and follow along.

Step 1: Create the Script File

A shell script is just a file. By convention, shell script files end with .sh, though technically the extension doesn't matter to the shell.

# Create a new file called hello.sh
touch hello.sh

# Open it in a text editor
nano hello.sh

Add the following content:

#!/bin/bash

echo "Hello, World!"
echo "My first shell script is running."

Save and exit (Ctrl+O, then Ctrl+X in nano).

Step 2: Make It Executable

By default, a new file doesn't have execute permission. If you try to run it as-is, you'll get a "Permission denied" error. You need to tell Linux that this file is allowed to be executed:

chmod +x hello.sh

chmod stands for change mode. The +x adds execute permission for the file owner. You only have to do this once per script.

Tip: Run ls -l hello.sh before and after chmod +x to see the permissions change. You'll notice an x appear in the permission string.

Step 3: Run the Script

Now you can execute it:

./hello.sh

You should see:

Hello, World!
My first shell script is running.

The ./ prefix tells the shell to look for the file in the current directory. Without it, the shell would only look in directories listed in your $PATH environment variable.

Alternative: You can also run it as bash hello.sh — this works even without chmod +x. But using ./ with execute permissions is the standard practice.

Understanding the Shebang

You probably noticed the first line of the script:

#!/bin/bash

This is called the shebang (also written as "hashbang"). It's not a comment, even though it starts with #. It's a special directive for the operating system.

How It Works

When you execute a file, the OS looks at the very first two characters. If it sees #!, it knows: "This is a script — the path that follows tells me which interpreter to use."

So #!/bin/bash is saying: "Use the program located at /bin/bash to execute this script."

If you were writing a Python script instead, you might use:

#!/usr/bin/env python3

Or for a Node.js script:

#!/usr/bin/env node

Always Include It

Some scripts will run without a shebang, but the behavior depends on whatever shell happens to be running them — which can vary between systems. Always include #!/bin/bash at the top of your Bash scripts. It makes your script's behavior explicit and predictable.

#!/bin/bash

# Your script starts here
echo "Shebang ensures I always run with Bash"

Tip: Use which bash to find the exact path to Bash on your system. On most systems it's /bin/bash, but on some (like certain macOS setups with Homebrew) it might be /usr/local/bin/bash. Using #!/usr/bin/env bash is a more portable alternative that searches your $PATH for bash.

Variables in Shell Scripts

Variables let you store values and reuse them. In Bash, they're simple to declare — maybe a little too simple, because the syntax is strict and easy to get wrong at first.

Declaring a Variable

#!/bin/bash

name="Malhar"
age=21
city="Vadodara"

Rules to live by:

No spaces around the = sign. name = "Malhar" will fail. It must be name="Malhar".
Variable names are case-sensitive. Name and name are different variables.
By convention, use lowercase for regular script variables and UPPERCASE for environment variables and constants.

Using a Variable

To use (or "reference") a variable, prefix its name with $:

#!/bin/bash

name="Malhar"
city="Vadodara"

echo "Hello, my name is $name and I live in $city."

Output:

Hello, my name is Malhar and I live in Vadodara.

Curly Brace Syntax

When a variable name could be ambiguous — like when you're placing it right next to other text — wrap it in curly braces:

#!/bin/bash

animal="dog"

echo "I have one ${animal}."
echo "I have two ${animal}s."   # Without braces, $animals would fail

Output:

I have one dog.
I have two dogs.

Tip: Get in the habit of using ${variable} over $variable — it prevents subtle bugs and makes your scripts easier to read.

Storing Command Output in a Variable

This is a technique you'll use constantly — capturing the output of a command into a variable:

#!/bin/bash

current_date=$(date)
current_user=$(whoami)

echo "Script run by: $current_user"
echo "Date: $current_date"

The $(...) syntax runs the command inside and captures its output. This is called command substitution.

Command Line Arguments

Scripts become far more useful when they can accept input at the time you run them — without needing to edit the file.

How Arguments Work

When you run a script like this:

./greet.sh Alice DevOps

Bash automatically populates special variables:

Variable	Value	Description
`$0`	`./greet.sh`	The name of the script itself
`$1`	`Alice`	First argument
`$2`	`DevOps`	Second argument
`$3`	(empty)	Third argument (not provided here)
`$#`	`2`	Total number of arguments passed
`$@`	`Alice DevOps`	All arguments as a list

Example Script

Create a file called greet.sh:

#!/bin/bash

echo "Script name: $0"
echo "Hello, $1! You work in $2."
echo "Total arguments passed: $#"

Make it executable and run it:

chmod +x greet.sh
./greet.sh Alice DevOps

Output:

Script name: ./greet.sh
Hello, Alice! You work in DevOps.
Total arguments passed: 2

What if an Argument Isn't Provided?

If $1 is empty because no argument was given, your script might behave unexpectedly. A good practice (which we'll cover more in Part 2 with conditionals) is to provide a default:

#!/bin/bash

name=${1:-"stranger"}   # Use $1 if provided, otherwise default to "stranger"

echo "Hello, $name!"

./greet.sh           # → Hello, stranger!
./greet.sh Malhar    # → Hello, Malhar!

Tip: ${variable:-default} is a Bash parameter expansion trick. The :- means "use this default value if the variable is unset or empty." Keep this one handy.

Taking Input from the User

Sometimes you want the script to pause and ask the user something while it's running. That's what the read command is for.

Basic `read`

#!/bin/bash

echo "What is your name?"
read user_name
echo "Nice to meet you, $user_name!"

The script will wait after printing the question. When the user types something and hits Enter, whatever they typed gets stored in user_name.

`read -p` (Prompt on the Same Line)

The -p flag lets you combine the prompt and the input on the same line, which looks cleaner:

#!/bin/bash

read -p "Enter your name: " user_name
read -p "Enter your city: " user_city

echo ""
echo "Welcome, $user_name from $user_city!"

Output (with user input in italics):

Enter your name: Malhar
Enter your city: Vadodara

Welcome, Malhar from Vadodara!

`read -s` (Silent Input)

For sensitive input like passwords, use -s to hide what the user types:

#!/bin/bash

read -sp "Enter your password: " user_pass
echo ""
echo "Password received (not printing it, obviously)."

Arithmetic Operations in Bash

Bash handles arithmetic a bit differently than most programming languages. The most reliable and readable way to do arithmetic is with the $(( )) syntax.

Basic Operations

#!/bin/bash

a=10
b=3

echo "Addition:       $((a + b))"
echo "Subtraction:    $((a - b))"
echo "Multiplication: $((a * b))"
echo "Division:       $((a / b))"   # Integer division only
echo "Modulo:         $((a % b))"
echo "Exponentiation: $((a ** b))"

Output:

Addition:       13
Subtraction:    7
Multiplication: 30
Division:       3
Modulo:         1
Exponentiation: 1000

Important: Bash only does integer arithmetic by default. $((10 / 3)) gives you 3, not 3.333. If you need decimal math, use bc or awk — we'll touch on those in later parts of this series.

Storing Arithmetic Results

#!/bin/bash

width=8
height=5

area=$((width * height))
perimeter=$(( 2 * (width + height) ))

echo "Width: $width, Height: $height"
echo "Area: $area"
echo "Perimeter: $perimeter"

Output:

Width: 8, Height: 5
Area: 40
Perimeter: 26

Increment and Decrement

#!/bin/bash

count=0

((count++))    # Increment by 1
echo $count    # 1

((count += 5)) # Add 5
echo $count    # 6

((count--))    # Decrement by 1
echo $count    # 5

Putting It All Together: A Small Practical Script

Let's combine everything we've covered — variables, arguments, user input, and arithmetic — into one cohesive script.

Scenario: You're building a simple tool for a gym management system. It takes a member's name and monthly fee as arguments, asks how many months they're signing up for, and calculates the total cost.

Create a file called gym_membership.sh:

#!/bin/bash

# ─────────────────────────────────────────
# gym_membership.sh
# Usage: ./gym_membership.sh <name> <monthly_fee>
# ─────────────────────────────────────────

# Grab arguments
member_name=${1:-"Member"}
monthly_fee=${2:-0}

echo "========================================="
echo "       Gym Membership Calculator"
echo "========================================="
echo ""
echo "Welcome, $member_name!"
echo "Monthly fee: ₹${monthly_fee}"
echo ""

# Ask for duration
read -p "How many months are you signing up for? " months

# Calculate totals
total=$((monthly_fee * months))
annual_equivalent=$((monthly_fee * 12))

echo ""
echo "-----------------------------------------"
echo "  Membership Summary"
echo "-----------------------------------------"
echo "  Name:               $member_name"
echo "  Monthly Fee:        ₹${monthly_fee}"
echo "  Duration:           ${months} months"
echo "  Total Cost:         ₹${total}"
echo "  (Annual would be:   ₹${annual_equivalent})"
echo "-----------------------------------------"
echo ""
echo "Registration complete. See you at the gym!"

Make it executable and run it:

chmod +x gym_membership.sh
./gym_membership.sh Malhar 999

Sample output:

=========================================
       Gym Membership Calculator
=========================================

Welcome, Malhar!
Monthly fee: ₹999

How many months are you signing up for? 6

-----------------------------------------
  Membership Summary
-----------------------------------------
  Name:               Malhar
  Monthly Fee:        ₹999
  Duration:           6 months
  Total Cost:         ₹5994
  (Annual would be:   ₹11988)
-----------------------------------------

Registration complete. See you at the gym!

This is a real, working script. Not a toy. You could drop this into a server right now and use it.

Conclusion

Let's recap what you've learned in Part 1:

What a shell script is — a plain text file with commands that the shell executes line by line
The shebang (#!/bin/bash) — tells the OS which interpreter to use
Creating and running scripts — touch, chmod +x, and ./script.sh
Variables — declaring with name="value", referencing with $name or ${name}
Command line arguments — $0, $1, $2, $#, and default values with ${1:-default}
User input — read, read -p, and read -s
Arithmetic — $(( )) for clean integer math

These are the building blocks. Every shell script you'll ever write — no matter how complex — is made up of some combination of these fundamentals.

What's Coming in Part 2

We've only just scratched the surface. In Part 2, we're going to add the real logic that turns scripts from simple command sequences into actual automation tools:

Conditional logic — if, elif, else to make decisions
Loops — for and while to repeat actions
Case statements — cleaner multi-branch logic
Functions — reusable blocks of code
Exit codes — how scripts communicate success or failure
Real automation scripts — backing up directories, monitoring disk usage, batch processing files

By the end of Part 2, you'll have scripts worth actually putting into a cron job.

Found this helpful? Drop a like or a comment — it genuinely helps. And if you're following along and something isn't working the way you expect, ask in the comments. Shell scripting has some gotchas that trip everyone up the first time.

See you in Part 2.

My Computer Networks Journey - From Confusion to Clarity with Kunal Kushwaha

Malhar Gupte — Wed, 10 Sep 2025 15:39:04 +0000

Starting a deep dive into computer networks felt like trying to understand an invisible world that somehow makes everything work. Over the past three weeks, I've been working through Kunal Kushwaha's comprehensive Computer Networks course, and what a journey it's been! As someone who always wondered "how does the internet actually work?", I can finally say I have real answers.

Let me share everything I learned and why understanding networks is absolutely crucial for any developer or tech enthusiast.

Understanding Computer Networks - The Invisible Infrastructure

What I Thought Networks Were vs. Reality

Before this course, my understanding of networks was embarrassingly surface-level:

"Wi-Fi connects me to the internet somehow"
"Routers do... router things?"
"HTTP is just how websites work"

Now I realize that computer networks are the entire foundation of modern digital life. Every app, every website, every cloud service, every smart device - they all depend on the same fundamental networking principles that I finally understand.

The Problems Networks Solve

Kunal's course brilliantly explained why we need networks in the first place:

Without Networks:

Computers would be isolated islands
No sharing of resources or information
Every computer would need its own printer, storage, etc.
No internet, no cloud, no modern computing as we know it

With Networks:

Resource sharing across the globe
Distributed computing and cloud services
Real-time communication and collaboration
Scalable, reliable systems

The Protocol Stack - OSI vs TCP/IP Models

OSI Model (7 Layers) - The Theoretical Framework

Kunal's explanation of the OSI model was incredibly detailed:

Layer 7 - Application Layer: User interfaces (HTTP, SMTP, FTP)
Layer 6 - Presentation Layer: Data formatting, encryption, compression
Layer 5 - Session Layer: Managing sessions between applications
Layer 4 - Transport Layer: Reliable delivery (TCP/UDP)
Layer 3 - Network Layer: Routing between networks (IP)
Layer 2 - Data Link Layer: Local network communication (Ethernet)
Layer 1 - Physical Layer: Physical transmission (cables, radio waves)

TCP/IP Model (5 Layers) - The Practical Reality

The TCP/IP model is what's actually implemented:

5. Application Layer: Combines OSI layers 5, 6, and 7
4. Transport Layer: TCP/UDP protocols
3. Network Layer: IP routing
2. Data Link Layer: Ethernet, Wi-Fi
1. Physical Layer: Hardware transmission

Why Both Models Matter

OSI: Great for understanding concepts and troubleshooting
TCP/IP: What actually runs the internet

Networking Devices Deep Dive

Understanding the role of each device was crucial:

Hubs: Dumb devices that repeat signals (mostly obsolete)
Switches: Smart devices that learn MAC addresses
Routers: Connect different networks using IP addresses
Gateways: Protocol converters between different network types
Firewalls: Security devices that filter traffic
Load Balancers: Distribute traffic across multiple servers

Sockets and Ports - The Communication Endpoints

Sockets - The Programming Interface

A socket is essentially:

IP Address + Port Number + Protocol
The endpoint for network communication
What programmers use to create network applications

Example: 192.168.1.100:8080 using TCP

Port Categories I Learned About

Well-Known Ports (0-1023):

Reserved for system services
Require admin privileges to use
Examples: HTTP (80), HTTPS (443), SSH (22)

Registered Ports (1024-49151):

Used by user applications
Examples: MySQL (3306), PostgreSQL (5432)

Dynamic/Private Ports (49152-65535):

Used for client connections
Assigned automatically by the operating system

HTTP Protocol Deep Dive

HTTP Methods That Actually Make Sense Now

GET: "Give me this resource" (idempotent, safe)
POST: "Create something new" (not idempotent)
PUT: "Replace this entire resource" (idempotent)
PATCH: "Update part of this resource"
DELETE: "Remove this resource" (idempotent)

HTTP Status Codes I Now Understand

2xx Success:

200 OK: Everything worked
201 Created: New resource created
204 No Content: Success, but no data to return

3xx Redirection:

301 Moved Permanently: Resource has new permanent location
302 Found: Temporary redirect
304 Not Modified: Use cached version

4xx Client Errors:

400 Bad Request: Malformed request
401 Unauthorized: Authentication required
403 Forbidden: Access denied
404 Not Found: Resource doesn't exist

5xx Server Errors:

500 Internal Server Error: Something broke on the server
502 Bad Gateway: Upstream server issue
503 Service Unavailable: Server temporarily down

Cookies - Session Management Made Simple

Cookies finally made sense:

Server sends Set-Cookie header
Browser stores the cookie
Browser sends cookie with subsequent requests
Server uses cookie to maintain state

This enables shopping carts, login sessions, and personalization.

How Email Actually Works

This was one of my favorite sections! The email journey:

Compose: You write an email in your client
SMTP: Your client sends to your email server
DNS: Server looks up recipient's email server
SMTP: Your server sends to recipient's server
Storage: Recipient's server stores the email
POP3/IMAP: Recipient downloads via email client

Key Protocols:

SMTP: Sending emails (Simple Mail Transfer Protocol)
POP3: Downloading emails (deletes from server)
IMAP: Accessing emails (keeps on server)

DNS - The Internet's Phone Book

How Domain Name Resolution Works

When you type www.google.com:

Browser Cache: Check local cache first
OS Cache: Check operating system cache
Router Cache: Check home router cache
ISP DNS: Query internet service provider
Root Servers: Query root name servers (.)
TLD Servers: Query top-level domain servers (.com)
Authoritative Servers: Query Google's name servers
Response: IP address returned through the chain

This complex process happens in milliseconds!

DNS Record Types

A Record: Maps domain to IPv4 address
AAAA Record: Maps domain to IPv6 address
CNAME: Creates an alias for another domain
MX Record: Specifies email servers
TXT Record: Stores text information

Transport Layer Deep Dive

TCP (Transmission Control Protocol) - The Reliable Choice

Key Features:

Connection-oriented: Establishes connection before data transfer
Reliable: Guarantees data delivery
Ordered: Data arrives in correct sequence
Error detection and correction
Flow control: Prevents overwhelming the receiver

The Famous 3-Way Handshake

This elegant dance establishes TCP connections:

SYN: Client sends synchronization request
SYN-ACK: Server acknowledges and sends its sync
ACK: Client acknowledges server's sync

Connection established! Now data can flow reliably.

UDP (User Datagram Protocol) - The Fast and Furious

Key Features:

Connectionless: No handshake required
Unreliable: No guarantee of delivery
Fast: Minimal overhead
Unordered: Data can arrive out of sequence

Perfect for:

Video streaming (occasional lost frames are okay)
Online gaming (speed over perfection)
DNS queries (fast lookups)

Checksums and Error Detection

Every TCP/UDP packet includes a checksum:

Mathematical calculation based on data content
Receiver recalculates and compares
If checksums don't match, data is corrupted
TCP retransmits, UDP discards

Timers in TCP

TCP uses various timers for reliability:

Retransmission Timer: Resends if no acknowledgment
Keep-Alive Timer: Maintains idle connections
Time-Wait Timer: Ensures clean connection closure

Network Layer - Routing and IP

Control Plane vs Data Plane

Control Plane:

Makes routing decisions
Builds routing tables
Exchanges routing information
The "brain" of the network

Data Plane:

Forwards actual packets
Uses routing table decisions
The "muscle" of the network

IP (Internet Protocol) - The Universal Language

IPv4 Packet Structure:

Version, Header Length, Type of Service
Total Length, Identification, Flags
Fragment Offset, Time to Live, Protocol
Header Checksum, Source IP, Destination IP
Options, Data

Packets vs Frames vs Segments

Segments: Transport layer (TCP/UDP)
Packets: Network layer (IP)
Frames: Data link layer (Ethernet)

Each layer adds its own header!

Middle Boxes - The Network Helpers

NAT (Network Address Translation):

Allows multiple devices to share one public IP
Translates private IPs (192.168.x.x) to public IP
Essential for home networks

Firewalls:

Filter traffic based on rules
Can operate at multiple layers
Protect networks from threats

Load Balancers:

Distribute traffic across servers
Improve performance and reliability
Can detect server failures

Data Link Layer - The Local Network Champion

This layer handles communication within the same network segment:

MAC Addresses: Physical hardware addresses
Ethernet: Most common wired protocol
Wi-Fi: Wireless local area networking
Switches: Forward frames based on MAC addresses

The course covered how frames are constructed and how switches learn MAC addresses to build their forwarding tables.

Network Security Fundamentals

Threats I Never Considered

Man-in-the-Middle Attacks: Intercepting communication between two parties
DNS Spoofing: Redirecting domain names to malicious servers
DDoS Attacks: Overwhelming servers with traffic
Packet Sniffing: Reading unencrypted network traffic

Security Measures That Make Sense Now

Firewalls: Like bouncers for network traffic
VPNs: Creating secure tunnels through insecure networks
SSL/TLS: Encrypting web traffic
Network Segmentation: Isolating sensitive systems

Routing and Switching - The Traffic Controllers

How Data Finds Its Way

Routers: Make decisions about where to send data across different networks
Switches: Handle communication within a single network
Routing Tables: Like GPS for network packets

Network Topologies I Finally Understand

Star Topology: Everything connects to a central hub
Ring Topology: Devices connected in a circular chain
Mesh Topology: Every device connected to every other device
Hybrid Topologies: Real-world combinations of the above

Practical Applications That Clicked

Load Balancing

Distributing traffic across multiple servers:

Round Robin: Take turns serving requests
Least Connections: Send to the least busy server
Geographic: Send to the nearest server

Content Delivery Networks (CDNs)

Now I understand why Netflix works so well globally - they store content close to users in hundreds of locations worldwide.

Network Address Translation (NAT)

How your router allows multiple devices to share one public IP address - this explained so much about home networking!

Tools and Commands I Learned

Essential Network Commands

# Check connectivity
ping google.com

# Trace route to destination
traceroute google.com

# Check DNS resolution
nslookup google.com

# Display network configuration
ifconfig (Linux/Mac) or ipconfig (Windows)

# Show network connections
netstat -an

# Display routing table
route -n

Network Analysis Tools

Wireshark: Capture and analyze network packets
Nmap: Network discovery and security scanning
Curl: Test HTTP requests from command line
Telnet: Test network connections

How This Connects to Development

API Design Makes More Sense

Understanding HTTP methods, status codes, and headers helps me design better APIs:

200: Success
404: Not Found
500: Server Error
401: Unauthorized

Database Connections

Network concepts explain database connection pooling, timeouts, and distributed databases.

Cloud Computing

AWS, Azure, GCP services all make more sense when you understand VPCs, subnets, security groups, and load balancers.

Microservices Architecture

Service discovery, API gateways, and inter-service communication rely heavily on networking fundamentals.

Challenges and Aha Moments

What Was Difficult

Binary and Hexadecimal Math: Converting between number systems for subnet calculations
Protocol Stack Interactions: Understanding how all the layers work together
Network Troubleshooting: Learning systematic approaches to diagnose issues

Breakthrough Moments

Subnet Masking: When I finally understood how to calculate network ranges
Three-Way Handshake: The elegant simplicity of TCP connection establishment
DNS Hierarchy: Realizing the internet is basically a giant distributed database

Questions for the Community

I'd love to hear from experienced network engineers and developers:

What networking concepts do you use most in your daily work?
Any recommendations for hands-on networking practice labs?
Which network monitoring tools do you find most valuable?
Common networking mistakes you see developers make?

What's Next in My Learning Journey

Now that I have solid networking fundamentals, I'm currently preparing for the AWS Cloud Practitioner Certification (CLF-C02). The networking concepts from this course are already helping me understand VPCs, security groups, and cloud networking services much better!

Resources That Made the Difference

Kunal Kushwaha's Computer Networks Course: Excellent explanations with real-world examples
GeeksforGeeks Articles: Supplemented the course with detailed articles on specific networking topics and concepts
Community Support: Discord discussions and Q&A sessions

If you're considering learning computer networks, I highly recommend Kunal's course. The concepts might seem abstract at first, but once they click, you'll see the network layer in everything you build.

Understanding networks has made me a better developer, a more effective debugger, and given me confidence to architect distributed systems. It's one of those foundational skills that pays dividends across your entire career.

What networking concepts do you find most challenging or interesting? Share your experiences in the comments!

See you next week for more learning adventures!

My DevOps Journey - Understanding the Why and Linux Fundamentals

Malhar Gupte — Sun, 17 Aug 2025 13:34:40 +0000

Starting a new learning journey always feels both exciting and overwhelming. This week, I decided to dive into the world of DevOps, and let me tell you - it's been an eye-opening experience. As someone looking to understand this field better, I chose to start with the fundamentals: understanding what DevOps really is and getting comfortable with Linux.

My learning sources for this week were TechWorld with Nana for DevOps concepts and TrainWithShubham for Linux fundamentals. Here's everything I learned and why it matters.

Understanding DevOps - More Than Just Buzzwords

What DevOps Actually Is

Before this week, I thought DevOps was just another tech buzzword - maybe some tools, maybe some automation. Boy, was I wrong! Thanks to Nana's clear explanations, I now understand that DevOps is fundamentally about culture and collaboration, not just tools.

DevOps is a methodology that bridges the gap between Development and Operations teams. It's about breaking down the traditional silos where developers write code and throw it "over the wall" to operations teams who then struggle to deploy and maintain it.

The Problems DevOps Solves

The more I learned about traditional software development approaches, the more I understood why DevOps became essential:

Before DevOps:

Deployments took days or weeks
Development and Operations teams barely communicated
Testing happened only at the end (too late!)
Environments were inconsistent ("it works on my machine!")
Manual processes everywhere = human errors everywhere
Slow feedback cycles meant issues were discovered late

After DevOps:

Multiple deployments per day (Netflix deploys thousands of times daily!)
Teams collaborate throughout the entire lifecycle
Continuous testing and integration
Consistent environments through automation
Automated processes reduce human error
Fast feedback loops catch issues early

Key DevOps Principles That Clicked for Me

Automation Everywhere: If you're doing it manually more than once, automate it
Continuous Integration/Continuous Deployment (CI/CD): Code changes are automatically tested and deployed
Infrastructure as Code: Manage your infrastructure like you manage your application code
Monitoring and Feedback: Constantly monitor and improve based on data
Fail Fast, Recover Quickly: It's better to find problems early when they're cheaper to fix

Linux Fundamentals - The Foundation of Everything

Why Linux Matters in DevOps

Before diving into commands, I needed to understand why Linux is so crucial for DevOps:

Most servers run Linux (96% of the top 1 million web servers!)
Container technologies like Docker are Linux-based
Cloud platforms predominantly use Linux
Automation scripts are often written in shell
Cost-effective - no licensing fees unlike Windows servers

Essential Commands I Mastered This Week

Here are the commands I practiced and their real-world applications:

Navigation and File Operations:

# Basic navigation
pwd                    # Show current directory
ls -la                # List files with details
cd /path/to/directory # Change directory
mkdir project-folder  # Create directory
rmdir empty-folder    # Remove empty directory
rm -rf folder         # Remove directory and contents

# File operations
cp source destination  # Copy files
mv oldname newname    # Move/rename files
cat filename          # Display file contents
less filename         # View file page by page
head -10 filename     # Show first 10 lines
tail -f logfile       # Follow log file in real-time

Permissions and Ownership:

chmod 755 script.sh         # Make script executable
chmod +x script.sh          # Another way to make executable
chown user:group filename   # Change file ownership
ls -l                       # View file permissions

Process Management:

ps aux                      # Show all running processes
top                         # Real-time process monitor
kill 1234                   # Terminate process with ID 1234
jobs                        # Show active jobs
nohup command &             # Run command in background

Understanding the Linux File System

The Linux directory structure finally makes sense to me:

/ - Root directory (everything starts here)
/home - User directories (like C:\Users on Windows)
/etc - Configuration files (this is huge for DevOps!)
/var - Variable data, including logs (crucial for troubleshooting)
/usr - User programs and applications
/tmp - Temporary files (cleaned on reboot)
/opt - Optional/third-party software

File Permissions Deep Dive

This was initially confusing, but now I get it:

Permission Types:

Read (r) = 4
Write (w) = 2
Execute (x) = 1

Permission Groups:

User (owner)
Group
Other (everyone else)

Example: chmod 755 script.sh

Owner: 7 (4+2+1) = read, write, execute
Group: 5 (4+1) = read, execute
Other: 5 (4+1) = read, execute

Connecting the Dots - How This All Fits Together

Now I understand why these fundamentals are crucial for DevOps:

Server Management: DevOps engineers constantly SSH into Linux servers to deploy applications, check logs, and troubleshoot issues. Without Linux skills, you're stuck.

Automation Scripts: Whether it's deployment scripts, backup scripts, or monitoring scripts, they're typically written in bash and run on Linux systems.

Container Technology: Docker containers are essentially Linux processes. Understanding Linux concepts like processes, file systems, and permissions is essential for containerization.

Infrastructure as Code: Tools like Terraform and Ansible manage Linux servers. You need to understand what you're automating.

CI/CD Pipelines: Build servers are typically Linux-based. Your deployment scripts need Linux knowledge.

Challenges and Learning Moments

What Was Difficult

Command Syntax: Remembering all the flags and options. Why is it ls -la and not ls /a? Getting used to the Unix philosophy took time.

Vim Editor: I spent 10 minutes trying to exit Vim on my first try! :q! is now permanently etched in my memory.

Permission Numbers: Understanding why 755 means what it means required practice and repetition.

No Safety Net: Unlike Windows with "Are you sure?" dialogs, rm -rf / can destroy everything. The power requires responsibility.

Questions for the Community

I'd love to hear from experienced DevOps practitioners:

What Linux commands do you use most frequently in your daily DevOps work?
Any beginner-friendly resources for practicing Linux skills in a DevOps context?
Any common mistakes I should watch out for as I continue this journey?

If you're also starting your DevOps journey, I encourage you to focus on these fundamentals. Don't rush to the flashy tools - master the basics first. Trust me, everything else will build on top of this foundation.

Resources mentioned:

TechWorld with Nana: What is DevOps? REALLY understand it | DevOps vs SRE
TrainWithShubham: Linux For DevOps In One Shot

See you next week for more learning adventures!

DEV Community: Malhar Gupte

Shell Scripting for Beginners: Control Flow, Functions and Real Automation (Part 2)

Quick Recap of Part 1

Conditional Logic (if Statements)

Basic if

if-else

if-elif-else

Comparison Operators

Double Brackets [[ ]]

For Loops

Looping Through a List of Values

Looping Through a Number Range

C-Style For Loop

Looping Through Files

Practical Example: Batch Rename Files

While Loops

Basic While Loop

Reading a File Line by Line

Waiting for Something to Happen

Case Statements

The Problem case Solves

Practical Example: Script Menu

Exit Codes

Checking $?

Using Exit Codes in Conditionals

Setting Exit Codes in Your Scripts

Functions in Bash

Defining and Calling a Function

A More Realistic Function

local Variables

Functions with Return Values

Real Automation Script: System Health Check

Best Practices for Shell Scripts

Always Quote Your Variables

Use Meaningful Names

Use set -e and set -u at the Top

Use ShellCheck

Add a Usage Comment at the Top

Redirect Error Messages to stderr

Final Thoughts

Shell Scripting for Beginners: From Zero to Automating Your First Tasks (Part 1)

Introduction

What is a Shell Script?

The Shell

Bash

What is a Shell Script?

Why is Scripting So Powerful?

Creating Your First Script

Step 1: Create the Script File

Step 2: Make It Executable

Step 3: Run the Script

Understanding the Shebang

How It Works

Always Include It

Variables in Shell Scripts

Declaring a Variable

Using a Variable

Curly Brace Syntax

Storing Command Output in a Variable

Command Line Arguments

How Arguments Work

Example Script

What if an Argument Isn't Provided?

Taking Input from the User

Basic read

read -p (Prompt on the Same Line)

read -s (Silent Input)

Arithmetic Operations in Bash

Basic Operations

Storing Arithmetic Results

Increment and Decrement

Putting It All Together: A Small Practical Script

Conclusion

What's Coming in Part 2

My Computer Networks Journey - From Confusion to Clarity with Kunal Kushwaha

Understanding Computer Networks - The Invisible Infrastructure

What I Thought Networks Were vs. Reality

The Problems Networks Solve

The Protocol Stack - OSI vs TCP/IP Models

OSI Model (7 Layers) - The Theoretical Framework

Basic `if`

`if-else`

`if-elif-else`

Double Brackets `[[ ]]`

The Problem `case` Solves

Checking `$?`

`local` Variables

Use `set -e` and `set -u` at the Top

Basic `read`

`read -p` (Prompt on the Same Line)

`read -s` (Silent Input)