|
|
|
|
|
by forgotpwd16
214 days ago
|
|
What GP talks about is illustrated with the following modification of your example: PS /home/user> gc *.txt | measure | cat | select -ExpandProperty Count
Select-Object: Property "Count" cannot be found.
Select-Object: Property "Count" cannot be found.
Select-Object: Property "Count" cannot be found.
Select-Object: Property "Count" cannot be found.
Select-Object: Property "Count" cannot be found.
Select-Object: Property "Count" cannot be found.
Select-Object: Property "Count" cannot be found.
Select-Object: Property "Count" cannot be found.
Select-Object: Property "Count" cannot be found.
Essentially at every step you need to consider whether the preceding command outputs objects or not. This isn't the case with the Unix way. The pipeline always carries a stream of bytes. You only have to consider how to interpret that stream. |
|
This is true, no matter what language, paradigm, or even universe you're in; data that gets passed into a pipeline needs to have the abstract shape that the pipeline expects. This is always true, and it's every bit as true of unix byte streams.
You can of course have pipelines that try to coerce data or assert its structure. The PowerShell example you showed does the latter, and raises an error message that the assertion failed.
Unix byte streams do neither. There's no coercion, no assertion. Just blind trust. When you have IFS set incorrectly, you simply get a wrong answer. When you grab the wrong field number with cut or awk, you get a wrong (or empty) answer. The input data matters every bit as much with unix as it does with every other system of computation. What changes are characteristics like brittleness and enforceability of invariants.