PowerShell vs. Unix shells • Hacker News Board

Re: PowerShell vs. Unix shells

#81

Post by yen223 » Sat, Jul 14, 2012, 1:29 AM UTC

dingle_thunk wrote: post #31

babarock wrote: 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…

I personally wished Powershell came preinstalled with Windows. Windows' native terminal is really horrible (try running a FOR loop!).

Re: PowerShell vs. Unix shells

#82

Post by eru » Sat, Jul 14, 2012, 2:54 AM UTC

georgemcbay wrote: post #68

mhurron wrote: post #54

Earlier quoted context omitted.

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.

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

Doesn't Ubuntu use dash by now?

Re: PowerShell vs. Unix shells

#83

Post by Someone » Sat, Jul 14, 2012, 11:45 PM UTC

rbanffy wrote: post #76

Someone wrote: post #63

Earlier quoted context omitted.

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

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

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.

Re: PowerShell vs. Unix shells

#84

Post by gecko » Mon, Jul 16, 2012, 8:00 PM UTC

jiggy2011 wrote: post #60

gecko wrote: post #45

Earlier quoted context omitted.

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

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.