PowerShell Pipelines Are Objects. Treating Them Like Text Is the Bug

The most expensive PowerShell mistake I see isn’t a missing cmdlet. It’s a mental model: treating the pipeline like Bash with different verbs. You pipe, you scrape text, you wonder why Select-String and Where-Object fight you, and you Google “PowerShell parse output” for the hundredth time.

The bug isn’t PowerShell. The bug is text-shaped thinking in an object pipeline.

What “objects” actually buys you

When you run:

Get-Process | Where-Object CPU -gt 100 | Select-Object Name, Id, CPU

you’re not filtering lines. You’re filtering process objects with properties. Formatting (Format-Table, Out-Default’s magic at the end) is a display concern. If you convert to string too early, you throw away the structure that made the pipeline useful.

Beginners often do this:

Get-ChildItem | Out-String | Select-String "\.log$"

It “works” until it doesn’t—widths, wrapping, culture, and Host formatting all leak into your “data.”

Symptoms you’re text-scraping by accident

• You’re using -split and array indexes on command output that already had properties.
• You rely on Format-* before Export-Csv or further filtering.
• You compare with Select-String against Format-Table output.
• You say “the column moved” about object output.

That last one is the tell. Objects don’t have columns until you format them.

A cleaner habit loop

1. Discover: Get-Member (or gm) on pipeline output once.
2. Filter/select: Where-Object, Select-Object on property names.
3. Sort/measure: still on properties.
4. Format or export last: human view or Export-Csv / ConvertTo-Json.

Example salvage:

Get-ChildItem -File |
  Where-Object Extension -eq '.log' |
  Sort-Object Length -Descending |
  Select-Object Name, Length, LastWriteTime

No regex on rendered tables. No prayer about spacing.

Where text is the right model

PowerShell still talks to a text world: native executables, logs, HTTP bodies, CMD leftovers. Then you parse deliberately—ConvertFrom-Json, Import-Csv, Select-String on raw content—not because the pipeline “is text,” but because that particular source is.

The skill is knowing which side of the boundary you’re on.

Teaching implication

If your first PowerShell lesson is “it’s like Linux pipes,” you’ve planted a weed. Better framing: pipelines pass objects; formatters turn objects into text for eyes.

A before/after that usually clicks

Text instinct (fragile):

Get-Service | Out-String | Select-String "Running"

Object habit (stable):

Get-Service | Where-Object Status -eq 'Running'

Same intent. One survives formatting changes; the other depends on how the host painted the table.

For mixed pipelines (objects + native text)

When you call git, docker, or a vendor .exe, you do get text. Bridge deliberately:

git status --porcelain | ForEach-Object { $_.Substring(3) }

Or better, use tools that emit JSON and ConvertFrom-Json. Crossing the boundary on purpose is expertise. Crossing it by habit is how scripts rot.

Common objections (and replies)

“But Format-Table is fine mid-pipeline for debugging.”

Temporarily, in the interactive host, sure—just don’t leave it in scripts that feed exporters.

“Select-String is powerful.”

It is—on strings. Use it on file content or deliberate string output, not on pretty-printed tables of objects you already owned.

“Bash users live in text and ship software.”

Different contract. PowerShell’s advantage is structure; throwing it away for familiarity is optional, not inevitable.

I care about this because interactive CLI practice has to punish early stringification or learners ship fragile scripts forever. That’s a core drill pattern in CMD Master—catch the model error at the prompt, not in production.

Discuss: When did object-vs-text confusion bite you hardest—and did you blame yourself or the shell?