Linux Shell Scripting Basics to Loops in 5 Days

It’s been a while since my last update on my DevOps journey with CoderCo — but I’ve been putting in the work behind the scenes. Since completing Linux Fundamentals, I’ve been diving into Bash scripting, and things are starting to click. Some of what I’ve been learning: - Writing Bash scripts to automate simple tasks - Using tools like "awk" and "grep" to process data - Understanding exit codes and error handling - Working with "set -e" and "set -u" to make scripts safer and more reliable It’s a different feeling now — less “copying commands” and more actually understanding what’s happening. Still a long way to go, but definitely seeing progress. Next focus: building small scripts and applying this in real scenarios. If anyone has beginner-friendly scripting projects or tips, I’d appreciate it. #DevOps #Linux #Bash #Automation #LearningJourney

Revisiting Linux concepts is always valuable, and the BashBlaze – 7 Days of Bash Scripting Challenge is a great way to do just that. It introduces the fundamentals of Bash scripting while helping you build and refine your skills through a fast-paced, engaging approach. Whether you're just starting out or already have experience and want to strengthen your scripting abilities, this challenge offers daily exercises and practical examples to boost your understanding and confidence in Bash. Feel free to fork the repository and get started: https://lnkd.in/g5ccY6Fc

Bash Scripting for DevOps — Part 11/? Till now, I was passing values using environment variables. That worked. But I realized something. Sometimes, I don’t want to set variables separately.I just want to pass values directly when running the script. That’s where arguments come in. In Bash, we can pass values like this: ./deploy.sh staging Inside the script, we can access it using: echo "Deploying to $1 environment" Here, $1 means the first argument. So if I run: ./deploy.sh prod It becomes: Deploying to prod environment This makes scripts much more flexible. Instead of editing the script or setting variables, I can just pass what I need at runtime. This is used a lot in real DevOps workflows: • passing environment names • passing versions or tags • controlling script behavior dynamically Small change. But now the script feels more like a real tool, not just a fixed set of commands. #DevOps #BashScripting #Linux #Automation #DevOpsJourney #LearningInPublic

Day 17 of #90DaysOfDevOps 💻🔥 Today I dived deeper into Shell Scripting and learned how to make scripts more powerful and practical. ✔ Practiced for & while loops ✔ Worked with command-line arguments ($1, $#, $@) ✔ Built small scripts to automate tasks ✔ Learned basic error handling 💡 Biggest learning: Using arguments makes scripts reusable and dynamic — not just static commands. ⚡ Real-world DevOps use: Shell scripts are used daily for automation, deployments, monitoring, and backups. Consistency is building confidence 🚀 #DevOps #Linux #ShellScripting #Automation #90DaysOfDevOps

🚀 Day 21 of #90DaysOfDevOps 📘 Today was all about building my own Shell Scripting Cheat Sheet After learning scripting for the past few days, I consolidated everything into a quick reference guide I can reuse anytime. 💡 What I covered: Shebang, variables, and user input Conditionals & operators Loops (for, while, until) Functions & arguments 🧠 Key Learning: Writing your own cheat sheet = best way to revise + truly understand concepts 💼 Real DevOps Use: Quick reference saves time while writing scripts for automation, debugging, and deployments ⚡ Consistency > Perfection 🔥 #DevOps #ShellScripting #Linux #Automation #LearningInPublic #90DaysOfDevOps

🚀 Day 21/90 – DevOps Learning Journey Today I created my own Shell Scripting Cheat Sheet after completing multiple hands-on scripting tasks. 🔹 What I covered • Bash basics, variables, arguments • If-else, loops, functions • File checks and logical operators • Powerful tools: grep, awk, sed, sort, uniq • Real-world one-liners for log analysis • Error handling using set -euo pipefail 💡 Key Learning Writing a cheat sheet forced me to organize concepts clearly — Now I can quickly debug scripts without searching documentation every time. This will be my go-to reference during real DevOps tasks 🚀 Consistency is building confidence day by day 💪 #90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham #ShellScripting #Linux #Automation

Day 19 of #90DaysOfDevOps 💻🔥 Today I built my first real-world automation scripts using Shell Scripting. ✔ Created a log rotation script (cleanup + compression) ✔ Built a server backup script using .tar.gz ✔ Automated tasks using crontab scheduling 💡 Biggest learning: Automation isn’t just writing scripts — it’s about making systems run without manual effort. ⚡ Real-world DevOps use: These concepts are used in log management, server backups, and scheduled maintenance in production systems. From learning → to building → to automating 🚀 #DevOps #Linux #ShellScripting #Automation #Crontab #90DaysOfDevOps

Day 20 of learning and practicing DevOps 🔁 Worked on scripting project — building a log analyzer and report generator Worked on: • Reading and validating log file input • Counting errors (ERROR, Failed) using grep • Extracting critical events with line numbers • Finding top 5 recurring errors using awk, sort, uniq • Generating a structured report file • Archiving processed logs automatically Important part: Instead of manually reading logs, I built a script that analyzes everything and gives a summary in seconds. Learning today--> logs tell the story turning raw logs into useful insights. Here are my notes: https://lnkd.in/ga8xUT6U 📍 #DevOps #Linux #ShellScripting #Automation #LogAnalysis #LearningInPublic #90DaysOfDevOps #TrainWithShubham

:::writing{variant=“social_post” id=“48321”} Ever run ls and feel like everything is under control… until ls -a exposes the chaos? 😅 That’s DevOps in a nutshell. What looks clean on the surface often hides: • Hidden configs • Environment variables • Secrets & keys • Dependency overloads The real work starts when you go deeper. 💡 Lesson: Don’t just trust what’s visible. Great engineers explore the hidden layers — that’s where the real problems (and solutions) live. #DevOps #Linux #EngineeringLife #Debugging #TechHumor #Learning :::

Ansible Conditionals: Using "when" Statements to Control Task Execution 🎯 Today's task introduced one of Ansible's most important control flow features, the when conditional statement. The goal was to copy different files to different app servers from a single playbook that runs against all hosts simultaneously, with each task only executing on its intended server and being skipped on the others. This is where Ansible starts to feel less like a simple automation tool and more like a proper programming language. The ability to gather facts about remote systems and then make decisions based on those facts is what allows a single playbook to behave differently across an entire fleet of servers without duplicating code. The key variable today was ansible_nodename a fact that Ansible automatically collects from each remote host during the fact-gathering phase. By comparing this value in a when condition, each task knew exactly which server it was meant to run on and quietly skipped the rest. Seeing those skipping messages in the output was actually satisfying because it confirmed the conditionals were working exactly as intended. What I reinforced today: - Using when conditionals to control which tasks run on which hosts in a multi-server playbook - The difference between ansible_nodename and inventory_hostname, and when to use each - How Ansible's fact gathering phase powers conditional logic, no facts means no conditionals - Using ansible -m setup -a "filter=ansible_nodename" to verify the exact value Ansible sees before writing conditions - Understanding that skipping in the play output is not an error, it is confirmation that conditionals are working correctly - Always running --check mode first when working with file copy tasks that have specific permission and ownership requirements 💡 Writing one playbook that intelligently handles multiple servers differently is far more scalable than writing separate playbooks for each server. Conditionals are what make that possible. Still learning. Still building. Still pushing forward! 🚀🎯 #DevOps #Ansible #Automation #Linux #AnsibleConditionals #ConfigurationManagement #InfrastructureAsCode #ContinuousLearning #TechJourney #Day93 #100DaysOfDevOps