The Thing with shell script

Index

1. Journey of Shell Script (History) - Short

2. My Journey with Shell Scripting

3. My New Gig Experience

4. My Take on Shell Scripting

1. Shell Script History

Shell scripting was born alongside Unix in the early 1970s, like peanut butter and jelly—meant to be together. The Thompson shell arrived in 1971, letting users chain commands like a pro. But it was the Bourne shell (sh) in 1977 that gave shell scripting its real mojo by adding scripting features and control structures. That shell was so popular that it led to the creation of Bash (Bourne Again Shell) in 1989, which was like sh, but on steroids. Since then, shells like zsh and fish have come along, each with their own quirks and features, but all paying homage to the OG shells. Today, shell scripting is still a favorite for system administration, automation, and scaring off people who don't like command lines.

Reference: IBM Developer

2. My Journey with Shell Scripting

Let’s be honest: when I was first introduced to Linux, I was a total nerd about it. When I started my degree, I got sucked into the terminal world. My first experience? Bash. I thought I had mastered it—boy, was I wrong. I used to flex my “skills” (okay, they were super amateur) in front of my classmates. I was so busy making the terminal look pretty and playing with different command-line tools that I completely missed the point. Eventually, I got overwhelmed by all the options and tapped out.

Fast forward to my first professional gig at a startup, where we were using Ubuntu 18. I felt like my old knowledge gave me an edge over my colleagues, but I quickly realized I was still a noob. Thankfully, my CTO Nitin Bhide and coworkers were incredibly supportive, helping me polish my shell skills. I started small—with basics like ls, pwd, and cat. Oh, and don't get me started on text editors. I tried vim first, but it gave me a headache, so I happily settled for Nano. From there, the ride was smooth.

The point of this little flashback? Your professional experience shapes your understanding, and having good mentors along the way makes all the difference.

Use cases for shell scripts (as I see them):

• Automating repetitive small tasks
• Creating custom commands
• Analyzing system logs and generating reports
• Backing up config files and data
• Writing small build scripts

Of course, there’s more, but I mostly use shell scripts for repetitive tasks and CI/CD pipeline tweaks. I haven't written any massive scripts, but you get the idea.

3. My New Gig Experience

In my current gig, shell scripts are everywhere. Small tools? Check. Big tools? Also check. Imagine my surprise—because I had no clue big tools could be built around shell scripts! Not only do we have scripts that deploy entire solutions on AWS, but we also have a full build pipeline designed in shell. We even have internal tools written in shell scripts. These aren’t just thrown together either; they’re meticulously crafted. I’ve seen syntax in shell scripting that I didn’t even know existed, like:

1. Associative Arrays

# Declare an associative array
declare -A FAMOUS_CITIES

# Add elements to the associative array
FAMOUS_CITIES[Mumbai]="Gateway of India"
FAMOUS_CITIES[Delhi]="India Gate"
FAMOUS_CITIES[Bangalore]="Lalbagh Botanical Garden"

# Print the value of a specific key
echo ${FAMOUS_CITIES[Mumbai]} # Outputs: Gateway of India

1. Functions and Recursion (Yes, really)

To solve problems where loops might be insufficient.

factorial() {
  if [ $1 -le 1 ]; then
    echo 1
  else
    prev=$(factorial $(($1 - 1)))
    echo $(($1 * $prev))
  fi
}
echo "Factorial of 5 is $(factorial 5)"

1. Custom Logging Mechanisms

log() {
  echo "$(date): $@" >> script.log
}
log "Script started"

We even built our own config parser and template generator in shell script. I quickly realized I had a lot to learn in this space! Here’s what I’ve picked up so far, thanks to my CTO:

1. Shell scripts are still super powerful and relevant, even for large tools.
2. It’s ridiculously easy to integrate shell scripts with other tools.
3. You can design a decent CLI tool with shell scripting.

Now, don’t ask me how we designed these scripts—it was all my CTO, who’s an absolute legend in leading open banking solutions. If you want to know more, check out his profile: Freddi Gyara

4. My Take on Shell Scripting

I’ve learned a lot from these tools, but here’s the thing: shell scripting is amazing for small to medium-sized scripts (up to 1,500 lines, in my opinion). But if you try to push beyond that, the tool starts to crack. Why? Let me break it down:

1. Complexity: The bigger the tool, the harder it becomes to add new features without breaking something.
2. Tooling: Shell scripting doesn’t have the fancy tooling modern programming languages provide.
3. Dependencies: You’ll likely end up reinventing the wheel for things like logging since there’s no easy way to manage dependencies.
4. Debugging and Error Handling: Debugging shell scripts? It’s like pulling teeth. There’s no fancy breakpoint system, just the good old set keyword.

set -e  # Exit on error
set -x  # Print commands as they are executed

So, here’s my final thought: use shell scripting for small utilities, but for anything bigger (or if your team grows beyond five or six people), switch to Python or in more language. It’ll save you a lot of headaches!