Day 20: Practically Exploring Shell Scripting – A Journey into Automation

Today marks the 20th day of our shell scripting journey, and it's all about getting our hands dirty with real-world scripting techniques. We've now crossed the theoretical foundation phase and are stepping into how things actually work when implemented. To start with, we first link our local Git Bash terminal to the remote GitHub repository where all our shell scripting practice is stored. This helps us maintain a clean structure and track our daily progress effectively. For Day 20, we create a new folder named "day2" under our shell scripting repository to keep today's practical work separate and well-organized.

Once inside the day2 folder, the next logical step is to create a file that will act as today’s working space. We name it something creative like “devops ki duniya” — because today, we are not just learning scripting; we are entering the world where DevOps meets automation through shell scripts. Using the terminal-based editor like Vim, we open the file and begin with the most fundamental part of any script — the declaration line that tells the system it's a shell script. This declaration, often called the shebang line, is always the first line of a shell script and acts like an identity badge for the script interpreter.

Following this, we dive into the concept of comments in shell scripting. Comments are like personal notes inside the code. They help the reader, including your future self, understand what’s happening in the script. Shell scripting allows two types of comments. The first type is the single-line comment. It is written using a special symbol at the start of the line, followed by the actual comment text. These are great for short explanations and reminders. Then comes the multi-line comment, which is used when you need to write longer notes across multiple lines. Though slightly more complex to implement, it becomes essential in larger scripts to document each section clearly. These comments are ignored during execution, which means they don’t affect how your script runs but improve its readability significantly.

Now, let’s explore variables — the real memory holders of shell scripting. Variables in shell scripting are like boxes that hold data values. You can use them to store anything from a single word to an entire sentence, or even numbers and calculations. Today, we learn not only how to assign values to variables, but also how to display those values on the terminal. Even more interestingly, we learn how to interact with users by taking input from them and storing it in variables. This simple interactivity makes your scripts dynamic and adaptive. For example, if you ask the user their name and use that name throughout your script, it makes your automation much more personalized.

Moving forward, we touch upon arguments in shell scripting. When we run a shell script from the command line, sometimes we need to pass extra information to it. These extra pieces of information are known as arguments. Imagine running a script like “./devops-ki-duniya.sh” followed by some text — each word or number after the script name is an argument. The first one is traditionally called $1, the second is $2, and so on. Arguments allow us to make a single script flexible enough to handle different data each time it's run. This becomes especially useful in real-world tasks like user account creation, backup processes, or automation of deployment steps — where each execution might require a different input.

Then comes the heart of any automation logic — conditional statements. These are like the decision-makers in your script. They allow the script to choose between different actions based on certain conditions. In a real-world example, think of a script that checks whether a file exists or not before trying to open it, or a script that checks if your internet connection is active before starting a download. These decisions are made using logical comparisons — like checking if two values are equal or if a number is greater than another. This makes your script smart — capable of reacting differently based on real-time situations.

As we build this logic, we naturally move towards loops, which are the engines behind repetitive tasks. Imagine needing to check all files in a folder or process every username in a list. Rather than writing the same commands over and over, loops let us write the logic once and repeat it as many times as needed. In a professional DevOps environment, loops are often used to monitor logs, process files, clean up resources, or repeat health checks. Today, we learn how to set up loops that iterate either over a predefined list or based on a condition, making our automation both efficient and powerful.

Finally, we reach functions, which bring structure and reusability into our scripts. A function is like a mini-script inside your main script. It’s a set of instructions grouped under a name, and you can call that name whenever you need to perform that task. Think of it like how you have apps on your phone — each app performs a specific task, and you open it when required. Similarly, in shell scripting, you might create a function to clean up temporary files, another to send an alert email, and another to restart a service — all within the same script. Using functions improves clarity, saves time, and prevents code duplication, especially as your scripts grow larger