5 ms·

> ...Powershell. They have command names... Except that PowerShell commands, 'cmdlets', are really just .NET classes that run within PowerShell, like Ruby and

> ...Powershell. They have command names... 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 PowerShell's interface obfuscates its true nature is a huge violation of honest design, a massive violation of what's described in "Design of Everyday Things," leads to false comparisons, and misleads people into thinking it is providing the same functionality as working with executables in POSIX shells when it's actually providing chaining functionality like that in other scripting languages.

ColinDabritz 11y ago
Interesting. You can, of course, work with actual executables in that environment too. Can you highlight some of the areas where it causes different behaviors or other design issues?
redwards510 11y ago
Isn't the purpose of a shell to obfuscate the gritty details of what happens behind the scenes? In Linux, when I execute a binary or a shell script, there is no obvious difference to me. Can you explain why it matters or would be considered bad design?
- javert 11y ago
  > obfuscate I'm certain the user meant "obfuscate" in the sense given in the dictionary. You are using it here in a different sense, like "provide a layer of abstraction so that un-needed details do not have to be considered." It's good to tuck away un-needed complexity behind abstractions. But those abstractions should not obfuscate.
UnoriginalGuy 11y ago
> 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
- integraton 11y ago
  > 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%29.aspx https://msdn.microsoft.com/en-us/library/ms714395%28v=vs.85%...
  - UnoriginalGuy 11y ago
    > 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-Builtins.html 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?
    - jc22 11y ago
      Beyond all that, a PowerShell cmdlet could be implemented as a .net class, a script, or a function with cmdlet style binding, or literally anything else you can write a command processor for. (I worked on the team that developed PowerShell for about 8 years, so don't argue with me, n00b.)
wcummings 11y ago
>it's actually providing chaining functionality like that in other scripting languages How do you feel bash et al are substantively different from "chaining functionality like that in other scripting languages"?
Someone 11y ago
"That PowerShell's interface obfuscates its true nature" It's different from Unix shells, but obfuscates? If so, so do bash, etc, with their built-ins. 'echo' doesn't start a process, either. Also, it would be stupid if PowerShell didn't take advantages of the memory safety guarantees that the .Net Platform gives it.

ColinDabritz 11y ago

Interesting. You can, of course, work with actual executables in that environment too. Can you highlight some of the areas where it causes different behaviors or other design issues?

redwards510 11y ago

Isn't the purpose of a shell to obfuscate the gritty details of what happens behind the scenes? In Linux, when I execute a binary or a shell script, there is no obvious difference to me. Can you explain why it matters or would be considered bad design?

javert 11y ago
> obfuscate I'm certain the user meant "obfuscate" in the sense given in the dictionary. You are using it here in a different sense, like "provide a layer of abstraction so that un-needed details do not have to be considered." It's good to tuck away un-needed complexity behind abstractions. But those abstractions should not obfuscate.

UnoriginalGuy 11y ago

> 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

integraton 11y ago
> 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%29.aspx https://msdn.microsoft.com/en-us/library/ms714395%28v=vs.85%...
- UnoriginalGuy 11y ago
  > 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-Builtins.html 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?
  - jc22 11y ago
    Beyond all that, a PowerShell cmdlet could be implemented as a .net class, a script, or a function with cmdlet style binding, or literally anything else you can write a command processor for. (I worked on the team that developed PowerShell for about 8 years, so don't argue with me, n00b.)

wcummings 11y ago

>it's actually providing chaining functionality like that in other scripting languages How do you feel bash et al are substantively different from "chaining functionality like that in other scripting languages"?

Someone 11y ago

"That PowerShell's interface obfuscates its true nature" It's different from Unix shells, but obfuscates? If so, so do bash, etc, with their built-ins. 'echo' doesn't start a process, either. Also, it would be stupid if PowerShell didn't take advantages of the memory safety guarantees that the .Net Platform gives it.