[integraton]

PowerShell's object pipeline only exists within the PowerShell/.NET runtime and is functionally analogous to method/function chaining in languages like JavaScript and Ruby. The object pipeline does not exist outside of the PowerShell/.NET runtime.

Pipelines in Unix shells use OS-level functionality to connect standard streams of data, often encoded as text, between arbitrary executables written in any language.

The reason this is confusing is because one of the main tactics used in PowerShell promotion is to disingenuously compare PowerShell's "object pipeline" to Unix pipelines in order to try to make it appear to be more novel than it is, when they should be comparing it to what it's functionally equivalent to, which is function chaining within a single runtime.

[useerup]

> which is function chaining within a single runtime

If PowerShells pipelines are merely equivalent to function chaining, then you should have no problem replicating the following very simple pipeline with function chaining in Ruby, Python or JavaScript:

    cat log.txt -wait | sls "error"

In case you need an explanation for what it is doing: It continously monitors the log.txt file for new lines, and selects those that contains the substring "error".

But I am curious: Why is it important whether the pipelines could be implemented using function chaining or not? PowerShell is a shell where I interact with the system through commands. Yes - those commands are not the typical Unix executables - but they act as commands within the shell

Is your problem that it is not a Unix shell? You could equally well say that Unix shell pipelines are just processes connected by file descriptors. That is factually correct but does not represent the true utility of pipelines.

PowerShell pipelines are not file descriptors. PowerShell commands do not execute in separate processes. But PowerShell commands are versatile and can be combined in a way analogous to Unix shell pipelines where the output of one command is consumed and acted upon by the next command.

The object of a operating system command line shell is to expose the operating system features to the user of the shell. Why does it matter whether it uses Unix file descriptors. Even if PowerShell pipelines were equivalent to "just" chained functions, why does it matter?

I get the point that you need the .NET runtime to run PowerShell, because it is implemented using .NET. At what point do we consider a runtime part of the operating system. When it is intrinsically distributed with the operating system and cannot be uninstalled?

[kbenson]

To underscore how the idea of a UNIX shell working on file descriptors between executables isn't really important, it's worth nothing that bash allows piping between it's built in commands/keywords. Not only can you pipe the aggregates output from a for, if or while construct, you can pipe the output of bash builtins such as bg, fg and disown.