Forem: Dan Higgins

Day 1 - Linux for DevOps: The Mindset Shift

Dan Higgins — Sun, 23 Nov 2025 20:56:21 +0000

Welcome to Day 1 of 30 Days of Linux for DevOps!
If you’re here, you already know something important:

DevOps isn’t about tools… it’s about knowing what’s happening under the hood.
And the engine under almost every cloud service, container, CI/CD runner, and Kubernetes node is Linux.

Today isn’t about memorizing commands.
It’s about building the DevOps mindset that connects Linux → Cloud → Automation → Systems thinking.

So let’s kick things off.

📚 Table of Contents

What makes Linux for DevOps different from Linux for beginners?
Today’s Goal: Learn how DevOps engineers observe a system
See where you are (DevOps style)
Navigate like you're working in production
See what your system is doing right now
View logs like an SRE
Today’s DevOps mini challenge
Day 1 Wrap Up

What makes Linux for DevOps different from Linux for beginners?

Beginners learn commands so they don’t feel lost.
DevOps engineers learn commands because they need to debug, automate, optimize, and control systems at scale.

Here’s the difference:

Beginner:

“ls shows files.”

DevOps Engineer:

“ls -lh tells me file sizes, permissions, ownership, and helps me spot weird stuff in log directories.”

Same command.
Different purpose.
Different mindset.

Today’s Goal: Learn how DevOps engineers observe a system

Before you automate anything, deploy anything, or build anything…
you must know how to look at a system and understand what’s going on.

So today we cover the DevOps essentials:

✔ What's running
✔ What's using resources
✔ How to find logs
✔ How to navigate like a pro

Let’s jump in.

See where you are (DevOps style)

Forget plain pwd.
We add context:

Why this matters:
Every server, container, or Kubernetes node could be different.
A DevOps engineer always checks:

Who am I? (User, root, restricted?)

Where am I? (Directory? Partition? Container?)

What machine am I on? (Production? Staging? EC2?)

This prevents mistakes like… deploying to the wrong environment.
(I'm just glad it's in the sandbox!)

Navigate like you're working in production

Skip the basics — let’s use flags DevOps engineers actually use:

Why?
-a shows hidden files (very important for configs).
-h shows sizes you can read (1K, 10M, 1G).
-l shows ownership + permissions.

This is how you spot things like:

log files exploding in size

weird hidden scripts

wrong ownership on app directories

See what your system is doing right now

This is where DevOps thinking really begins.

✔ Check running processes

✔ Live system view (your new best friend)

Why this matters:
When a service is slow, a pod is failing, or a CI runner is stuck —
your first job is to observe system behavior.

CPU spikes?
Memory leak?
Zombie processes?
You’ll see it here.

View logs like an SRE

Logs are where DevOps engineers spend half their life.
Let’s get comfortable with them from Day 1.

Try this in /var/log:

Then open a log:

Real-time log streaming:

This is how you troubleshoot:

failing services

permission issues

network errors

kernel events

container crashes

If you can read logs, you can fix anything.

Today’s DevOps mini challenge

Create a simple “system snapshot” script and save it:

Make it executable and run it:

Congrats — you just created your first DevOps-style diagnostic tool!

Day 1 wrap up

Today you didn’t just learn some commands.
You learned how DevOps engineers observe, analyze, and understand a system before doing anything else.

This mindset will guide you through the next 29 days — and into real DevOps work.

See you tomorrow for Day 2: “Navigating Logs Like an SRE.”

Let’s keep building something real

Week 1: Talking to the Cloud Like a Pro — Setting Up the AWS CLI on Windows

Dan Higgins — Fri, 20 Jun 2025 19:55:02 +0000

Hey cloud adventurers!

Welcome to Week 1 of my new weekly series:
“From Terminal to Cloud: My Linux + AWS Project Journey”
Each week, I’ll share a hands-on AWS project (powered by Linux + the AWS Free Tier) to help cement my knowledge and build toward passing the AWS Solutions Architect Associate exam — and maybe help you do the same!

But before we launch EC2s, wrangle S3 buckets, or ride CloudFront like a cowboy — we need to gear up with our most powerful tool:

The AWS Command Line Interface (CLI)
AKA the magic wand that lets you talk to AWS like a developer-ninja-architect hybrid.

📚 Table of Contents

Why the AWS CLI?
Step-by-Step: Installing the AWS CLI on Windows
Step 4: Configure the CLI
Test Your Setup
Want This on Linux Too?
What’s Next?

Why the AWS CLI?

If the AWS Console is the shiny showroom, the CLI is the garage with all the tools.

Deploy stuff in seconds
Automate backups
Control every AWS service from the command line
Look like a total legend in screenshots

Step-by-Step: Installing the AWS CLI on Windows

Step 1: Download the installer

Go to the official AWS CLI v2 download page and grab the Windows installer. Link here

Step 2: Run the installer

Double-click the .msi file and click through the wizard like a seasoned wizard

Step 3: Verify the install
Pop open Command Prompt (cmd) or PowerShell and type aws --version

Step 4: Configure the CLI

You’ll need your AWS credentials. If you don’t have them yet:

Log into your AWS Console
Go to IAM > Users
Create a new user (if needed) with Programmatic access
Attach the policy AmazonS3FullAccess or AdministratorAccess (if you're just testing in the Free Tier)
Download the access keys safely

Then in your terminal, run aws configure

It’ll ask for:

AWS Access Key ID [None]:
AWS Secret Access Key [None]:
Default region name [None]: eu-west-1 (closest to me in Northern Ireland, and totally Free Tier supported!)
Default output format [None]: json

Once completed it will look like this when you next run the command

Test Your Setup

If you see your account info, you're ready to roll! I've redacted mine - just in case!

Want This on Linux Too?

I did this setup on Windows, but if you’d like a Linux walkthrough (especially from my Red Hat environment), just let me know in the comments or messages and I’ll happily whip one up!

What’s Next?

Next week in Project 1, we’ll:

Use the CLI to create an S3 bucket
Upload files to it
And even host a static website on it — with CloudFront swagger

Stay tuned, and if you’re following along, tag me and let’s build this AWS + Linux skill stack together!

AWS #Linux #AWSCLI #CloudComputing #DevOps #100DaysOfCloud #FromTerminalToCloud

Day 5 of #30DaysRHCSAChallenge — The Sticky Bit Strikes Back

Dan Higgins — Mon, 02 Jun 2025 19:32:29 +0000

Welcome to Day 5, where we enter the secret lair of Linux file permissions and uncover magical artifacts like SUID, SGID, and the legendary Sticky Bit.

By the end of today, I half expected my Linux box to start chanting spells.

📚 Table of Contents

Today’s Lab of Doom
Challenge Breakdown
Spellbook of the Day
What I Learned (aka Lessons from the School of Bashcraft)
RHCSA Objectives Crushed Today
TL;DR
Coming Tomorrow — Day 6

Today’s Lab of Doom

I created shared directories. I tested who could delete what. I accidentally gave a file SUID powers and it felt like I’d handed a toddler the root password.

Challenge Breakdown

Create a shared folder for a group
- Add the SGID bit so group inheritance works
- Set the Sticky Bit so users stop deleting each other’s stuff
- Play with SUID on files (but not for evil)
- Review file permissions like a digital detective

Spellbook of the Day

mkdir /sysops_team - We're making a shared workspace — like a digital whiteboard everyone can write on.
chown :devops_team /sysops_team - Assigns the group ownership to devops_team, so all group members have access.
chmod 2775 /shared_team - This ensures any file created inside /sysops_team will automatically belong to devops_team, keeping things tidy and collaborative.
chmod +t /sysops_team - Prevents team sabotage! Only the person who created a file (or root) can delete it, even though everyone can write in the directory.
chmod u+s /usr/bin/passwd - This lets regular users change their passwords because passwd runs with root’s power, even though they’re not root. Use with caution!
ls -l /shared_team - The inspection tool! This reveals whether your SGID and Sticky Bit are set correctly, and lets you marvel at your sysadmin wizardry (or lack of in this case!)

What I Learned (aka Lessons from the School of Bashcraft)

SGID = “Group loyalty forever!” Files created in that folder will inherit the group.
Sticky Bit = “You can’t delete my files, Karen.” Only the file owner (or root) can delete.
SUID = “Run me as the file’s owner.” Mostly used on programs like passwd. Don't mess this up unless you're aiming for hacker-of-the-month.
Watching ls -l change after each permission tweak is like checking the weather during a storm.

RHCSA Objectives Crushed Today

Manage special permissions like SUID, SGID, and Sticky Bit
Understand secure collaboration through group permissions
Level up in terminal-based trust issues

TL;DR

Today I learned that Linux file systems have more trust issues than my last team project in university. But at least chmod doesn’t ghost you.

Coming Tomorrow — Day 6

Mountains, Devices & Eternal Confusion
(AKA: "Why does my USB drive disappear when I sneeze?")

Day 4 of #30DaysRHCSAChallenge – Who Knew File Permissions Had More Drama Than a Reality Show?

Dan Higgins — Sun, 01 Jun 2025 19:56:00 +0000

Today I faced the Linux filesystem like a cautious archaeologist discovering an ancient tomb… only the tomb had permissions issues, missing files, and a bash tantrum.

📚 Table of Contents

Mission
The Journey
What even happened
Lesson of the Day
RHCSA Objectives Smashed
Today I Learned
Tomorrow

Mission

Master file and directory permissions
Practice chmod, chown, umask
Not break the internet while doing it

The Journey

Created a directory

Gave our heroic dev some ownership

Then came the dramatic moment: writing HTML into a file.

I confidently typed and Bash exploded with bash: !: event not found!

What even happened

Turns out Bash thought ! meant "find a command from history" instead of just letting me express my hot take on cats.

Also… I forgot to include the actual file name, so Bash tried to write into a directory. Double fail.

Lesson of the Day

Use single quotes when your string contains a '!'. File written. Permissions set. Cat lovers pleased.

RHCSA Objectives Smashed

Set file and directory ownership and permissions
Created and manipulated files in nested directories
Debugged Bash behavior like a command-line therapist
Learned to never trust a ! inside double quotes

Today I Learned

chmod and chown are your best friends—and occasional drama queens
Bash has feelings, especially about exclamation marks
Always specify the full file path, or Bash gets confused and dramatic

Tomorrow

We dive into umask, default permissions, and why new files sometimes act like they’re born with an attitude.

Follow the full series here: #30DaysRHCSAChallenge on Dev.to

And yes, I'll probably make a sticker that says "Don't double quote your !"

Day 3 of #30DaysRHCSAChallenge – Group Therapy (For Users, Not Me... Mostly)

Dan Higgins — Sat, 31 May 2025 19:17:04 +0000

📚 Table of Contents

The Real World Problem
Today’s Mission
Commands I Used (and promptly typo'd the first three times)
RHCSA Objectives Covered
What I Learned Today
Real Life Analogy Time
Tomorrow’s Challenge Teaser

The Real World Problem

"Why is this user part of six different groups? Are they building servers or starting a band?"

If you've ever stared at the output of groups and thought,

"Wait, what even is a 'secondary group'?"
then today's your kind of chaos.

Today’s Mission

Understand primary vs secondary groups (like best friends vs group chats you're stuck in)
Create groups manually
Add users to one or more groups
View group membership
Remove users from groups without deleting the group or starting a system-wide rebellion

Commands I Used (and promptly typo'd the first three times)

Bonus spell: see all groups on the system:

RHCSA Objectives Covered

Create and manage groups
Manage user group memberships
Understand primary and secondary group differences
Use commands like usermod, groupadd, groupdel, and gpasswd

What I Learned Today

The primary group is like your day job. The secondary groups are your side hustles.
usermod -aG is your friend — forget the -a and you accidentally wipe all other group memberships
getent group feels like snooping on everyone’s backstage passes

Real Life Analogy Time

If users are people in a company, then groups are:

devops_team – who gets access to deploy
finance – who sees the money stuff
lunch_club – okay this one’s unofficial but still important

Assign wisely. Because one wrong group and suddenly “Susan from HR” has root access to /var/www.

Tomorrow’s Challenge Teaser

“Wait… I thought that file belonged to me?”

Day 4 is all about ownership, permissions, and why chown is a blessing and a curse.

What’s your weirdest group name on your Linux box?
Mine’s kettlegang. Long story.

RHCSA #LinuxAdminLife #UserGroupDrama #30DaysChallenge #BeginnerToBoss #SysadminChronicles #RHEL9 #CommandLineConfidence #DevTo #KeepLearning #RealWorldRHCSA

Day 2 of #30DaysRHCSAChallenge – Who Gave the Intern sudo?!

Dan Higgins — Fri, 30 May 2025 15:19:12 +0000

📚 Table of Contents

The Real World Problem
Today’s Mission
Commands I Used
RHCSA Objectives Covered
What I Learned (the hard way)
Tomorrow’s Challenge Teaser

The Real World Problem

You’ve got a shiny new junior dev on the team. They need sudo access to restart a service... and next thing you know, your web server is down and /etc/ is crying.

Today’s challenge: Give the right people the right power—without accidentally handing them the keys to the kingdom.

Today’s Mission

Add a user to the wheel group (aka: the VIP club for sudo users)
Check who else has sudo rights
Configure sudo access safely via /etc/sudoers
Bonus: Set up a custom sudo rule for a specific command (if you're feeling spicy!)

Commands I Used

Checked the sacred scrolls of sudo:

(Seriously, use visudo, not your usual editor—it’s got safety checks so you don’t accidentally break your entire system trying to be helpful.)

RHCSA Objectives Covered

Manage local user security
Configure sudo access
Understand /etc/sudoers and the wheel group

What I Learned (the hard way)

Adding someone to the wheel group is like giving them the “admin lightsaber.” Use responsibly.
visudo saves lives (and jobs).
Sudo abuse is real—and totally traceable. Your logs will snitch.

Tomorrow’s Challenge Teaser

Tomorrow we take a peek into the hidden world of groups. Primary, secondary, and why “newdev” is in six of them.

Want to follow along?
Post your commands, share your fails, and tag your fellow sudo warriors.

Linux #RHCSA #30DaysChallenge #SudoSaga #DevTo #SysadminLife #BeginnerToBoss #RHEL9 #CommandLineChronicles

Day 1 of #30DaysRHCSAChallenge – Why Can’t This User Log In?

Dan Higgins — Thu, 29 May 2025 19:30:50 +0000

📚 Table of Contents

The Real World Problem
Today’s Mission
Commands I Used
RHCSA Objectives Covered
What I Learned (or Screwed Up)
Tomorrow’s Challenge Teaser

The Real World Problem

You just created a new user… but they can't log in. They’re already on Slack asking why “Linux hates them personally.” You check your work—and oops. You forgot to give them a shell or a home. Rookie move, but hey, we've all been there.

Today’s Mission

Create a user with a home directory
Set their password
Make sure they’re assigned a default shell
Confirm they can log in and run basic commands

Commands I Used

Then I double-checked:

RHCSA Objectives Covered

Create and manage local users and groups
Set passwords and default shell
Understand the /etc/passwd and /etc/shadow files

What I Learned (or Screwed Up)

Not using -m creates a user without a home—unless you're creating a ghost.
No shell = no login = frustrated coworkers.
/etc/passwd is like a user phonebook. If your name isn’t in there correctly, you’re not getting through the door.

Tomorrow’s Challenge Teaser

Tomorrow we tackle the dangerous art of giving users sudo powers… and how to not accidentally let an intern nuke your server.

Linux #RHCSA #30DaysChallenge #SysadminLife #DevToSeries #BeginnerToBoss

Day 30 of #30DayLinuxChallenge — From “Wait, What’s a Terminal?” to “Let’s Partition This Thing!”

Dan Higgins — Fri, 23 May 2025 20:30:50 +0000

Subtitle: How I went from Linux newbie to loopback-creating, file-permission-setting, disk-wrangling warrior in just 30 days.

30 days ago, I sat down in front of a terminal window and thought,

“How hard can Linux be?”

Cue dramatic zoom-in on my face as I accidentally chmod'd the wrong directory, couldn’t find /dev/sdb no matter how many times I begged it to appear, and got error messages that looked like they were written by an angry toaster.

But guess what?

I showed up the next day.
And the next.
And the next after that.

📚 Table of Contents

What I’ve Learned
What I’ve Overcome
Why Challenges Like This Matter
What’s Next? RHCSA, Meet RHCE
To Future Me (and maybe Future You)

What I’ve Learned

These 30 day's weren’t just about commands — they were about transformation. I learned:

How to create users and make sure they can’t see my secret tea logs
How to mount things that don’t technically exist (hello, loopback devices!)
How to partition, format, and set up logical volumes like a junior sysadmin
How to break things, Google like a detective, and fix them with newfound pride
That VirtualBox will test your patience, but perseverance pays off

And perhaps most importantly…

That being a beginner isn’t a weakness — it’s the most powerful place to start.

What I’ve Overcome

Fear of the terminal: Now, I don’t just type in commands — I understand them.
Frustration with errors: I’ve learned to read, troubleshoot, and even enjoy the chase.
Imposter syndrome: That little voice that said “You can’t do tech”? Yeah, it’s quieter now.

Every sudo, every permission flag, every mysterious error message has helped me rewrite that voice with one that says:

“You’re getting this. You belong here.”

Why Challenges Like This Matter

Doing a #30DayChallenge isn’t just about streaks or posts. It’s about:

Consistency over perfection.
Learning publicly and proudly.
Turning confusion into curiosity, and curiosity into confidence.

It’s about building habits, community, and resilience — all essential for anyone stepping into tech.

If you’re reading this and wondering whether you can do it — you can.
Your first ls is just as important as your first lvm command.

What’s Next? RHCSA, Meet RHCE

Now that I’ve got the RHCSA mindset, tools, and battle scars, it’s time to level up.

Next stop: RHCE.

More automation. More scripting. More “Whoa, I didn’t know Linux could do that.”

And just like this challenge, I’ll be logging my journey, wins, struggles, and probably another round of confused looks at missing disks.

To Future Me (and maybe Future You)

Remember Day 1? You didn’t know the difference between chmod and chocolate.

Now you’re the person who teaches others what that means.

Keep showing up.
Keep typing.
Keep learning.

And when it gets hard, just say:

“Challenge accepted.”

Thanks to everyone who’s been following my journey. Stick around — the next adventure is already booting up.

Linux #30DayChallenge #RHCSA #BeginnerToPro #LearningInPublic #TechJourney #RHCEPrep

RHCSA Prep for Absolute Beginners: The “Diskless but Determined” Edition

Dan Higgins — Fri, 23 May 2025 20:20:51 +0000

Subtitle: When your second disk refuses to show up, but your Linux spirit refuses to back down.

📚 Table of Contents

Welcome to the RHCSA Arena!
First, Let’s Deal With This Missing Disk Situation
Part 1: Practice File Permissions Like a Boss
Part 2: Master User & Group Management
Part 3: Practice Mounting Like a Pro (No New Disk Required!)
Part 4: Manage Services Like a Sysadmin Ninja
Part 5: Bonus Scripting Practice
Final Words of Wisdom

Welcome to the RHCSA Arena!

You’ve fired up your RHEL 9 VM, flexed your typing fingers, and bravely typed lsblk… only to be ghosted by /dev/sdb. But guess what? You’re still in the game. And this guide is for you — the Linux warrior who keeps going, one command at a time.

First, Let’s Deal With This Missing Disk Situation

If you tried lsblk and /dev/sdb is still in hiding, it's okay. You can still practice tons of RHCSA skills using the space and partitions you already have. Let’s pivot to the real-world RHCSA tactics you can conquer right now:

Part 1: Practice File Permissions Like a Boss

Make your own top-secret coffee log:

This is the command line equivalent of putting your diary under lock and key.

Part 2: Master User & Group Management

Because every RHCSA candidate should know how to create a user who respects a properly brewed cup of the sweet bean juice.

Part 3: Practice Mounting Like a Pro (No New Disk Required!)

Create a loopback device — it's like a pretend disk:

I'll admit, this was a hard one to grasp but perseverance and hard work paid off! I debated whether to keep my mistakes in and re-do it to make it look clear, but sometimes, we need to own our mistakes and embrace them, that's how we learn, and grow.

Boom. Fake disk. Real experience. Zero stress.

Part 4: Manage Services Like a Sysadmin Ninja

Learn to control services. Become the puppet master of your system.

Part 5: Bonus Scripting Practice

Create a basic shell script because scripts are sexy and RHCSA loves them:

Save it as brew.sh, make it executable.

Boom. You just automated a task. Hire yourself.

Final Words of Wisdom

Don’t let hardware hiccups stop your hustle.
The RHCSA is as much about mindset as it is about commands.
You’re learning. You’re practicing. And that’s more powerful than a second disk.

Need help fixing VirtualBox or creating more real-world practice scenarios with what you have? I’ve got you. Just say the word.

Day 10: CTRL+ALT+WOW — Our Command-Line Glow-Up Recap!

Dan Higgins — Fri, 23 May 2025 19:24:53 +0000

Welcome to Day 10 of our 10-part beginner-friendly journey into RHEL 9 — aka Linux for Real People Who Like Laughing and Learning.

If you've stuck with me from Day 1, then congratulations: you now officially know more Linux than the average cat (and I'm not just talking about cat filename.txt).

Today isn’t about new commands — it’s about honoring the wild ride we’ve had. Think of this as the terminal-themed version of a high school yearbook. Let’s roll back through the bashful beginnings, the pipe-dreams, and the chmod-fueled chaos...

📚 Table of Contents

Day 1: pwd Where’s My Shell At?
Day 2: mkdir Mayhem
Day 3: The Assassins of the Shell
Day 4: Permission, Please
Day 5: Backup Before You Break It
Day 6: Finders Keepers
Day 7: Top Secrets & Sneaky Processes
Day 8: Let’s Get Greppy
Day 9: Pipes, Please!
So, What Now?
Your Next Steps:
Final Words (Before I exit)

Day 1: pwd Where’s My Shell At?

We kicked off lost in a terminal window — unsure of who we were, where we were, or what planet /home/user existed on. But pwd and ls gave us a sense of location, and suddenly we weren’t terminal tourists anymore.

Day 2: mkdir Mayhem

We got bold. We made directories. Nested folders. Rebelled against mkdir fail messages. We became creators — and occasionally destroyers (looking at you, rmdir).

Day 3: The Assassins of the Shell

Enter touch, cat, and rm. We met the quiet librarian who shows us file contents… and the file hitman who doesn’t ask any questions. We touched greatness — and sometimes deleted it by accident.

Day 4: Permission, Please

It was time to get serious. We met the cryptic rw-r--r-- code and learned how to claim ownership with chown and wield power (safely-ish) with chmod. We made secret diaries, and hopefully, no one sudoed into them.

Day 5: Backup Before You Break It

We faced real-world panic: “Did I just overwrite my project folder with a typo?” Cue cp, mv, and the almighty man to explain everything in tiny font. We survived. Just barely.

Day 6: Finders Keepers

Files were lost. Tempers were tested. But find, head, tail, and wc made us detectives of the filesystem. We counted lines, sniffed out files, and peeked inside logs like responsible hackers.

Day 7: Top Secrets & Sneaky Processes

We peeked behind the curtain. top, ps, and uptime helped us spy on our system like digital spies. And free -h told us how much memory our chaos was using.

Day 8: Let’s Get Greppy

If grep were a person, it’d be that friend who finds exactly what you're ranting about in the group chat. We became pattern-hunters, search wizards, and logs no longer scared us.

Day 9: Pipes, Please!

You mastered the ancient art of chaining commands together like a Linux wizard. |, >, >>, and < turned us from button-mashers into elegant stream-benders. Power. Flow. Control.

So, What Now?

If this journey proved anything, it’s this:

You don’t need to be “technical” to learn Linux. You just need curiosity, caffeine, and a little chaos.

You now know how to:

Navigate your way out of /etc/panic
Create and delete files like a cool kid
Read logs, manipulate text, monitor systems
Chain together commands with confidence

You’ve built real command-line muscle — one typo at a time.

Your Next Steps:

Try out a personal Linux project. Make a Bash script. Break something (then fix it!).
Start exploring tools like cron, ssh, scp, or the package manager dnf.
Study for RHCSA if you’re certification-curious.
Share your journey — because the terminal isn’t as lonely as it looks

Final Words (Before I exit)

To everyone who followed along — thank you. Your comments, encouragement, and “oh no I deleted everything” messages made this adventure feel like a community campfire… with slightly more chmod.

Until next time:

echo "Goodbye, world!" > final.txt

Catch you on the command line.

— CloudWhistler

Day 9: The Mysterious World of Pipes and Redirection in RHEL 9

Dan Higgins — Tue, 20 May 2025 20:06:24 +0000

Welcome to the land of pipes (|) and redirection (> and >>) — where Linux becomes a modular masterpiece. Think of it like Lego for grown-ups (but nerdier and more powerful).

📚 Table of Contents

What are pipes and redirection?
Redirection Basics:
Pipe Magic:
Mini Mission:
Why this rocks
What's Next

What are pipes and redirection?

Redirection sends output somewhere else (like a file).
Pipes connect commands so one’s output becomes the next one’s input.

Redirection Basics:

> — send output to a file (overwrites it)
>> — append output to a file

Now greetings.txt contains "Hello world" and now greetings.txt has BOTH messages.

Pipe Magic:

This lists all files and sends that list to grep, which filters and only shows .txt files.

View system boot messages, but in a scrollable way. No terminal meltdown!

Mini Mission:

Use echo to write a sentence to a file.
Append a second line with >>
Use a pipe to search your .bash_history for the word "sudo"

Why this rocks

This is how Linux pros build supercharged workflows. It's like chaining spells in a video game: each command is strong on its own, but together, they’re unstoppable.

What's Next

Quick Reflection:
You’ve now wrangled files, navigated directories, tamed permissions, and even filtered text like a digital detective. These new tools (grep, pipes, redirection) are your backstage passes to real-world Linux wizardry — and they're way easier than they sound.

Practice them a few times in real scenarios — not just in theory — and they’ll stick for life.

See you tomorrow for Day 10, where we wrap it all up in a command-line bow!

LinuxLearning #RHEL9 #CloudWhistler #BeginnerFriendly #RHCSA #LearningLinux

Day 8: Let’s Get Greppy – Finding Text Like a Pro in RHEL 9

Dan Higgins — Tue, 20 May 2025 19:39:05 +0000

Alright, command-line comrades, it’s time we talk about someone very special…

Grep — the text detective that never sleeps.

If you’ve ever stared at a log file wondering if the answer to your issue is hiding somewhere in 3,000 lines of gobbledygook, grep is your new best friend.

📚 Table of Contents

So what exactly is grep?
Basic Syntax:
Handy Flags for Beginners:
Real World Use:
Mini Mission:
Why It Matters

So what exactly is grep?

Grep stands for Global Regular Expression Print, but don't let the fancy name scare you. It basically means: “Hey Linux, find this text for me, now, please and thank you.”

Basic Syntax:

grep "pattern" filename

Let’s say you have a file called shopping.txt and it looks like this:

apples
bananas
pineapples
chocolate bananas

Run this, and boom — it’ll spit out:

Handy Flags for Beginners:

-i (ignore case)
-n (show line number)
-r (search recursively through directories)

Now it finds both “Banana” and “banana”, and shows which line they’re on. Pretty slick.

Real World Use:

Searching logs for errors:

Finding a user in /etc/passwd:

Mini Mission:

Create a file with different fruit names. Use grep to find your favorites. Bonus points for using -i and -n.

Why It Matters

In a real-world tech job, whether you’re a sysadmin or cloud wizard, you’ll often need to extract one crucial line from a sea of chaos.

Mastering grep saves time, energy, and possibly your sanity.