5 ms·

The main difference between the two, in my humble opinion, is that PowerShell is a nice (and powerful) addition to a Windows system, whereas the Shell is a fund

The main difference between the two, in my humble opinion, is that PowerShell is a nice (and powerful) addition to a Windows system, whereas the Shell is a fundamental component of Unix. Of course, the two shells may be equivalent in terms of power or number of features, and any contest a la "Can your shell do this?" would be futile. To me, it's a matter of cultural differences. Think of it this way: a shell operates in two mode, script or interactive (the new fancy word now is REPL). How much time does your average PowerShell user spend in REPL mode? In comparison, a Unix hacker spends all his time in the shell, even for doing the most trivial tasks. As you practice more and more, the shell becomes a favorite way to operate a computer. Even tasks that may seem easier on a point-and-click interface (like selecting a few files from one directory and copying them into a new one) come more natural to me on the command line than with a mouse. The day I discovered that you can run 'for' loops from your interactive shell as naturally as a script, I almost uninstalled X :) My only point is that the shell fits in the overall philosophy. You probably heard of the famous McIlroy vs Knuth story (legend?), where a pipe of a few commands turned out to be more efficient than a Knuth data structure. That's beyond my point. What I want to show is more the ending paragraph of this story, what McIlroy had to say about it: > Very few people can obtain the virtuoso services of Knuth (or afford the equivalent person-weeks of lesser personnel) to attack nonce problems such as Bentley’s from the ground up. But old UNIX hands know instinctively how to solve this one in a jiffy. That last sentence. Unix hands know how to solve these problems because of all the time spent on their command line. Overall I'm glad that Microsoft is developing PowerShell, and I absolutely agree that it is far more adapted to their Windows platform than the old "all-is-text" mentality of bash and the POSIX tools. However, PowerShell is still treated as a second class citizen in the Windows eco-system, and that is, imho, its biggest weakness.

MatthewPhillips 14y ago
> However, PowerShell is still treated as a second class citizen in the Windows eco-system, and that is, imho, its biggest weakness. I don't know about that. Microsoft operates NuGet (the .NET equivalent of NPM or Gems) and the way of downloading packages is through powershell (albeit a specially docked version inside Visual Studio). I agree that it's treated as second class in that most utilities are not designed with it in mind first but I can see that changing over time. They are already excellent Powershell equivalents of Make and Apt/Yum by third parties. Third parties have embraced it pretty strongly.
- deleted 14y ago
  [deleted]
  - MatthewPhillips 14y ago
    If you go to any package on nuget.org, it's the way you're instructed to install. For example: http://nuget.org/packages/Nancy http://nuget.org/packages/Nancy
- recursive 14y ago
  I have never touched power shell during my use of nuget fwiw. I'm not even sure how to if I wanted to. As far as I can tell it's just a graphical user interface. There might be some command line options somewhere but it does not seem like a first class citizen.
rbanffy 14y ago
> You probably heard of the famous McIlroy vs Knuth story (legend?), where a pipe of a few commands turned out to be more efficient than a Knuth data structure. Since very few shell scripts run continuously for long periods of time, it's hard to justify prioritizing runtime efficiency over development time. I remember ActiveState's Perl and the standard Windows version of Python have some API hooks that can be useful for manipulating Windows-only things. Can help leverage Cygwin tools on Windows. Having said that, I always used Cygwin when I had to use Windows. It felt, of course, detached from the rest of the system, but it was a small island of sanity in a sea of APIs, registries and metabases... PowerShell is, indeed, a perfect match for the environment it evolved on. As for the "can you do this" thing, I run bash on Android. Can PowerShell run on Windows Phones ;-)
- wslh 14y ago
  > As for the "can you do this" thing, I run bash on Android. Can PowerShell run on Windows Phones ;-) Seems like you need to ask "Google" about these things ;-) http://stackoverflow.com/questions/8892357/is-there-any-scripting-support-on-windows-phone http://stackoverflow.com/questions/8892357/is-there-any-scri... To be sincere I also prefer to develop in .NET with Visual Studio than in Java. And, if you ask me about the mobile market ($$$) size, I prefer iOS than Android. I see a lot of crap on the Android Market and a lack of high quality applications.
  - rbanffy 14y ago
    It's hard to stand out within the Play app store, but the lack of competitors is actually an opportunity. And while I really hate using Java for web applications, Android is quite nice to develop for, once you get the rules and learn to navigate the boilerplate. I also find the wide selection of devices comforting when compared to the one size fits all idea (even if the one size is the one dictated by Saint Steven of Cupertino himself)
    - wslh 14y ago
      I have a doubt about the opportunities vs risks associated. For example, I am not seeing interactive books like the ones on the iOS platform. I understand that from the developer perspective there are a lot of work but this is because the entrepreneur carries the risk and not the final developer/non-founder
dingle_thunk 14y ago
> PowerShell is still treated as a second class citizen in the Windows eco-system This is so completely wrong it's not funny. The majority of Microsoft's server GUIs are now built completely on PowerShell. This includes basic products like IIS, Exchange, etc. Where I work, most consultants who implement or maintain these products have learned PowerShell and use it regularly. Windows Server 2012's default option is "headless" install (Powershell only), and that's been an option since at least Server 08 R2. Powershell is certainly not an afterthought - it is at the core of Microsoft's server administration GUI plans. MS have completely committed to it.
- tammer 14y ago
  Interesting - babarock is incredibly wrong from the windows perspective, but from the unix perspective entirely correct. (I work in IT and handle things on both sides.) Comparatively, the recent and steadily increasing reliance on PS is evidence of microsoft's recognition of the utility of a shell for managing their more complex software. On the other hand, the fact that PS doesn't have it's own readline yet (it's just a wrapper for the cripplingly ancient CMD) and its incredible lack of basic features (just try managing AD users in PowerShell - sure its easy once you've written your own custom script or mapped it to a web interface or something, but there's no built in equivalent for adduser or about a billion other basic UNIX commands). It all depends on your perspective. I'm glad to see MS moving away from their decade of GUI dependence.
  - rome 14y ago
    Powershell isn't a wrapper for CMD. It's a separate interface for WMI, COM and .NET.
    - zem 14y ago
      he's not talking about the powershell engine, he's talking about the frontend repl you interact with
  - hartez 14y ago
    just try managing AD users in PowerShell - sure its easy once you've written your own custom script or mapped it to a web interface or something, but there's no built in equivalent for adduser or about a billion other basic UNIX commands It's not that bad. Adding a new AD user is a built-in command. From the docs: New-ADUser GlenJohn -OtherAttributes @{title="director";mail="glenjohn@fabrikam.com"} I'm not a UNIX admin; maybe the adduser command is easier. But managing AD stuff in PS is pretty easy (especially if you have to do it in bulk).
Spooky23 14y ago
That's a good point, but Microsoft is slowly working on that. The Exchange guys whom I work with live in PowerShell -- they barely touch the GUI to make changes to things. As the Microsoft Apps get powershell-ized, I think you'll see it become a bigger part of the environment.
actf 14y ago
> To me, it's a matter of cultural differences. Think of it this way: a shell operates in two mode, script or interactive (the new fancy word now is REPL). How much time does your average PowerShell user spend in REPL mode? I realize this is anecdotal, but I spent about 2 years using powershell exclusively, instead of mingw/cygwin, and I during that time I would always keep one or more powershell windows open. I see no reason to believe that anyone with bash, etc experience would not use powershell the same way. Imho it worked well as an interactive shell, its biggest failing was Microsoft's awful console window that hosts powershell. I would be really happy if Microsoft provided something better by default, like Console2 - although that program has it's own set of problems too.
guard-of-terra 14y ago
the famous McIlroy vs Knuth story http://www.leancrew.com/all-this/2011/12/more-shell-less-egg/ http://www.leancrew.com/all-this/2011/12/more-shell-less-egg... here it goes

MatthewPhillips 14y ago

> However, PowerShell is still treated as a second class citizen in the Windows eco-system, and that is, imho, its biggest weakness. I don't know about that. Microsoft operates NuGet (the .NET equivalent of NPM or Gems) and the way of downloading packages is through powershell (albeit a specially docked version inside Visual Studio). I agree that it's treated as second class in that most utilities are not designed with it in mind first but I can see that changing over time. They are already excellent Powershell equivalents of Make and Apt/Yum by third parties. Third parties have embraced it pretty strongly.

deleted 14y ago
[deleted]
- MatthewPhillips 14y ago
  If you go to any package on nuget.org, it's the way you're instructed to install. For example: http://nuget.org/packages/Nancy http://nuget.org/packages/Nancy
recursive 14y ago
I have never touched power shell during my use of nuget fwiw. I'm not even sure how to if I wanted to. As far as I can tell it's just a graphical user interface. There might be some command line options somewhere but it does not seem like a first class citizen.

rbanffy 14y ago

> You probably heard of the famous McIlroy vs Knuth story (legend?), where a pipe of a few commands turned out to be more efficient than a Knuth data structure. Since very few shell scripts run continuously for long periods of time, it's hard to justify prioritizing runtime efficiency over development time. I remember ActiveState's Perl and the standard Windows version of Python have some API hooks that can be useful for manipulating Windows-only things. Can help leverage Cygwin tools on Windows. Having said that, I always used Cygwin when I had to use Windows. It felt, of course, detached from the rest of the system, but it was a small island of sanity in a sea of APIs, registries and metabases... PowerShell is, indeed, a perfect match for the environment it evolved on. As for the "can you do this" thing, I run bash on Android. Can PowerShell run on Windows Phones ;-)

wslh 14y ago
> As for the "can you do this" thing, I run bash on Android. Can PowerShell run on Windows Phones ;-) Seems like you need to ask "Google" about these things ;-) http://stackoverflow.com/questions/8892357/is-there-any-scripting-support-on-windows-phone http://stackoverflow.com/questions/8892357/is-there-any-scri... To be sincere I also prefer to develop in .NET with Visual Studio than in Java. And, if you ask me about the mobile market ($$$) size, I prefer iOS than Android. I see a lot of crap on the Android Market and a lack of high quality applications.
- rbanffy 14y ago
  It's hard to stand out within the Play app store, but the lack of competitors is actually an opportunity. And while I really hate using Java for web applications, Android is quite nice to develop for, once you get the rules and learn to navigate the boilerplate. I also find the wide selection of devices comforting when compared to the one size fits all idea (even if the one size is the one dictated by Saint Steven of Cupertino himself)
  - wslh 14y ago
    I have a doubt about the opportunities vs risks associated. For example, I am not seeing interactive books like the ones on the iOS platform. I understand that from the developer perspective there are a lot of work but this is because the entrepreneur carries the risk and not the final developer/non-founder

dingle_thunk 14y ago

> PowerShell is still treated as a second class citizen in the Windows eco-system This is so completely wrong it's not funny. The majority of Microsoft's server GUIs are now built completely on PowerShell. This includes basic products like IIS, Exchange, etc. Where I work, most consultants who implement or maintain these products have learned PowerShell and use it regularly. Windows Server 2012's default option is "headless" install (Powershell only), and that's been an option since at least Server 08 R2. Powershell is certainly not an afterthought - it is at the core of Microsoft's server administration GUI plans. MS have completely committed to it.

tammer 14y ago
Interesting - babarock is incredibly wrong from the windows perspective, but from the unix perspective entirely correct. (I work in IT and handle things on both sides.) Comparatively, the recent and steadily increasing reliance on PS is evidence of microsoft's recognition of the utility of a shell for managing their more complex software. On the other hand, the fact that PS doesn't have it's own readline yet (it's just a wrapper for the cripplingly ancient CMD) and its incredible lack of basic features (just try managing AD users in PowerShell - sure its easy once you've written your own custom script or mapped it to a web interface or something, but there's no built in equivalent for adduser or about a billion other basic UNIX commands). It all depends on your perspective. I'm glad to see MS moving away from their decade of GUI dependence.
- rome 14y ago
  Powershell isn't a wrapper for CMD. It's a separate interface for WMI, COM and .NET.
  - zem 14y ago
    he's not talking about the powershell engine, he's talking about the frontend repl you interact with
- hartez 14y ago
  just try managing AD users in PowerShell - sure its easy once you've written your own custom script or mapped it to a web interface or something, but there's no built in equivalent for adduser or about a billion other basic UNIX commands It's not that bad. Adding a new AD user is a built-in command. From the docs: New-ADUser GlenJohn -OtherAttributes @{title="director";mail="glenjohn@fabrikam.com"} I'm not a UNIX admin; maybe the adduser command is easier. But managing AD stuff in PS is pretty easy (especially if you have to do it in bulk).

Spooky23 14y ago

That's a good point, but Microsoft is slowly working on that. The Exchange guys whom I work with live in PowerShell -- they barely touch the GUI to make changes to things. As the Microsoft Apps get powershell-ized, I think you'll see it become a bigger part of the environment.

actf 14y ago

> To me, it's a matter of cultural differences. Think of it this way: a shell operates in two mode, script or interactive (the new fancy word now is REPL). How much time does your average PowerShell user spend in REPL mode? I realize this is anecdotal, but I spent about 2 years using powershell exclusively, instead of mingw/cygwin, and I during that time I would always keep one or more powershell windows open. I see no reason to believe that anyone with bash, etc experience would not use powershell the same way. Imho it worked well as an interactive shell, its biggest failing was Microsoft's awful console window that hosts powershell. I would be really happy if Microsoft provided something better by default, like Console2 - although that program has it's own set of problems too.

guard-of-terra 14y ago

the famous McIlroy vs Knuth story http://www.leancrew.com/all-this/2011/12/more-shell-less-egg/ http://www.leancrew.com/all-this/2011/12/more-shell-less-egg... here it goes