3 ms·

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 bytest

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`.

integraton 11y ago
> It's fundamentally different. 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.
- useerup 11y ago
  > That's because the object pipeline is functionally analogous to function chaining within a single runtime like in Python or Ruby No it is not. See my response below.
  - integraton 11y ago
    Yes it is, and stop trying to pretend otherwise. Your long-winded comments about PowerShell's internal language and runtime features are utterly irrelevant since they exist within with PowerShell runtime, just as the features of Ruby, Python, JavaScript, the JVM languages, etc all exist within those runtimes. You also tried to falsely claim that cmdlets are not instances of .NET classes in a previous discussion (https://news.ycombinator.com/item?id=9461682 https://news.ycombinator.com/item?id=9461682) and your comments are perfect examples of how PowerShell advocates use long posts of handwaving, obfuscation, and verifiably false claims to try to pretend PowerShell's functionality is different than it actually is.
    - useerup 11y ago
      > 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.
      - deleted 11y ago
        [deleted]
      - integraton 11y ago
        Your statements about cmdlets are simply false, and you are again trying to handwave past the fact that PowerShell is a .NET CLI and that its object pipeline only exists within its .NET runtime and is analogous to function chaining within a single runtime like in Python or Ruby, not Unix pipelines. From the Microsoft documentation, which I quoted to you in a previous discussion, so you should already know it (which would then indicate you are being deliberately dishonest): "Cmdlets are instances of .NET Framework classes; they are not stand-alone executables." > they can also be implemented through script (i.e. not .NET classes) Your statement here is factually wrong. They are called "advanced functions," previously "script cmdlets," mimic the behavior of true cmdlets ("bind as cmdlets"), but are not true cmdlets. They also exist within the .NET runtime, which is the relevant issue. > through manifests where cmdlets are generated for WMI/CIM classes. Then those generated cmdlets must be instances of .NET classes, because by definition that's what cmdlets are, and they exist within the .NET runtime, which is the relevant issue. And in all cases, they exist within the PowerShell/.NET runtime and are not arbitrary executables written in arbitrary languages. 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.

integraton 11y ago

> It's fundamentally different. 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.

useerup 11y ago
> That's because the object pipeline is functionally analogous to function chaining within a single runtime like in Python or Ruby No it is not. See my response below.
- integraton 11y ago
  Yes it is, and stop trying to pretend otherwise. Your long-winded comments about PowerShell's internal language and runtime features are utterly irrelevant since they exist within with PowerShell runtime, just as the features of Ruby, Python, JavaScript, the JVM languages, etc all exist within those runtimes. You also tried to falsely claim that cmdlets are not instances of .NET classes in a previous discussion (https://news.ycombinator.com/item?id=9461682 https://news.ycombinator.com/item?id=9461682) and your comments are perfect examples of how PowerShell advocates use long posts of handwaving, obfuscation, and verifiably false claims to try to pretend PowerShell's functionality is different than it actually is.
  - useerup 11y ago
    > 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.
    - deleted 11y ago
      [deleted]
    - integraton 11y ago
      Your statements about cmdlets are simply false, and you are again trying to handwave past the fact that PowerShell is a .NET CLI and that its object pipeline only exists within its .NET runtime and is analogous to function chaining within a single runtime like in Python or Ruby, not Unix pipelines. From the Microsoft documentation, which I quoted to you in a previous discussion, so you should already know it (which would then indicate you are being deliberately dishonest): "Cmdlets are instances of .NET Framework classes; they are not stand-alone executables." > they can also be implemented through script (i.e. not .NET classes) Your statement here is factually wrong. They are called "advanced functions," previously "script cmdlets," mimic the behavior of true cmdlets ("bind as cmdlets"), but are not true cmdlets. They also exist within the .NET runtime, which is the relevant issue. > through manifests where cmdlets are generated for WMI/CIM classes. Then those generated cmdlets must be instances of .NET classes, because by definition that's what cmdlets are, and they exist within the .NET runtime, which is the relevant issue. And in all cases, they exist within the PowerShell/.NET runtime and are not arbitrary executables written in arbitrary languages. 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.