Comment by UnoriginalGuy | Hacker News Reader

Comment by UnoriginalGuy | Hacker News Reader

Parent Full thread

> Except that PowerShell commands, 'cmdlets', are really just .NET classes that run within PowerShell, like Ruby and Python classes, none of which are the same as working with GNU or BSD utilities and other executables in POSIX shells.

That's categorically incorrect and shows a lack of knowledge of both Powershell and .Net classes. But instead of me showing you that you're wrong, let me teach you how to prove to yourself that you're wrong.

Open up Powershell, type in

     ( get-command get-date ).dll

This will find the dll on your system for the get-date cmdlet, but any will do ( C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.PowerShell.Commands.Utility on my box). Now spin up ILSpy or any .Net decompiler.

Let's look at the GetDateCommand class. That's a 400 line class, which according to you, shouldn't exist (as cmdlets are "really just .Net classes"). In fact this entire DLL shouldn't exist.

But GetDateCommand is one of PS's simplest commands since it wraps DateTime (in CorLib), so "wait! See!" you say. But what you need to understand is that Powershell is built on top of .Net, .Net is effectively Powershell cmdlet's "kernel" so just like UNIX commands communicate with the actual kernel, cmdlets are going to leverage functionality in their "kernel" (.Net whenever possible).

My point is, that no, Powershell cmdlets are NOT just .Net classes. However you CAN use .Net classes directly in Powershell. For example:

     [System.DateTime]::Now

> cmdlets are NOT just .Net classes

Yes they are.

The fact that you (and others I've seen here and elsewhere) continue to believe otherwise further demonstrates how deceptive PowerShell's design is.

What's interesting is that the cmdlet documentation is very clear:

"Cmdlets differ from commands in other command-shell environments in the following ways:

"Cmdlets are instances of .NET Framework classes; they are not stand-alone executables....

"Cmdlets do not generally do their own parsing, error presentation, or output formatting. Parsing, error presentation, and output formatting are handled by the Windows PowerShell runtime."

https://msdn.microsoft.com/en-us/library/ms714395%28v=vs.85%...

> Yes they are.

I literally just spoon fed you exactly how to go look for yourself about how cmdlets work and how they're distinct from the .Net classes they represent. I honestly don't know what more I can do.

> The fact that you (and others I've seen here and elsewhere) continue to believe otherwise further demonstrates how deceptive PowerShell's design is.

You realise I understand how Powershell works top to bottom, right? Where are they "deceiving me?" You can yourself can go learn about Powershell's artitecture (you have the tools, I've given them to you, and you clearly have access to the documentation).

> What's interesting is that the cmdlet documentation is very clear:

Wait is your biggest issue that cmdlets are held within DLLs of classes instead of standalone binaries? Because based on the snippets you posted I can only assume that is what your issue is.

Wait, but hold on, how many internal commands do most UNIX shells have? Dozens? Hundreds? Here's a list of them for bash: http://www.gnu.org/software/bash/manual/html_node/Bash-Built...

So why one rule for UNIX and another for Powershell? Why does it matter that you can store multiple commands (cmdlets) inside of a single DLL?

I'm only passingly familiar with PowerShell but really, it's Microsoft, in the bloody documentation, that literally states precisely that cmdlets are instances of .NET Framework classes:

"Cmdlets differ from commands in other command-shell environments in the following ways:

Cmdlets are instances of .NET Framework classes; they are not stand-alone executables.

https://msdn.microsoft.com/en-us/library/ms714395%28v=vs.85%...

We can have an ontological debate about how an instance of an-object-as-a-concept is different from an instance of an-object-as-memory-content but I think that's best left to amateur philosophers.

You're right with the caveat that they can also be powershell scripts.

Anyone arguing that PS isn't really just 'scriptable .Net' is unfamiliar with the more advanced ideas of PS.

PS is different things to different people, but from a pure tech perspective the above is an apt description of PS.

edit:

I should also mention I find the idea of using PS as an example of an easy, intuitive shell to be laughable at best. Anyone who believes that has definitely tried to do much more than simply Get-Item, New-Item, type things. Once you start getting into more advanced things it becomes a hairy mess.

I had trouble parsing this - Could you explain, in a sentence or two, why cmdlets are more than .NET classes? What's the significance of the GetDateCommand class existing?

> What's the significance of the GetDateCommand class existing?

That it is additional code, above and beyond the core .Net classes.

Reply on news.ycombinator.com