3 ms·

> your assertion that cmdlets are .NET classes is both factually wrong They are instances of .NET classes that derive from `Cmdlet` and `PSCmdlet` and run in t

> your assertion that cmdlets are .NET classes is both factually wrong They are instances of .NET classes that derive from `Cmdlet` and `PSCmdlet` and run in the PowerShell runtime. As stated plain as day in the Microsoft cmdlet documentation: "Cmdlets are instances of .NET Framework classes; they are not stand-alone executables." Your entire comment is an attempt to obfuscate the nature of PowerShell cmdlets, which are actually very simple. >> Piping objects between cmdlets in PowerShell is analogous to working with objects in Python, Ruby, Perl, etc, not like Unix pipes. > No it is not. Yes it is. This is not about the term 'pipeline,' it's about how PowerShell, Unix shells and pipes, and language runtimes work and the scope to which they apply. FACT: PowerShell's object pipeline is internal to the PowerShell / .NET runtime, just as other language features of Python, Ruby, etc are internal to those languages' runtimes. FACT: Unix pipes are primarily for chaining separate processes. They are a lower-level feature than the runtimes of Python, Ruby, or PowerShell, and can be used to chain those runtimes together with each other and other processes. Here's an illustration of the scope of each one. PowerShell's cmdlet / object pipeline: (PowerShell runtime) Unix Pipeline: (Python runtime) | (arbitrary executable) | (PowerShell runtime) | (Ruby runtime)

useerup 11y ago
You look at the developer documentation for developing PowerShell cmdlets using C#, and go "look! it says you create cmdlets using C#!". Well, here is another way to create cmdlets: https://msdn.microsoft.com/en-us/library/jj542520(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/jj542520(v=vs.85).a... Yes, you specify cmdlets using XML. You can point to static methods, remote CIM objects. It may very well use .NET classes underneath. The implementation details are immaterial to how PowerShell works. PowerShell is certainly built using .NET - and require that commands are built (or at least execute) under .NET. However, PowerShell works with objects. An object is a collection of properties and methods that work on the object. Every command in PowerShell must be able to understand the objects, hence a common binary object format must be specified. PowerShell choses .NET objects as it's lingua franca - the PowerShell type system, although it extends it. PowerShell specification says that commands that specifies parameters must do so with types from that type system, and if they support pipelines they must consume objects from the type system and produce objects from the type system. It is a protocol This is very much like how sh shells specifies that commands must support arguments as an array of strings and can optionally consume byte streams from stdin and produce byte streams to stdout. It's a protocol Does PowerShell use the same protocol as sh shells? No. Hence, the commands are different. You do not like that they are different? fine. Don't use it. Your pipeline illustration should have been: PowerShell's cmdlet / object pipeline: (PowerShell runtime | adapter(arbitraty old-school stdin/stdout) | ironpython runtime | any runtime that adheres to type system) Unix Pipeline: (Python runtime) | (arbitrary executable) | (PowerShell runtime) | (Ruby runtime) Yes, PowerShell raises the bar for commands: They must meet some other criteria than string args and stdin/stdout. But just like sh shells and stdin/stdout executables, PowerShell and cmdlets build an ecosystem. It may hurt to realize that the world one knows is just one possible world, and that there may be others out there where some things may be easier and other harder. To me, it is an opportunity to learn. Nothing quite like being shaken up a little.
- integraton 11y ago
  What still seems to be getting missed is that despite some superficial similarities, Unix pipelines and PowerShell pipelines serve different purposes, operate on different levels, function totally differently, and are not interchangeable within the system. Unix pipelines are an operating system feature that coordinates data streams between processes. PowerShell's object pipeline is function chaining feature of PowerShell, a runtime that runs on an operating system as a process, the kind of process whose communication with other processes is coordinated on Unix systems using Unix pipelines. Python, PowerShell, and Ruby object handling and function/method chaining are not a features at the operating system level, they are features within the Python, PowerShell, and Ruby runtimes and processes. Unix pipelines are a feature at the operating system level that coordinate communication between these kinds of processes. Unix pipelines are not a feature of Unix shells, they are an operating system feature for which shells provide an interface. PowerShell's object pipelines are features of PowerShell and its runtime, not the host operating system. This is not a minor distinction. A feature for working with objects and chained functions within particular language or framework's runtime is not the same thing as a feature for coordinating process communication in an operating system.

useerup 11y ago

You look at the developer documentation for developing PowerShell cmdlets using C#, and go "look! it says you create cmdlets using C#!". Well, here is another way to create cmdlets: https://msdn.microsoft.com/en-us/library/jj542520(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/jj542520(v=vs.85).a... Yes, you specify cmdlets using XML. You can point to static methods, remote CIM objects. It may very well use .NET classes underneath. The implementation details are immaterial to how PowerShell works. PowerShell is certainly built using .NET - and require that commands are built (or at least execute) under .NET. However, PowerShell works with objects. An object is a collection of properties and methods that work on the object. Every command in PowerShell must be able to understand the objects, hence a common binary object format must be specified. PowerShell choses .NET objects as it's lingua franca - the PowerShell type system, although it extends it. PowerShell specification says that commands that specifies parameters must do so with types from that type system, and if they support pipelines they must consume objects from the type system and produce objects from the type system. It is a protocol This is very much like how sh shells specifies that commands must support arguments as an array of strings and can optionally consume byte streams from stdin and produce byte streams to stdout. It's a protocol Does PowerShell use the same protocol as sh shells? No. Hence, the commands are different. You do not like that they are different? fine. Don't use it. Your pipeline illustration should have been: PowerShell's cmdlet / object pipeline: (PowerShell runtime | adapter(arbitraty old-school stdin/stdout) | ironpython runtime | any runtime that adheres to type system) Unix Pipeline: (Python runtime) | (arbitrary executable) | (PowerShell runtime) | (Ruby runtime) Yes, PowerShell raises the bar for commands: They must meet some other criteria than string args and stdin/stdout. But just like sh shells and stdin/stdout executables, PowerShell and cmdlets build an ecosystem. It may hurt to realize that the world one knows is just one possible world, and that there may be others out there where some things may be easier and other harder. To me, it is an opportunity to learn. Nothing quite like being shaken up a little.

integraton 11y ago
What still seems to be getting missed is that despite some superficial similarities, Unix pipelines and PowerShell pipelines serve different purposes, operate on different levels, function totally differently, and are not interchangeable within the system. Unix pipelines are an operating system feature that coordinates data streams between processes. PowerShell's object pipeline is function chaining feature of PowerShell, a runtime that runs on an operating system as a process, the kind of process whose communication with other processes is coordinated on Unix systems using Unix pipelines. Python, PowerShell, and Ruby object handling and function/method chaining are not a features at the operating system level, they are features within the Python, PowerShell, and Ruby runtimes and processes. Unix pipelines are a feature at the operating system level that coordinate communication between these kinds of processes. Unix pipelines are not a feature of Unix shells, they are an operating system feature for which shells provide an interface. PowerShell's object pipelines are features of PowerShell and its runtime, not the host operating system. This is not a minor distinction. A feature for working with objects and chained functions within particular language or framework's runtime is not the same thing as a feature for coordinating process communication in an operating system.