Learn BASH Scripting - Pre-Requisites Skill & Setup Environment

#Introduction

Welcome to the Learn BASH Scripting series! This series will take you from zero to writing production-grade automation scripts: from prerequisites and environment setup, shell history, variables & environment variables, quoting & word splitting, globbing, arithmetic, conditionals & regex, loops, functions, indexed & associative arrays, parameter expansion, command substitution & heredoc, error handling & strict mode, trap & signal, debugging, professional CLI with getopts, sed/awk/curl/jq integration, logging & colorizing, ShellCheck & Bats-core, all the way to real-world server automation case studies. That's 27 episodes that will transform you from a mere "command typer" into someone who makes systems run themselves.

Why is BASH so important? Because BASH is the glue of the Linux server world. Imagine a server as a factory: applications, databases, and web servers are its machines. Without BASH, every log check, every backup, every disk cleanup, and every deployment must be done manually — click, type, repeat hundreds of times. With BASH, you write a single script that does all of it, runs on a schedule by itself, and quietly keeps the factory alive. A DevOps Engineer who can't script is like a mechanic with only one size of wrench: they can work, but never efficiently.

This episode 0 is your roadmap. We'll make sure three things are in place before we set off: (1) the basic skills you must have, (2) the environment best suited for learning, and (3) the tools and verification that the BASH interpreter runs flawlessly. Once this episode is done, you'll be standing firm at the entrance — ready to step into episode 1, which covers the history and why BASH became the standard of the Linux world.

#Basic Skills You Must Have

Trust us, the biggest problem for BASH beginners isn't the if or for syntax — it's a shaky Linux foundation. BASH scripting is stringing Linux commands together into automation. If you don't understand the commands themselves, all you're stringing together is meaningless incantation.

#Filesystem Navigation

BASH scripts almost always deal with files and directories: reading configuration, moving logs, processing output. You must be comfortable "walking" around the filesystem. You need to understand the difference between absolute paths (/var/log/nginx/access.log) and relative paths (../config/app.conf), as well as the meaning of ~ (the user's home) and cd - (return to the previous directory). Think of the filesystem as a warehouse; you need to know where items are stored before you can organize them.

#Basic Commands You Must Remember

Here are the commands you'll encounter in almost every script:

Don't worry — you don't need to memorize every option. What matters is that you've used them and understand what they do, because BASH is just the automation of these commands. When you write cp -r /etc/nginx /backup/nginx inside a script, you're not learning something new — you're retyping something you normally do in the terminal.

#Getting Comfortable with a Terminal Text Editor

A BASH script is a plain text file — there's no magic inside. That's why you need an editor you're comfortable writing text in. Two most popular options:

• nano — the friendliest editor for beginners. The best entry point: open, type, Ctrl+O to save, Ctrl+X to exit.
• vim — steeper learning curve, but once mastered, it's the most efficient editor in the world. Many server admins live inside vim.

If you prefer a GUI, VS Code with remote editing (SSH into a server or opening a WSL folder) is also very common in the DevOps world. Whichever you choose, the important thing is consistency — because throughout this series, you'll keep writing scripts in that editor.

#Willingness to Read Errors and Documentation

This isn't a technical skill, but it decides everything. BASH error messages like command not found, Permission denied, or syntax error: unexpected end of file always contain clues — read them before asking Google. The same goes for the habit of opening man bash or help when you're confused. Laziness in reading errors is the biggest enemy of every aspiring script-writer.

#Environment for Learning BASH

BASH runs anywhere there's a Unix-like system. You have three main choices, each with its own trade-offs:

Your environment choice doesn't determine your quality — BASH is BASH on all platforms. But there's one important note: the BASH version. Scripts written for BASH 5 can fail on BASH 3, and vice versa. Make sure your environment has BASH 4.0+, ideally 5.0+.

#Supporting Tools

#The BASH Interpreter at /bin/bash

The most fundamental thing: make sure there's a /bin/bash file. On almost all Linux distros and macOS, this file already exists. It's the "engine" that reads and runs your scripts — the equivalent of a runtime in other languages. We'll dig into it further in episode 2 (shebang and execution modes).

#A Comfortable Terminal

• Linux: your distro's built-in terminal (GNOME Terminal, Konsole, kitty) is more than enough.
• Windows/WSL2: Windows Terminal — a modern terminal with tabs, split panes, and themes. A must-install.
• macOS: the built-in Terminal or iTerm2.

#VS Code Extensions (Optional but Highly Recommended)

VS Code isn't a requirement, but these two extensions will save you from many of the mistakes we'll cover in the upcoming episodes:

ShellCheck matters especially because it teaches you why a pattern is wrong — exactly like a spell-checker that explains grammar. It'll be your "silent teacher" throughout this series.

#Environment Verification

Time to make sure everything is ready. Open your terminal and run:

bash --version
which bash
echo $BASH_VERSION

GNU bash, version 5.2.21(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2022 Free Software Foundation, Inc.
/usr/bin/bash
5.2.21(1)-release

Explanation of the three lines above:

If your output shows version 4.x or 5.x, you're ready. If it's still 3.x, update your system (sudo apt update && sudo apt upgrade on Ubuntu) or reinstall the environment.

#Why Is the BASH Version So Important?

The BASH version determines which features are available. The two most impactful features: associative array (an array with string keys — available since BASH 4) and globstar (** for recursive directory matching — available since BASH 4). BASH 5 added several improvements, including the BASH_XTRACEFD mechanism for cleaner debugging.

A script that uses associative arrays will fail entirely with the error declare: -A: invalid option on BASH 3. That's why, if you write scripts that must run on servers of varying versions, always check compatibility — a topic we'll cover in the episode about portability.

shopt -s globstar
declare -A mymap
mymap[ops]="production"
echo "Versi: $BASH_VERSION"

If the first three lines run without errors, your environment supports modern features. The last output line will show your BASH version.

#Your First Setup Verification Script

Now let's tie it all together. Create a file named hello-setup.sh in your practice folder, fill it with the script below, then run it:

#!/bin/bash
 
echo "Hello, BASH Scripting!"
echo "User saat ini   : $USER"
echo "Home directory : $HOME"
echo "Shell saat ini : $SHELL"
echo "Versi BASH     : $BASH_VERSION"
echo "Direktori aktif: $PWD"

bash hello-setup.sh

Hello, BASH Scripting!
User saat ini   : arman
Home directory : /home/arman
Shell saat ini : /usr/bin/bash
Versi BASH     : 5.2.21(1)-release
Direktori aktif: /home/arman/lab

Note: in this script we've only used built-in variables ($USER, $HOME, $SHELL, $BASH_VERSION, $PWD). You don't need to fully understand them yet — episode 3 will dissect variables and environment variables thoroughly. What matters right now: the script runs, the output is correct, the environment is ready. If you see BASH version 4.x/5.x and all the lines print, you're officially ready to begin this journey.

#Common Pitfalls

1. Old BASH version. Modern features fail mysteriously on BASH 3.x. Always check $BASH_VERSION and make sure it's 4.0+ (ideally 5.x).

2. Windows editors that alter line endings. Notepad and Windows editors write line endings as CRLF, while Linux uses LF. The result is the error $'\r': command not found. Solution: use an editor that supports LF (VS Code, nano, vim) or convert with sed -i 's/\r$//' script.sh.

3. Writing scripts too soon, without a CLI foundation. If you still get confused by ls, cp, and grep, strengthen your terminal basics first before writing scripts. BASH is automation — a shaky foundation makes the scripts shaky too.

4. Ignoring error messages. command not found on line 3 means the command on that line isn't recognized — not a mystery. Read the message, match it to the line number, and fix it.

5. Never practicing by typing. Reading tutorials without typing yourself is like watching swimming videos without getting in the pool. In every episode, retype all the examples — the mistakes you make while typing are the best teacher.

#Conclusion

In episode 0 you've secured three foundations: basic Linux CLI skills (filesystem navigation, the core commands cd, ls, cp, mv, rm, chmod, cat, grep, and comfort with a text editor), the right learning environment (Linux native, WSL2, or macOS with BASH 4.0+/5.0+), and tools and verification that the BASH interpreter runs properly via bash --version and your first test script.

Points to take away:

• BASH is automation of Linux commands — master the basic commands first.
• Any environment is fine, as long as it's BASH 4.0+ and comfortable for you.
• ShellCheck + VS Code is an editor pairing that really helps beginners.
• Verification always starts with bash --version and $BASH_VERSION.
• Don't fear errors — read the message, it holds the answer.

Remember, the Learn BASH Scripting series consists of 27 episodes that build on each other: from shell history, variables, quoting, globbing, control flow, functions, arrays, parameter expansion, to error handling and production-grade automation. Episode 0 is the first brick of that building — and you've just laid it perfectly. In the next episode we'll take a step back to understand the history, background, and why BASH became the standard of the Linux world — from the Bourne Shell of 1979, the birth of BASH at the hands of Brian Fox in 1989, to BASH's position as the bridge connecting almost every server on the internet. See you in episode 1, and happy writing your first command lines!