5 ms·

> PowerShell never just works. That statement is a bit much. I agree the default execution policy is annoying, but can you blame MS for being a little overzeal

> PowerShell never just works. That statement is a bit much. I agree the default execution policy is annoying, but can you blame MS for being a little overzealous given their history? Some aspects of Powershell are actually pretty nice. Ever want to use a real hashmap in bash for example? Or easy JSON construction/manipulation without hacks like jq? PS has all that.

integraton 11y ago
> Ever want to... That's because Bash is used to tie together separate programs that do the work. PowerShell, on the other hand, is a .NET shell and more equivalent to the shells in Python, Node, Ruby, the JVM, etc, all of which provide ways to work with JSON and many different data structures.
- skrebbel 11y ago
  So?
  - seanp2k2 11y ago
    So it's not unique to Windows and other things have been doing this for much longer on different platforms with more users and now have much larger ecosystems making it easier to do what you want quickly.
  - wtallis 11y ago
    If you want to do advanced stuff in your scripts, you've never been limited on unix systems to just sh or bash, but on Windows you still don't have a good shell for interactive use.
    - Someone1234 11y ago
      PowerShell ISE is pretty nice. I use it as my main shell.
    - SomeStupidPoint 11y ago
      How is it fair to give the example of the Python shell in Unix but not in Windows when it runs in both?
      - wtallis 11y ago
        What? Python isn't the kind of thing you would use as an everyday interactive system shell; it's a scripting language that can incidentally be used interactively but isn't well-suited for that, especially without extras like ipython. And quite aside from that, every unix-like desktop OS comes with Python pre-installed; Windows doesn't.
- bkeroack 11y ago
  That's a false distinction. bash has a (primitive, idiosyncratic) language built-in. So does PS. They also are both designed to glue together independent programs via the pipe abstraction. The difference is that PS has much more modern language constructs and capabilities. The fact that it hooks into the .NET API as well is only a convenience.
  - integraton 11y ago
    > They also are both designed to glue together independent programs via the pipe abstraction PowerShell and its object pipeline are focused on cmdlets which are not arbitrary programs, they are .NET classes, and PowerShell objects are .NET objects. Unix shells like sh and bash are focused on tying together separate programs and only have a very minimal set of built-in commands. The focus of each one is very different, despite PowerShell's syntax. Piping objects between cmdlets in PowerShell is analogous to working with objects in Python, Ruby, Perl, etc, not like Unix pipes.
    - useerup 11y ago
      > PowerShell and its object pipeline are focused on cmdlets which are not arbitrary programs, they are .NET classes, and PowerShell objects are .NET objects. Both correct and horribly wrong. PowerShell is indeed focused on cmdlets (and functions) and it's pipeline concept is focused on objects. It is also correct that cmdlets are not arbitrary programs. However, cmdlets are not .NET classes. It is true that you can implement a cmdlet through a .NET class that derives from the base Cmdlet class. But that is just one way to create a cmdlet that can be recognized by PowerShell. You can build cmdlets using PowerShell itself. There is nothing in the PowerShell specification (http://www.microsoft.com/en-us/download/confirmation.aspx?id=36389 http://www.microsoft.com/en-us/download/confirmation.aspx?id...) that require a cmdlet to be a .NET class. If you use PowerShells (rich) introspection function to enquire about a cmdlet, there is nothing objective to give it away as either .NET class based or advanced function based (advanced functions are cmdlets). Yes, you can see if a module (distribution unit of cmdlets, providers, functions etc) are "binary" or "script". That merely reinforces the argument that cmdlets are not classes. Indeed, PowerShell will now dynamically create a new type of cmdlets based on an Open Management Infrastructure (OMI) implementation. Think managed routers, switches, Linux boxes etc. If they expose a REST service that complies with OMI, PowerShell can query the capabilities and create cmdlets in-session for each individual type of equipment. PowerShell has since v3 been able to create WMI/CIM cmdlets. The point is that your assertion that cmdlets are .NET classes is both factually wrong, and grossly misleading. Saying that PowerShell cmdlets are .NET classes is like saying that Yum packages are just archives. Sure, you can pick one apart and say "look! it's a .NET class". I can pick a Yum package apart and say: "look! it's just an archive with some files in it!". That said, it is true that PowerShell builds upon .NET. It is implemented using .NET and the object model is based on .NET. PowerShell's type system is a superset of .NETs - because an administrators tool needs more ad-hoc typing. We have gotten so used to think that sh shells were developed with pipelines like that (streams stdin/stdout) because the commands are like that. In reality, the commands and the (first) shells were developed in tandem so that the commands would fit the shell and vice versa. What Microsoft is doing with PowerShell is challenge that commands must be "like that". If we make the commands "richer" and allow them to use a higher level protocol (objects) for inter-command communication, an even smarter shell can be built. Yes, it does create some friction with traditional commands. PowerShells solution is to regard those as "cmdlets" that just consume sequences of strings (which are objects) and produce sequences of strings. > Unix shells like sh and bash are focused on tying together separate programs and only have a very minimal set of built-in commands. PowerShell is focused on tying together separate cmdlets and only has a very minimal set of build-on commands. See? (Aside: Actually, PowerShell is more terse than any sh shells: It has 0 (zero) "built-in" commands. What it is has is a module concept with auto-discovery. The seemingly "built-in" are not built in. Those cmdlets comes from modules that are distributed alongside the PowerShell binary, and PowerShell auto-loads them as it will any module that is placed in the correct location. sh shells needs commands like e.g. "cd" that manipulate the environment to be built-in. You could never implement "cd" as an external command. In PowerShell "cd" (alias for the Set-Location cmdlet) is distributed through the Microsoft.PowerShell.Management module) > The focus of each one is very different, despite PowerShell's syntax. 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. A pipeline is exactly that: A temporary communications channel that is set up for the duration of the (compound) command, and through which multiple objects flow. In PowerShell the individual cmdlets - like commands in a sh pipeline - are active a the same time. From the PowerShell spec: "A pipeline is a series of one or more commands each separated by the pipe operator | (U+007C). Each command receives input from its predecessor and writes output to its successor." Re: Python, Ruby, Perl, etc: You can create a pipeline concept for those languages as well. See for instance pypi (https://code.google.com/p/python-pipelines/ https://code.google.com/p/python-pipelines/). But it is like you want to portrait PowerShell pipelines as mere method invocations. They are considerably more.
simplexion 11y ago
I have had so many people tell me how fantastic PowerShell is. Not a single one of them was ever a *nix user. PowerShell is getting better with a tab completion of sorts but it is still a headache to figure out commands without web search. I try to force myself to use PowerShell as often as possible, but continuously find myself going back to a GUI. I have the opposite problem when using Linux.
- ossreality 11y ago
  I hate Windows. I spent 90% of my life in Unix. Powershell is fantastic. I'm not joking. Do you have any actual criticisms?
- aesthetics1 11y ago
  I think this comes from being unfamiliar with it. Want to know what you can do with network adapters? Run Get-Help AD to see every cmdlet containing AD, and narrow your search from there. Get-Help auto-updates itself. See a command, but want to know all of the ins and outs (syntax etc) of using it? Run Get-Help [command]. Use the optional -Examples flag to see several well-explained examples. You can even add -Online to get the technet article to launch in your default web browser. I would think that nix users would feel at home with powershell. Microsoft has made a big push for getting developers to take a second look at Windows. They even set up aliases for common nix commands. Don't type 'dir', just type 'ls' - It works fine.
  - dlitz 11y ago
    > Microsoft has made a big push for getting developers to take a second look at Windows. This presumes that the developers' first look and decision to stay away from Windows was mistaken. It wasn't. I avoid Windows because mistakes were made. If Microsoft continues to assert that I'm the one who made the mistakes, then I'm just going to keep avoiding their stuff. As a developer, I make dependency choices based largely on my confidence in the upstream's judgment. Microsoft has a long track record of making poor technical decisions and then never fixing them. I've also heard enough about their internal culture to understand how difficult this would be to change. Introducing a shell or a package manager well over a decade after it was clear that they needed one doesn't inspire confidence. Not to mention Microsoft's tendency act coercively when they can get away with it, and friendly when they can't. Yes, I'm bitter about this. I still don't plan on taking a second look.

integraton 11y ago

> Ever want to... That's because Bash is used to tie together separate programs that do the work. PowerShell, on the other hand, is a .NET shell and more equivalent to the shells in Python, Node, Ruby, the JVM, etc, all of which provide ways to work with JSON and many different data structures.

skrebbel 11y ago
So?
- seanp2k2 11y ago
  So it's not unique to Windows and other things have been doing this for much longer on different platforms with more users and now have much larger ecosystems making it easier to do what you want quickly.
- wtallis 11y ago
  If you want to do advanced stuff in your scripts, you've never been limited on unix systems to just sh or bash, but on Windows you still don't have a good shell for interactive use.
  - Someone1234 11y ago
    PowerShell ISE is pretty nice. I use it as my main shell.
  - SomeStupidPoint 11y ago
    How is it fair to give the example of the Python shell in Unix but not in Windows when it runs in both?
    - wtallis 11y ago
      What? Python isn't the kind of thing you would use as an everyday interactive system shell; it's a scripting language that can incidentally be used interactively but isn't well-suited for that, especially without extras like ipython. And quite aside from that, every unix-like desktop OS comes with Python pre-installed; Windows doesn't.
bkeroack 11y ago
That's a false distinction. bash has a (primitive, idiosyncratic) language built-in. So does PS. They also are both designed to glue together independent programs via the pipe abstraction. The difference is that PS has much more modern language constructs and capabilities. The fact that it hooks into the .NET API as well is only a convenience.
- integraton 11y ago
  > They also are both designed to glue together independent programs via the pipe abstraction PowerShell and its object pipeline are focused on cmdlets which are not arbitrary programs, they are .NET classes, and PowerShell objects are .NET objects. Unix shells like sh and bash are focused on tying together separate programs and only have a very minimal set of built-in commands. The focus of each one is very different, despite PowerShell's syntax. Piping objects between cmdlets in PowerShell is analogous to working with objects in Python, Ruby, Perl, etc, not like Unix pipes.
  - useerup 11y ago
    > PowerShell and its object pipeline are focused on cmdlets which are not arbitrary programs, they are .NET classes, and PowerShell objects are .NET objects. Both correct and horribly wrong. PowerShell is indeed focused on cmdlets (and functions) and it's pipeline concept is focused on objects. It is also correct that cmdlets are not arbitrary programs. However, cmdlets are not .NET classes. It is true that you can implement a cmdlet through a .NET class that derives from the base Cmdlet class. But that is just one way to create a cmdlet that can be recognized by PowerShell. You can build cmdlets using PowerShell itself. There is nothing in the PowerShell specification (http://www.microsoft.com/en-us/download/confirmation.aspx?id=36389 http://www.microsoft.com/en-us/download/confirmation.aspx?id...) that require a cmdlet to be a .NET class. If you use PowerShells (rich) introspection function to enquire about a cmdlet, there is nothing objective to give it away as either .NET class based or advanced function based (advanced functions are cmdlets). Yes, you can see if a module (distribution unit of cmdlets, providers, functions etc) are "binary" or "script". That merely reinforces the argument that cmdlets are not classes. Indeed, PowerShell will now dynamically create a new type of cmdlets based on an Open Management Infrastructure (OMI) implementation. Think managed routers, switches, Linux boxes etc. If they expose a REST service that complies with OMI, PowerShell can query the capabilities and create cmdlets in-session for each individual type of equipment. PowerShell has since v3 been able to create WMI/CIM cmdlets. The point is that your assertion that cmdlets are .NET classes is both factually wrong, and grossly misleading. Saying that PowerShell cmdlets are .NET classes is like saying that Yum packages are just archives. Sure, you can pick one apart and say "look! it's a .NET class". I can pick a Yum package apart and say: "look! it's just an archive with some files in it!". That said, it is true that PowerShell builds upon .NET. It is implemented using .NET and the object model is based on .NET. PowerShell's type system is a superset of .NETs - because an administrators tool needs more ad-hoc typing. We have gotten so used to think that sh shells were developed with pipelines like that (streams stdin/stdout) because the commands are like that. In reality, the commands and the (first) shells were developed in tandem so that the commands would fit the shell and vice versa. What Microsoft is doing with PowerShell is challenge that commands must be "like that". If we make the commands "richer" and allow them to use a higher level protocol (objects) for inter-command communication, an even smarter shell can be built. Yes, it does create some friction with traditional commands. PowerShells solution is to regard those as "cmdlets" that just consume sequences of strings (which are objects) and produce sequences of strings. > Unix shells like sh and bash are focused on tying together separate programs and only have a very minimal set of built-in commands. PowerShell is focused on tying together separate cmdlets and only has a very minimal set of build-on commands. See? (Aside: Actually, PowerShell is more terse than any sh shells: It has 0 (zero) "built-in" commands. What it is has is a module concept with auto-discovery. The seemingly "built-in" are not built in. Those cmdlets comes from modules that are distributed alongside the PowerShell binary, and PowerShell auto-loads them as it will any module that is placed in the correct location. sh shells needs commands like e.g. "cd" that manipulate the environment to be built-in. You could never implement "cd" as an external command. In PowerShell "cd" (alias for the Set-Location cmdlet) is distributed through the Microsoft.PowerShell.Management module) > The focus of each one is very different, despite PowerShell's syntax. 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. A pipeline is exactly that: A temporary communications channel that is set up for the duration of the (compound) command, and through which multiple objects flow. In PowerShell the individual cmdlets - like commands in a sh pipeline - are active a the same time. From the PowerShell spec: "A pipeline is a series of one or more commands each separated by the pipe operator | (U+007C). Each command receives input from its predecessor and writes output to its successor." Re: Python, Ruby, Perl, etc: You can create a pipeline concept for those languages as well. See for instance pypi (https://code.google.com/p/python-pipelines/ https://code.google.com/p/python-pipelines/). But it is like you want to portrait PowerShell pipelines as mere method invocations. They are considerably more.

simplexion 11y ago

I have had so many people tell me how fantastic PowerShell is. Not a single one of them was ever a *nix user. PowerShell is getting better with a tab completion of sorts but it is still a headache to figure out commands without web search. I try to force myself to use PowerShell as often as possible, but continuously find myself going back to a GUI. I have the opposite problem when using Linux.

ossreality 11y ago
I hate Windows. I spent 90% of my life in Unix. Powershell is fantastic. I'm not joking. Do you have any actual criticisms?
aesthetics1 11y ago
I think this comes from being unfamiliar with it. Want to know what you can do with network adapters? Run Get-Help AD to see every cmdlet containing AD, and narrow your search from there. Get-Help auto-updates itself. See a command, but want to know all of the ins and outs (syntax etc) of using it? Run Get-Help [command]. Use the optional -Examples flag to see several well-explained examples. You can even add -Online to get the technet article to launch in your default web browser. I would think that nix users would feel at home with powershell. Microsoft has made a big push for getting developers to take a second look at Windows. They even set up aliases for common nix commands. Don't type 'dir', just type 'ls' - It works fine.
- dlitz 11y ago
  > Microsoft has made a big push for getting developers to take a second look at Windows. This presumes that the developers' first look and decision to stay away from Windows was mistaken. It wasn't. I avoid Windows because mistakes were made. If Microsoft continues to assert that I'm the one who made the mistakes, then I'm just going to keep avoiding their stuff. As a developer, I make dependency choices based largely on my confidence in the upstream's judgment. Microsoft has a long track record of making poor technical decisions and then never fixing them. I've also heard enough about their internal culture to understand how difficult this would be to change. Introducing a shell or a package manager well over a decade after it was clear that they needed one doesn't inspire confidence. Not to mention Microsoft's tendency act coercively when they can get away with it, and friendly when they can't. Yes, I'm bitter about this. I still don't plan on taking a second look.