Can you explain me a bit the difference if you mind (I don't know much about Windows).
In Linux/Unix I can also pipe audio to /dev/audio for example. And image processing through a sequence of steps by pipes is quite often done. Are these objects coming with default metaparameters to make piping easier? Or are there other things implemented that might be cool?
I have never used PowerShell, so I don't know a lot about the details. But PowerShell pipes .NET objects from one command to the next, which are not just bytestreams but are objects, with methods and such. It's fundamentally different.
In UNIX, you have bytes, and the underlying system doesn't know what they represent. Most tools assume they're ASCII or UTF-8 (or whatever) encoded text, but that's all they agree on. In practice, you're working almost always working with structured data - tables or lists or mappings - but you have to remember that for the output of this program, you want to cut on '=' and take -f4, and first you need to pipe it through head and tail to clean up some junk output[1], and this other thing for that program, and whatever.
[1] This is a way to get the `time` field from the output of `ping`.
That's because the object pipeline is functionally analogous to function chaining within a single runtime like in Python or Ruby, not streaming data between arbitrary executables like in Unix pipelines.
This would be a lot clearer if PowerShell advocates compared it to things that it's actually functionally analogous to, but they are trying to position it as a Unix shell competitor.
> You are the same person who tried to falsely claim that cmdlets are not instances of .NET classes
The fact stands, cmdlets can be implemented as .NET classes, but they can also be implemented through script (i.e. not .NET classes) or through manifests where cmdlets are generated for WMI/CIM classes.
I don't know why you continue to ignore this, or even why it is important. I point out that you are incorrect and point to a authoritative source that demonstrate the point.
The relevant section of the PowerShell section:
---
... A module can contain one or more module members, which are commands (such as cmdlets and functions) and items (such as variables and aliases). The names of these members can be kept private to the module or they may be exported to the session into which the module is imported.
There are three different module types: manifest, script, and binary. A manifest module is a file that contains information about a module, and controls certain aspects of that module's use. A script module is a PowerShell script file with a file extension of ".psm1" instead of ".ps1". A binary module contains class types that define cmdlets and providers. Unlike script modules, binary modules are written in compiled languages. Binary modules are not covered by this specification.
Windows PowerShell: A binary module is a .NET assembly (i.e.; a DLL) that was compiled against the PowerShell libraries.
---
I will point out when your claims about PowerShell are incorrect. It's an opportunity to learn something. Please address the topic, not the poster.
> Then those generated cmdlets must be instances of .NET classes, because by definition that's what cmdlets are
Nope. The problem is that you searched for confirmation that cmdlets was "just" .NET classes (I really don't get why that is important), and then you dive into documentation for C# programmers and point out how the documentation for C# programmers is telling the C# programmer that if he wants to create a cmdlet he can do it with a C# class. D-oh!
When I point to the PowerShell specification and demonstrates how it does not claim that cmdlets are .NET classes you ignore it.
I point out how it enumerates the 3 different ways to make cmdlet modules: Binary, script and manifest, of which only the binary module variety implement cmdlets as classes.
You could equally well claim that Web Services are just MVC Controllers, because in the documentation for MVC I can find out how to implement web services using MVC controllers.
> ... and they exist within the .NET runtime, which is the relevant issue
Why? If the .NET runtime has become sediment to the point where the OS is always distributed with the runtime, where important OS functions (like troubleshooting) is implemented using the runtime, where remote administration is based on the runtime, at what point do you accept the runtime as part of the OS?
.NET IS part of Windows now, has been since Windows 7 SP1 (IIRC). Troubleshooting packs, guides etc. are written using PowerShell. When your network gets the hiccups, and Windows proactively offers to troubleshoot the network connection, it is PowerShell that is running underneath. The new PackageManager is PowerShell based.
> Thank you, however, for providing yet another demonstration of how PowerShell advocates consistently resort to handwaving, obfuscation, and false claims in order to try to pretend PowerShell is functionally different than it actually is.
No need for snide remarks. I stand by all of my claims. It is you who selectively quote C# programmers documentation out of context. All you have proven is that if a C# programmer wants to create a cmdlet using C#, he must implement it using a class.
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.
> 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?
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.
"objects" means data structures. It means you can have some structure with fields, or list or array or whatever as the output of one command, and input of the next one, so the next one doesn't have to do character-level parsing.
Of course, this kind of piping is present in nice languages that precede the PowerShell.
A one page Lisp macro will give you a left-to-right syntactic sugar for filtering. Clojure has a threading operator, Ruby has cascades of dots: object.{ blah }.foo().bar() ... and so on.
In Linux/Unix I can also pipe audio to /dev/audio for example. And image processing through a sequence of steps by pipes is quite often done. Are these objects coming with default metaparameters to make piping easier? Or are there other things implemented that might be cool?