
PowerShell vs. Unix shells - wslh
http://stackoverflow.com/questions/573623/powershell-vs-unix-shells
======
babarock
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 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.

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

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

~~~
hartez
_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="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).

~~~
niels_olson
me@my_server$ useradd -G director glenjohn

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.

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

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

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

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

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

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

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

~~~
Someone
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...](http://stackoverflow.com/questions/896808/find-exec-cmd-vs-xargs),
still lacks an all-important -- argument. Or maybe we should follow
[http://stackoverflow.com/questions/7039130/bash-iterate-
over...](http://stackoverflow.com/questions/7039130/bash-iterate-over-list-of-
files-with-spaces)?

I think the Unix world needs something that stands to the combination of find
and xargs as ack (<http://betterthangrep.com/>) stands to grep.

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

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

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

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

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

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

~~~
pjmlp
As a .NET application Powershell needs to be JITed before execution starts.

However in most systems I never had more than 5s startup time.

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

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

~~~
MatthewPhillips
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?

~~~
ot
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>
    

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.

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

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

~~~
gecko
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

    
    
        echo box1 box2 box3 ... | tr " " "\n" | xargs -L 1 -I BOX ssh BOX /etc/init.d/whatever stop
    

but that's really rare, in my experience, compared to using a tool like
Fabric.

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
    

Note what's going on: I'm passing an array of box names in, grabbing out
handles to the actual services running on the remote box, and then stopping
those, using the _local_ Stop-Service cmdlet.

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.

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

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

~~~
jiggy2011
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?

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

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

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

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

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

------
m0skit0
UNIX shell is not only Bash... Did you guys try fish? I recommend it!

~~~
rbanffy
I didnt like it, but a lot of friends love zsh.

------
halayli
If you cannot make this decision yourself you shouldn't be in this business.

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

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

