PowerShell vs. Unix shells
stackoverflow.com
stackoverflow.com
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.
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.
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 ;-)
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.
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.
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.
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.
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).
glenjohn@my_server$ vi .forward
:a
glenjohn@fabrikam.com
: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.
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.
For a lot of Linux users (Debian/Ubuntu) /bin/sh is a symlink to dash.
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...)
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.
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.
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.
* 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.
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.
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.
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...
- 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.
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.
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.
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.
I think the Unix world needs something that stands to the combination of find and xargs as ack (http://betterthangrep.com/) stands to grep.
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
If you want to just talk about interesting topics, use a forum (so says the SO masters).
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 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.
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.
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 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.
See http://news.ycombinator.com/item?id=4203350 for my quitting stack overflow due to bad moderation.
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.
I guess server people would not encounter this problem.
However in most systems I never had more than 5s startup time.
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.
<exe writing to stdout> | <filtering/manipulation> | <exe reading from stdin>
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?
You can then use Powershell remoting capabilites, or log into the server with SSH, like on UNIX systems.
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.
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.
Note that Windows 8 removes the distinction between Pro and other editions.
Even if my primary goal was not achieved I am still happy that I learned a few tricks with it.
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?