PowerShell vs. Unix shells(stackoverflow.com)
stackoverflow.com
PowerShell vs. Unix shells
http://stackoverflow.com/questions/573623/powershell-vs-unix-shells
15 comments
> 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.
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.
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.
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.
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="[email protected]"}
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).
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="[email protected]"}
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).
me@my_server$ useradd -G director glenjohn
glenjohn@my_server$ vi .forward
:a
[email protected]
:wq
And there are at least a few other ways to do that. But you certainly don't have to be an admin to specify an alternate email address.
glenjohn@my_server$ vi .forward
:a
[email protected]
:wq
And there are at least a few other ways to do that. But you certainly don't have to be an admin to specify an alternate email address.
Have you used PowerShell ISE 3.0? Its user experience is better than the standard tools on *nix that I've used, and of course much better than the old powershell. You get very good autocompletion (similar to what you get in IDEs like Eclipse or Visual Studio), syntax highlighting, debugger, etc.
But you can't use things like git from ISE because it doesn't support interactive console apps...
As I understand it, a lot of Microsoft's certification training materials and tests are Powershell oriented... instead of clicking around in GUIs they teach you how to make the changes via Powershell commands. (I'm not an MS admin but I've heard this second hand so my apologies if it's not completely accurate)
One big problem with powershell is that it is not installed on all windows machines by default (I think it is only on some server versions). So you can't just whip up a script and have it run on any machine like you can with bash, which is a first class citizen.
I think it comes as standard on Windows 7, I'd be very surprised if it isn't in Windows 8.
Please, "like you can with the Bourne shell". Scripts that assume you have bash make baby Jesus cry.
Only if baby Jesus is using an open source BSD. Bash is standard on all Linux and OS X installs, and vastly more featureful than the POSIX sh standard. If you're a decent bash hacker and really in a situation where you can't rely on a better scripting runtime to be installed, you'd have to think really hard about whether FreeBSD/OpenBSD is worth the hassle.
Honestly, the BSDs need to get their act together on this and either bash-ify their shells or just use it. Their existing environment is pretty poor.
(I guess an argument could be made that Android is another non-bash environment. But the shell there is so terrible that I literally don't know anyone that's used it for anything in production.)
(Edit: I guess technically I should include Solaris people in the list of bashless victims. But, well, yeah...)
Honestly, the BSDs need to get their act together on this and either bash-ify their shells or just use it. Their existing environment is pretty poor.
(I guess an argument could be made that Android is another non-bash environment. But the shell there is so terrible that I literally don't know anyone that's used it for anything in production.)
(Edit: I guess technically I should include Solaris people in the list of bashless victims. But, well, yeah...)
Possibly they could make zsh the default interactive shell, bash is GPL. If you need a better scripting runtime python is probably a better bet.
It depends on what you're scripting, some things really are expressed best in the shell.
But tools like perl, python and ruby aren't nearly as universal as you'd like them to be. Obviously if you maintain the box and are deploying an app, they're trivially available. But if you're shipping software to be installed on end user boxes of unknown configuration, they're a dependency that can bite you. That's why things like self-extracting archives and shell-based initscripts persist, even though they look ugly to modern eyes. They do what they need to do very well, and they do it universally.
But tools like perl, python and ruby aren't nearly as universal as you'd like them to be. Obviously if you maintain the box and are deploying an app, they're trivially available. But if you're shipping software to be installed on end user boxes of unknown configuration, they're a dependency that can bite you. That's why things like self-extracting archives and shell-based initscripts persist, even though they look ugly to modern eyes. They do what they need to do very well, and they do it universally.
Depends on your target. Bash is the LSB shell. If your scripts are only targeting Linux, then you should be able to safely assume bash is there. On Linux, by default, there isn't even a real Bourne shell anyway; it's a symlink to bash.
If you're writing cross-platform then yes, sh would be a better target, but a lot of environments are going to be Linux only.
If you're writing cross-platform then yes, sh would be a better target, but a lot of environments are going to be Linux only.
"On Linux, by default, there isn't even a real Bourne shell anyway; it's a symlink to bash."
For a lot of Linux users (Debian/Ubuntu) /bin/sh is a symlink to dash.
For a lot of Linux users (Debian/Ubuntu) /bin/sh is a symlink to dash.
Doesn't Ubuntu use dash by now?
Fair enough. Still, I haven't seen a desktop linux that didn't have bash in a while.
I personally wished Powershell came preinstalled with Windows. Windows' native terminal is really horrible (try running a FOR loop!).
> 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.
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.
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.
[deleted](1)
> 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 ;-)
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 ;-)
> 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-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.
Seems like you need to ask "Google" about these things ;-) 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.
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)
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
I know Android is Linux based, and, for background, I'm an experienced Linux user/developer, but have never checked out Android as a Linux till now, though I've heard that phones can be rooted. So my q is: what all can you do with bash on Android - as compared to bash on a desktop or server Linux? Interested to know because I have an Android phone. Do you get all or some of the Linux command-line commands like awk, sed, etc.? Do command pipelines work? Thanks for any info you can give.
The base install is very minimal, but you can install a functional environment:
https://play.google.com/store/apps/details?id=com.zpwebsites...
I wouldn't like to run Eclipse on it, but I guess Emacs would run with ease.
https://play.google.com/store/apps/details?id=com.zpwebsites...
I wouldn't like to run Eclipse on it, but I guess Emacs would run with ease.
Thanks for the reply.
> 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.
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.
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.
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.
the famous McIlroy vs Knuth story
http://www.leancrew.com/all-this/2011/12/more-shell-less-egg... here it goes
PowerShell compared to Cygwin bash, in my experience:
* Powershell is more capable than bash, straight up.
* bash is easier to use; writing ad-hoc pipes etc. in PowerShell has never seemed pleasant to me, the commands are verbose and the contractions non-obvious; getting help is tedious, and options are often very long.
* Object orientation works well when you're dealing with meaningful objects. But often you just want to deal with a singular list of items, and it can make things more awkward. It's a bit like the OO - relational dichotomy.
* Interaction between PowerShell and Unix utilities is very clunky, because by default PowerShell will include column headers and formatting characters as part of the output. Something else that's unpleasant: PowerShell doesn't have a simple mode that can work well inside a terminal. I mean, just running PowerShell inside Cygwin mintty results in a copyright notice and an apparantly hung program. That's because it's using ReadConsole rather than ReadFile for I/O, but ReadConsole only works in Windows' horrible console windows. You can work around it with 'powershell -', but then you don't get a prompt. Similarly, running a PowerShell script requires echoing a return character to the PowerShell process to get it to exit! Literally: "echo | powershell -file <script file>". It's a bit ridiculous.
* Deeper Windowsy things like WMI or COM automation work infinitely better with PowerShell. In practice, the only time I use PowerShell is when I need access to something in this area; and then I'll take some arguments, do the PowerShell work, then output the results as text so I can do the main work in bash.
Powershell doesn't really feel like a shell to me. It's more like a SQL query command line and scripting language REPL hybrid. For example, something as basic as job control is almost non-existent. Forget about carefree application of '&' and 'wait'; that style of working, doesn't.
* Powershell is more capable than bash, straight up.
* bash is easier to use; writing ad-hoc pipes etc. in PowerShell has never seemed pleasant to me, the commands are verbose and the contractions non-obvious; getting help is tedious, and options are often very long.
* Object orientation works well when you're dealing with meaningful objects. But often you just want to deal with a singular list of items, and it can make things more awkward. It's a bit like the OO - relational dichotomy.
* Interaction between PowerShell and Unix utilities is very clunky, because by default PowerShell will include column headers and formatting characters as part of the output. Something else that's unpleasant: PowerShell doesn't have a simple mode that can work well inside a terminal. I mean, just running PowerShell inside Cygwin mintty results in a copyright notice and an apparantly hung program. That's because it's using ReadConsole rather than ReadFile for I/O, but ReadConsole only works in Windows' horrible console windows. You can work around it with 'powershell -', but then you don't get a prompt. Similarly, running a PowerShell script requires echoing a return character to the PowerShell process to get it to exit! Literally: "echo | powershell -file <script file>". It's a bit ridiculous.
* Deeper Windowsy things like WMI or COM automation work infinitely better with PowerShell. In practice, the only time I use PowerShell is when I need access to something in this area; and then I'll take some arguments, do the PowerShell work, then output the results as text so I can do the main work in bash.
Powershell doesn't really feel like a shell to me. It's more like a SQL query command line and scripting language REPL hybrid. For example, something as basic as job control is almost non-existent. Forget about carefree application of '&' and 'wait'; that style of working, doesn't.
> getting help is tedious, and options are often very long.
This is what bothered me the most when I last worked on MS systems (maybe 7 years ago now). As much as people complain about manpages, having a quick reference, with some verbosity, right at hand is immensely helpful. Maybe not knowing my way around the MS ecosystem handicapped me, but it was always so much more difficult to find a useful quick reference for what I needed in windows.
This is what bothered me the most when I last worked on MS systems (maybe 7 years ago now). As much as people complain about manpages, having a quick reference, with some verbosity, right at hand is immensely helpful. Maybe not knowing my way around the MS ecosystem handicapped me, but it was always so much more difficult to find a useful quick reference for what I needed in windows.
Get-Help has proven useful at times for me, though sometimes not as detailed as I'd like (even with -full).
I think this is basically right. PowerShell is what you'd get if you started writing "the perfect shell" from scratch. But comparing to bash in isolation is sort of missing the point. Everything in unix is designed to work in the shell, and that's not true in windows.
So you have tools like ssh and nc and curl at hand, designed to feed each other via pipes and do one thing well. Want to push a file to a server behind a VPN when all I have is ssh access to a host on the network? Trivial. On windows? No clue. It's not a shell problem.
So you have tools like ssh and nc and curl at hand, designed to feed each other via pipes and do one thing well. Want to push a file to a server behind a VPN when all I have is ssh access to a host on the network? Trivial. On windows? No clue. It's not a shell problem.
Copying files is an excellent issue: at some point I suggested either on the PowerShell blog or their feedback site that PowerShell should have the ability to copy files via remoting (essentially what you mention, you can remote into a box via powershell and need to copy a file from your local machine onto the remote box).
The response I got from someone at MS was quite telling, it went something like "please tell me more why you would ever want to do this, when we have existing folder sharing technology in windows". I gave up, if they seriously don't understand why that is NOT the answer to situation, gee...
The response I got from someone at MS was quite telling, it went something like "please tell me more why you would ever want to do this, when we have existing folder sharing technology in windows". I gave up, if they seriously don't understand why that is NOT the answer to situation, gee...
Powershell creator's deep UNIX background is evident in its design - they have actually fixed many important problems with most UNIX shells. Some of which are:
- Moving from a text stream manipulation to structure content. No more worrying if separators need to be escaped within the content each time.
- More powerful programming constructs like: Lambda functions, parallel assignments
- Signed scripts
Even though it might not be superior to other shells in every aspect, Powershell's tighter OS integration and OOP approach makes it one of the best shell available on the Windows platform.
- Moving from a text stream manipulation to structure content. No more worrying if separators need to be escaped within the content each time.
- More powerful programming constructs like: Lambda functions, parallel assignments
- Signed scripts
Even though it might not be superior to other shells in every aspect, Powershell's tighter OS integration and OOP approach makes it one of the best shell available on the Windows platform.
I fail to realize why any of these features were "important problems" of Unix shells. Passing byte streams between programs is a very powerful idea and transfers the responsibility of interpreting what the input is to the program parsing it. I realize, from a programmatic point of view, that being able to get a series of objects and to invoke a specific method on them is an intriguing idea, but it breaks the simplicity of the Unix approach of each utility doing one thing and doing it well.
The tight integration into the OS is another weakness - I can grab my Linux scripts and run them on OSX, BSD, AIX, Solaris and pretty much every Unix-like OS around. Your PowerShell scripts will never run on anything other than Windows.
The tight integration into the OS is another weakness - I can grab my Linux scripts and run them on OSX, BSD, AIX, Solaris and pretty much every Unix-like OS around. Your PowerShell scripts will never run on anything other than Windows.
a) I fail to realize why any of these features were "important problems" of Unix shells.
b) Passing byte streams between programs is a very powerful idea and transfers the responsibility of interpreting what the input is to the program parsing it.
b) is an important problem. It means that there are zillions of implementations of various parsers. That inefficiency costs money. Worse, not all of them are without bugs. For an example consider the problem of searching by file name in a script. I guesstimate that a large proportion of Linux installations has a buggy version of it somewhere. Doing it reliably (file names can have spaces, may contain control characters or slashes) involves, IIRC, setting $IFS.
b) Passing byte streams between programs is a very powerful idea and transfers the responsibility of interpreting what the input is to the program parsing it.
b) is an important problem. It means that there are zillions of implementations of various parsers. That inefficiency costs money. Worse, not all of them are without bugs. For an example consider the problem of searching by file name in a script. I guesstimate that a large proportion of Linux installations has a buggy version of it somewhere. Doing it reliably (file names can have spaces, may contain control characters or slashes) involves, IIRC, setting $IFS.
> It means that there are zillions of implementations of various parsers. That inefficiency costs money.
Most of them (if you are referring to command-line utilities) are open-source. I see this variety of implementations as a good thing - evolution relies on diversity and the openness makes it possible for software to "reproduce sexually", making evolution easier.
Most of them (if you are referring to command-line utilities) are open-source. I see this variety of implementations as a good thing - evolution relies on diversity and the openness makes it possible for software to "reproduce sexually", making evolution easier.
And yet, after 40+ years, the (AFAIK) best this evolution has produced is http://en.wikipedia.org/wiki/Xargs, which, if I follow http://stackoverflow.com/questions/896808/find-exec-cmd-vs-x..., still lacks an all-important -- argument. Or maybe we should follow http://stackoverflow.com/questions/7039130/bash-iterate-over...?
I think the Unix world needs something that stands to the combination of find and xargs as ack (http://betterthangrep.com/) stands to grep.
I think the Unix world needs something that stands to the combination of find and xargs as ack (http://betterthangrep.com/) stands to grep.
"closed as not constructive by Bobby, Kev♦ 20 mins ago"
This despite 111 upvotes on the question, 249 upvotes on the accepted answer, and 43 upvotes on the HN link (0 mins ago).
----
Dear Stack Overflow Moderators,
Seriously, what is it that you find to be so objectionable about interesting topics?
Love, bunderbunder
This despite 111 upvotes on the question, 249 upvotes on the accepted answer, and 43 upvotes on the HN link (0 mins ago).
----
Dear Stack Overflow Moderators,
Seriously, what is it that you find to be so objectionable about interesting topics?
Love, bunderbunder
There is no plausible objective answer to this question, thus its not for StackOverflow.
If you want to just talk about interesting topics, use a forum (so says the SO masters).
If you want to just talk about interesting topics, use a forum (so says the SO masters).
"There is no plausible objective answer to this question, thus its not for StackOverflow."
The first half of that sentence is absolutely true. But judging by the enormous number of upvotes, StackOverflow itself (i.e., the people who make it up) disagrees about that second bit.
I fall on the side of Stack Overflow at large. Programming is, among other things, an art. Like in any art, there are sometimes situations where there is no objective answer, and the artisan needs to make a judgment call. And in those cases, a wise artisan may still wish to consider the opinions and experiences of other skilled artisans before deciding on an approach.
Stack Overflow has an excellent format for facilitating this, since it allows some people to share their opinion or experience, and for others to indicate whether they have a similar opinion or experience by simply upvoting that answer. The only thing in Stack Overflow that doesn't actually fit this use case is the green checkbox, but that can be ignored easily enough.
A forum, on the other hand, is a terrible fit for that use case. Forums are for having a conversation, not for getting a quick pulse of what other people are thinking. They leave no way to contribute other than adding an additional post, and they leave no way to get a quick idea of what everyone else is thinking other than reading every single item in the resulting mountain of posts and manually tabulating it all.
It's just possible that the SO masters have fallen out of touch with the SO community. To the extent that they have done so, they are a detriment to that community.
The first half of that sentence is absolutely true. But judging by the enormous number of upvotes, StackOverflow itself (i.e., the people who make it up) disagrees about that second bit.
I fall on the side of Stack Overflow at large. Programming is, among other things, an art. Like in any art, there are sometimes situations where there is no objective answer, and the artisan needs to make a judgment call. And in those cases, a wise artisan may still wish to consider the opinions and experiences of other skilled artisans before deciding on an approach.
Stack Overflow has an excellent format for facilitating this, since it allows some people to share their opinion or experience, and for others to indicate whether they have a similar opinion or experience by simply upvoting that answer. The only thing in Stack Overflow that doesn't actually fit this use case is the green checkbox, but that can be ignored easily enough.
A forum, on the other hand, is a terrible fit for that use case. Forums are for having a conversation, not for getting a quick pulse of what other people are thinking. They leave no way to contribute other than adding an additional post, and they leave no way to get a quick idea of what everyone else is thinking other than reading every single item in the resulting mountain of posts and manually tabulating it all.
It's just possible that the SO masters have fallen out of touch with the SO community. To the extent that they have done so, they are a detriment to that community.
I don't think that's possible at all. If you'll have a listen to their recent podcast #31 - it explains how they see this.
"Within PowerShell, you can call out to your Unix tools" -- so the answer, to the question "how closely does PowerShell emulate Unix scripting?", is "totally". That seems like a pretty objective and plausible answer to me.
The questioner did not ask which was _better_, but how close one is to the other, and on particular dimensions. If a question like that is too controversial or slippery to answer, then I don't see how S.O. can answer any question about choices among technologies.
I think some moderators just saw Windows vs Unix and reflexively decided a food fight must ensue. And that's just sloppy.
The questioner did not ask which was _better_, but how close one is to the other, and on particular dimensions. If a question like that is too controversial or slippery to answer, then I don't see how S.O. can answer any question about choices among technologies.
I think some moderators just saw Windows vs Unix and reflexively decided a food fight must ensue. And that's just sloppy.
>The first half of that sentence is absolutely true. But judging by the enormous number of upvotes, StackOverflow itself (i.e., the people who make it up) disagrees about that second bit.
That's a very dangerous thing, look at what happened to Reddit once there was an influx of people from Digg and 4chan. In fact it is critical that a site's focus is maintained in spite of people's opinions.
>It's just possible that the SO masters have fallen out of touch with the SO community. To the extent that they have done so, they are a detriment to that community.
Not really, SO is just maintaining their site's USP and doesn't want to generate flamebaity discussions. I appreciate them for it.
That's a very dangerous thing, look at what happened to Reddit once there was an influx of people from Digg and 4chan. In fact it is critical that a site's focus is maintained in spite of people's opinions.
>It's just possible that the SO masters have fallen out of touch with the SO community. To the extent that they have done so, they are a detriment to that community.
Not really, SO is just maintaining their site's USP and doesn't want to generate flamebaity discussions. I appreciate them for it.
Tens of thousands of views and many answers and comments later, most everything that's happened in response to the question has been edifying.
There's simply no evidence there of a flamewar having been averted. The closest thing I've seen to an unreasonable insult that I've noticed in relation to the topic is an unfounded comparison to 4chan.
There's simply no evidence there of a flamewar having been averted. The closest thing I've seen to an unreasonable insult that I've noticed in relation to the topic is an unfounded comparison to 4chan.
The problem is, a lot of smart people are on SO. I ant them to answer my non-objectively answerable, flamy question. I don't want a 16-year old script wiz to talk about differences between PowerShell and Unix Shell. And I want other visitors to be able to vote what they think is the better answer.
The only other forum I know that kinda matches this criteria is HN, which is far from ideal (it doesn't show you the votes, it usually doesn't show up in search, the discussions are active for less than 2 days and if you come here late, you won't be able to participate).
Looks like I want the same thing as StackOverlow, with a few minor differences... So, why not create another StackExchange forum (they already have 600 or so) JUST for these kinds of questions?
P.S: programmers.sta... is almost as bad as SO, regarding these kinds of questions.
The only other forum I know that kinda matches this criteria is HN, which is far from ideal (it doesn't show you the votes, it usually doesn't show up in search, the discussions are active for less than 2 days and if you come here late, you won't be able to participate).
Looks like I want the same thing as StackOverlow, with a few minor differences... So, why not create another StackExchange forum (they already have 600 or so) JUST for these kinds of questions?
P.S: programmers.sta... is almost as bad as SO, regarding these kinds of questions.
They want this sort of problem on http://programmers.stackexchange.com/. It is much more clear cut than what happened to me.
See http://news.ycombinator.com/item?id=4203350 for my quitting stack overflow due to bad moderation.
See http://news.ycombinator.com/item?id=4203350 for my quitting stack overflow due to bad moderation.
>Seriously, what is it that you find to be so objectionable about interesting topics?
The US presidential election is very interesting too, but that doesn't mean that HN or SO is the right place to discuss it(even if some upvote it).
SO is about giving specific answers to specific questions, like 'How to get two DIVs side by side', not discussions that result in flaming.
The US presidential election is very interesting too, but that doesn't mean that HN or SO is the right place to discuss it(even if some upvote it).
SO is about giving specific answers to specific questions, like 'How to get two DIVs side by side', not discussions that result in flaming.
One problem with PowerShell is that it uses too much resources for a shell. I believe it to be superior in some ways to Unix shells, but I was never able to get (psychologically) past the 15 second or more startup time needed on my machine (Windows 7 netbook). Given that languages like Python have less starting times, I am likely to use the command prompt and/or scripting language every time.
I guess server people would not encounter this problem.
I guess server people would not encounter this problem.
Good news: the startup time is largely fixed on PowerShell 3 (Windows 8). Most of that startup time ends up being PowerShell trying to load all of the snapins on your system--and you can have a LOT of them if you're a developer, since there are snapins for IIS, SQL Server, and remote management that come more-or-less out-of-the-box in that scenario. PowerShell 3, rather than actually loading all of these, simply notes what commands they export, and only bothers actually loading the snapins if you actually use them. Up side, PS on Windows 8 takes less time to start up. Down side, commands occasionally pause a second while PowerShell loads whatever snapin happens to have the commands you just tried to use. This ends up being a pretty good trade-off in my daily work, though.
As a .NET application Powershell needs to be JITed before execution starts.
However in most systems I never had more than 5s startup time.
However in most systems I never had more than 5s startup time.
I have had some long start times like the parent. Typically it's pretty short. I do agree, though, that not having that instance start time is a bit psychologically confusing... it's a shell, how could it not start instantly! However, typically if I'm developing I'll just leave one open at all times and it's not an issue.
oh wow, now that you mention it you're right ... PowerShell does take a long time to start up. I tend to leave a powershell window open for pretty much my whole session so I guess it's not a huge deal for me. But yeah, when starting up I definitely notice it.
PowerShell was clearly tailored for system scripting, sysadmin, filesystem manipulations, etc... and it does a very good job at that.
Where I find it lacking is in the manipulation of large (10s of GBs) text files, which is what I do most of the time. If I try to cat a large file to wc -l I have to kill the shell because it starts eating all my memory. Even when the memory is not a problem, it is considerably slower than Cygwin or MinGW. I think that the lines are converted to System.String and cached in memory; if this is the case it might be very hard to solve this without an architectural change.
I haven't found any good equivalent of less or grep, things like head and tail are unnecessarily verbose, etc..
Also, the text input is not nearly as advanced as readline-based shells (no Ctrl-K, Ctrl-Y, Alt-Backspace, history search, decent completion...).
I sincerely hope that someone (MSFT or others) comes up with a better solution. Cygwin/MinGW are a reasonable trade-off but PowerShell proved that a much better integration with the system is possible.
Where I find it lacking is in the manipulation of large (10s of GBs) text files, which is what I do most of the time. If I try to cat a large file to wc -l I have to kill the shell because it starts eating all my memory. Even when the memory is not a problem, it is considerably slower than Cygwin or MinGW. I think that the lines are converted to System.String and cached in memory; if this is the case it might be very hard to solve this without an architectural change.
I haven't found any good equivalent of less or grep, things like head and tail are unnecessarily verbose, etc..
Also, the text input is not nearly as advanced as readline-based shells (no Ctrl-K, Ctrl-Y, Alt-Backspace, history search, decent completion...).
I sincerely hope that someone (MSFT or others) comes up with a better solution. Cygwin/MinGW are a reasonable trade-off but PowerShell proved that a much better integration with the system is possible.
cat is an alias for Get-Content which is notoriously slow. If you do some googling people suggesting using System.IO.StreamReader instead. Have you tried that?
When I say cat I mean cat.exe, the unix utility. My usual workflow is
<exe writing to stdout> | <filtering/manipulation> | <exe reading from stdin>
Wow. I love it when the developer of the tool answered the question. And he gave a superb answer. Make me want to try out PowerShell.
How much can you do with powershell regards system configuration?
For example, could you put a Windows Server with PS behind SSH and login and config everything that way without having to touch the GUI?
For example, could you put a Windows Server with PS behind SSH and login and config everything that way without having to touch the GUI?
Kind of, but you're doing it wrong.
The bash way to remotely administer a server is to SSH into the server, then run your commands there. While that's technically possible with PowerShell in recent versions, it's not how PowerShell is designed to work with remote machines. Instead, your local copy of PowerShell is designed to grab the remote server's management objects, and use those to administer the remote server.
For example, say I quickly want to shut down a service on ten boxes. On a Unix system, I'd use a tool like Fabric/Ansible/whatever to quickly SSH into those ten boxes and run "/etc/init.d/whatever stop" (or equivalent). I guess you could do this all on one line with something like
On PowerShell, in contrast, I'd grab the remote service objects, and pipe them into the Stop-Service cmdlet, locally. For example (written verbosely; there's a shorter way to do this):
Other things work the same way.
But my favorite part is that Windows servers actually vend a lot of their resources as PowerShell mounts. Changing the configuration of Apache on your server farm? Break out Puppet and some templates on Unix, but on Windows, use the IIS snapin to "cd" right into the IIS configurations on those boxes and use your normal cat/echo magic to change the configurations. Need to change registry settings? You can "cd" into the registries, too. Same for SQL Server. And because this is all through PowerShell, doing things like redirecting a SQL Server database name right into an IIS configuration file (e.g., configuring your website on which DB to use) becomes easy--again, across a pile of machines.
So: yes, you can remote in. But that's not how PowerShell is designed to work, and you're losing a lot of the magic if you do things that way.
The bash way to remotely administer a server is to SSH into the server, then run your commands there. While that's technically possible with PowerShell in recent versions, it's not how PowerShell is designed to work with remote machines. Instead, your local copy of PowerShell is designed to grab the remote server's management objects, and use those to administer the remote server.
For example, say I quickly want to shut down a service on ten boxes. On a Unix system, I'd use a tool like Fabric/Ansible/whatever to quickly SSH into those ten boxes and run "/etc/init.d/whatever stop" (or equivalent). I guess you could do this all on one line with something like
echo box1 box2 box3 ... | tr " " "\n" | xargs -L 1 -I BOX ssh BOX /etc/init.d/whatever stop
On PowerShell, in contrast, I'd grab the remote service objects, and pipe them into the Stop-Service cmdlet, locally. For example (written verbosely; there's a shorter way to do this):
@('box1', 'box2' ... ) | ForEach-Object { Get-Service -name "whatever" -computername $_ } | Stop-Service
Other things work the same way.
But my favorite part is that Windows servers actually vend a lot of their resources as PowerShell mounts. Changing the configuration of Apache on your server farm? Break out Puppet and some templates on Unix, but on Windows, use the IIS snapin to "cd" right into the IIS configurations on those boxes and use your normal cat/echo magic to change the configurations. Need to change registry settings? You can "cd" into the registries, too. Same for SQL Server. And because this is all through PowerShell, doing things like redirecting a SQL Server database name right into an IIS configuration file (e.g., configuring your website on which DB to use) becomes easy--again, across a pile of machines.
So: yes, you can remote in. But that's not how PowerShell is designed to work, and you're losing a lot of the magic if you do things that way.
This approach most likely requires that the script runs within the same trusted local network, correct? So, technically you'd still have to "ssh" into at least one box, and run all admin scripts from it.
"It depends."
Generally speaking, your servers will be bound to the same Active Directory domain, so if you're logged in via AD, and AD says you're an admin on the boxes you're trying to hit, you're good. This is called trusted authentication, and is similar to forwarding your SSH agent all over the place.
That opens up what happens if you're not in the domain (say, you're on your home laptop). Many commands take a -Credential parameter, which takes an authentication token available that you create via Get-Credential. If the command you want to use takes -Credential, then you can still avoid actually logging into the remote machine in the way you would for, say, SSH.
If, on the other hand, the command you want doesn't take -Credential, you do either need to use Invoke-Command, or genuinely log onto the remote PowerShell service via New-PSSession/Enter-PSSession, which is an extremely direct analog for SSH.
Generally speaking, your servers will be bound to the same Active Directory domain, so if you're logged in via AD, and AD says you're an admin on the boxes you're trying to hit, you're good. This is called trusted authentication, and is similar to forwarding your SSH agent all over the place.
That opens up what happens if you're not in the domain (say, you're on your home laptop). Many commands take a -Credential parameter, which takes an authentication token available that you create via Get-Credential. If the command you want to use takes -Credential, then you can still avoid actually logging into the remote machine in the way you would for, say, SSH.
If, on the other hand, the command you want doesn't take -Credential, you do either need to use Invoke-Command, or genuinely log onto the remote PowerShell service via New-PSSession/Enter-PSSession, which is an extremely direct analog for SSH.
Would this not mean that to do administrative tasks you need to be using a Windows 7 Pro computer and could not do it from a Windows Home, Mac or Linux box?
You would need to RDC into at least one machine and run the scripts from there, in that scenario--so no worse than where you are now.
Note that Windows 8 removes the distinction between Pro and other editions.
Note that Windows 8 removes the distinction between Pro and other editions.
Yes, this is the preferred approach since Windows 2008 Server Core. Please note that Powershell is only installed by default in Windows 2008 R2 Server Core.
You can then use Powershell remoting capabilites, or log into the server with SSH, like on UNIX systems.
You can then use Powershell remoting capabilites, or log into the server with SSH, like on UNIX systems.
Remoting is a bit hobbled I find. For example I'd love to be able to run vim in a powershell remoting session, but it doesn't seem to work.
That's largely because that's not really how Microsoft envisions you using PowerShell. The Windows way is to run the tool locally, edit the resource remotely (kind of like Emacs' TRAMP mode v. Vim users always sshing into the box). In this way, I kind of view PowerShell's direct remoting (i.e., Enter-PSSession) as a complete misfeature.
Even with the UNIX subsystem installed?
After a few years working on a OSX machine I arrived at a new job and had to work with a windows machine. I had the idea to try Powershell so I could share scripts with my colleagues, as I always done. One year later I am still using it, no one ever had any interested on learning them (but they always ask me to run that "dark magic script that load that excel spreadsheet").
Even if my primary goal was not achieved I am still happy that I learned a few tricks with it.
Even if my primary goal was not achieved I am still happy that I learned a few tricks with it.
I used powershell pretty comfortably for years when managing Windows boxes, it does the job superbly. It's a bit weaker as a general-use scripting language (a la Python/Ruby), but I believe it never promised to be that kind of tool. It's just always tempting to use it as a REPL for when whipping out a throwaway C# project in VS is too much of a hassle. It works as one, I'm just not a huge fan of its syntax.
>"What I think you'll find is that there will be lots of occasions when text-processing won't get you what you want on Windows. At that point, you'll want to pick up PowerShell. NOTE - it is not an all or nothing deal. Within PowerShell, you can call out to your Unix tools (and use their text process or PowerShell's text processing). Also you can call PowerShell from your Unix tools and get text." [Jeffery Snover - Top Answer]
In other words, besides performing many useful tasks, Blub Shell is highly portable. In fact it is so portable, that it may be incorporated into MoreAbstract Shell.
There is of course a bit more to the story. MoreAbstract Shell only runs on OS W, but Blub Shell runs on OS X, L, and U. Furthermore, Blub Shell has an extensive collection of utility features which have been added on over the years, so there is much more plug and play code.
On the other hand, why wouldn't one choose the more abstract shell, if it was available?
In other words, besides performing many useful tasks, Blub Shell is highly portable. In fact it is so portable, that it may be incorporated into MoreAbstract Shell.
There is of course a bit more to the story. MoreAbstract Shell only runs on OS W, but Blub Shell runs on OS X, L, and U. Furthermore, Blub Shell has an extensive collection of utility features which have been added on over the years, so there is much more plug and play code.
On the other hand, why wouldn't one choose the more abstract shell, if it was available?
The fact that not everyone is using fish instead of the ridiculously inflexible, unintuitive and underpowered bash means that the shell mustn't matter that much. I'm just glad I found out about fish.
If you cannot make this decision yourself you shouldn't be in this business.
When writing shell script, try to develop an awareness of how much you use sed, awk, tr, `` and so on to munge the output from one command into the format or value you want for the next. If it's a lot then something like PowerShell (or equiv on Unix) may be what you're after.
I used to do that a lot, but now, I very much try to avoid those for modifying command output - at least for scripts: it can be quite fragile. Usually utilities have options to output exactly what you need instead, or you can get the information another way (another utility, something in /proc, etc).
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.