In PowerShell, what actually travels between two commands joined by the pipe operator, and how does that differ from a pipeline in bash?

## Two different contracts A Unix shell pipeline is defined by one contract: a process writes bytes to standard output and the next process reads bytes from standard input. Nothing else crosses the boundary. Every program therefore renders its internal data into text for display, and every consumer must parse that text back into fields. That round trip is where `awk '{print $2}'`, `cut -d: -f1` and a lot of fragile quoting come from: structure the producer already had is thrown away at the pipe and guessed at on the other side. PowerShell changes the contract. A cmdlet is a .NET class that *emits objects*, and the pipe hands those object references straight to the next command in the same process. `Get-Process` does not print a table; it emits `System.Diagnostics.Process` instances. `Get-ChildItem` emits `System.IO.FileInfo` and `System.IO.DirectoryInfo`. The rendering you see happens only when nothing else consumes the objects and they fall out of the end of the pipeline into the default output path. ## What objects remove ```powershell Get-Process | Where-Object CPU -gt 10 | Sort-Object CPU -Descending | Select-Object -First 5 Name, Id, CPU ``` Nothing in that pipeline parses anything. `Where-Object` evaluates a comparison against the `CPU` property, `Sort-Object` sorts on the property's real numeric value, and `Select-Object` projects three named properties. In a text shell each of those steps needs to know a column index or a delimiter, and each breaks the day a value contains the delimiter. Three concrete consequences follow: - **No field-splitting bugs.** A file named `My Report.txt` is one property value, not two fields. - **Types survive.** A `DateTime` property compares chronologically, not lexically; a size compares as a number, so `Where-Object Length -gt 1MB` is meaningful. (`1MB` is real PowerShell numeric-literal syntax.) - **The data is discoverable at runtime.** `Get-Process | Get-Member` prints the type name plus every property and method. There is no equivalent for a text stream — you can only look at it and guess. ## What you see is not what flows The most common beginner error is believing the console table *is* the data. It is not. When objects reach the end of the pipeline they are passed to the formatting layer, which consults per-type formatting rules to decide which properties to show and whether to use a table or a list. `Get-Process` displays a handful of columns while the object carries dozens of properties; `Select-Object *` or `Format-List *` reveals the rest. This is also why `Format-Table` and its siblings must be last: they replace your objects with internal formatting-instruction objects (types in the `Microsoft.PowerShell.Commands.Internal.Format` namespace) that only the output cmdlets understand. If you want data in a file, serialize the objects — `Export-Csv`, `ConvertTo-Json`, `Export-Clixml` — rather than capturing the rendered text. ## Where the object model leaks PowerShell still lives in a world of ordinary executables. When you run `git status` or `ping` inside PowerShell, that program writes text, and PowerShell wraps it as `System.String` objects — one per output line. So this works: ```powershell git status --porcelain | Where-Object { $_ -like ' M *' } ``` but `$_` there is a string, not a structured object, and you are back to matching patterns. `$_` (also spelled `$PSItem`) is the automatic variable holding the current pipeline item. Some cmdlets deliberately re-introduce structure at that boundary: `Select-String` returns `MatchInfo` objects with `Line`, `LineNumber`, `Path` and `Matches` properties rather than raw text, which is why it composes better than a bare grep-style filter. ## What it costs Objects are not free. Every item is a live .NET object, so a pipeline over a very large stream pays allocation and per-item cmdlet overhead that a tight C program reading bytes does not. PowerShell pipelines are usually slower than the equivalent text pipeline on huge inputs, and a language-level `foreach` loop over an in-memory collection is faster still than the pipeline machinery. You also inherit .NET's shape: interop with the wider Unix tool ecosystem happens through strings at the edges, and objects only travel intact between PowerShell commands. The honest summary for an interview: PowerShell trades raw throughput and universality for structure that does not have to be re-derived at every stage, and the biggest adjustment coming from bash is to stop reading the screen and start asking `Get-Member` what you actually hold.