Live data from Hacker News

PowerShell vs. Unix shells

stackoverflow.com

41–50 of 84 posts

Re: PowerShell vs. Unix shells

#41

"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

>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.

Re: PowerShell vs. Unix shells

#42
post #8

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…

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.

Re: PowerShell vs. Unix shells

#43

Earlier quoted context omitted.

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).

"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 whe…

>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.

Re: PowerShell vs. Unix shells

#44
post #8

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…

> 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.

Re: PowerShell vs. Unix shells

#45
post #20

Earlier quoted context omitted.

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.…

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.

Re: PowerShell vs. Unix shells

#46
post #35
post #34

Earlier quoted context omitted.

> 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 Androi…

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…

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

Re: PowerShell vs. Unix shells

#47
post #8

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…

> 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 "h…

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.

Re: PowerShell vs. Unix shells

#48
post #16

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 m…

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.

Re: PowerShell vs. Unix shells

#49
post #30

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…

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?

Re: PowerShell vs. Unix shells

#50

Earlier quoted context omitted.

> 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 "h…

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.

Please, "like you can with the Bourne shell". Scripts that assume you have bash make baby Jesus cry.
Post reply on HN