Live data from Hacker News

PowerShell vs. Unix shells

stackoverflow.com

51–60 of 84 posts

Re: PowerShell vs. Unix shells

#51
post #22
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…

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

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.

Re: PowerShell vs. Unix shells

#52
post #50

Earlier quoted context omitted.

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.

Fair enough. Still, I haven't seen a desktop linux that didn't have bash in a while.

Re: PowerShell vs. Unix shells

#53

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.

I think it comes as standard on Windows 7, I'd be very surprised if it isn't in Windows 8.

Re: PowerShell vs. Unix shells

#54
post #50

Earlier quoted context omitted.

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.

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.

Re: PowerShell vs. Unix shells

#55
post #5

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

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

Get-Help has proven useful at times for me, though sometimes not as detailed as I'd like (even with -full).

Re: PowerShell vs. Unix shells

#56
>"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?

Re: PowerShell vs. Unix shells

#57
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?

When I say cat I mean cat.exe, the unix utility. My usual workflow is

      |  | 
Whenever I run this inside PowerShell, whatever flows through the pipeline seems to be cached in memory, and it is orders of magnitude slower than when I run the same pipeline inside bash.

Re: PowerShell vs. Unix shells

#58
post #36

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…

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

Powershell isn't a wrapper for CMD. It's a separate interface for WMI, COM and .NET.

Re: PowerShell vs. Unix shells

#59
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…

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)

Re: PowerShell vs. Unix shells

#60
post #45

Earlier quoted context omitted.

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

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?
Post reply on HN