Exercise 1: Object Pipeline vs. Text Pattern Matching — Possible Solution
====================================================================

THE BASH VERSION'S REAL RISK
------------------------------
The chapter's Bash example - "ls -la | grep '\.txt$' | wc -l" - never actually knows what a file extension is. It only knows that a LINE OF TEXT happens to end in the four characters ".txt". That's a pattern match against formatting, not a query against real file metadata. A filename that legitimately ends in ".txt" inside a longer string (or a directory entry whose "ls -la" line is formatted slightly differently by a different ls implementation or locale) can silently produce a wrong count, and nothing about the pipeline would signal that anything went wrong.

WHY THE POWERSHELL VERSION DOESN'T HAVE THIS PROBLEM
------------------------------
"Get-ChildItem | Where-Object Extension -eq '.txt' | Measure-Object" never touches text at all. Get-ChildItem returns real file objects, and each one already carries an actual "Extension" property set by the .NET filesystem APIs underneath - not reconstructed from a formatted text line. Where-Object compares that real property directly. There's no regex, no column position, no formatting to drift out from under the pipeline.

THE GENERAL PRINCIPLE
------------------------------
"Same command name" (ls in both worlds, grep vs. Where-Object) is not "same guarantee." Bash's pipeline is only as reliable as the text format everyone downstream agrees to parse; PowerShell's pipeline is as reliable as the object's own real properties, which can't drift the way formatted text can.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly identifies that Bash's grep is matching formatted text rather than querying real metadata, explains the concrete failure mode (a formatting/locale change silently breaking the count), and correctly attributes PowerShell's own reliability to querying a genuine object property (Extension) instead of reconstructing one from text.