For 40 years unix shells and their descendants and derivatives including cmd.exe have used files and text streams as the metaphor for interconnecting processes. Powershell changes that, and it means the output of one command goes to the input of another command as "objects".

This can be powerful, but it is also very disorienting. Which means it can be hard to learn to do even basic things in powershell, things that would take only a pipe or two and a couple unxutls programs in cmd.exe.

In cmd.exe, easy things are easy and hard things can be really hard. In powershell, hard things are hard (as opposed to "really hard") and easy things are hard.

The only thing that I find sucks is that the pipeline is slow as snails. For example, an svnadmin dump piped to a file which takes 8 mins in cmd.exe takes 14 hours in powershell...

Apart from that it's bearable!

This is because CreateProcess in Windows is slow. It's the reason that run make on Cygwin on Windows for not-that-large Makefiles is really, really slow. The same Makefile on UNIX and Windows differ in startup time by a wide margin. It's really painful to type "make ..." and sit there for 30 seconds on a fast machine.

   svnadmin dump d:\repo > repo.dump

Effectively where *NIX shells use a fixed size buffer for pipe operations and operate on streams, PS has to convert it to lines first before writing it out.

That doesn't work when you have approximately 25 bytes per line and a 12Gb file which is where the issue is.

Don't get me wrong, I actually like their approach in developing an OO-shell - but if it hurts performance that much someone has taken that paradigm too far. It's the typical case of someone with a hammer (OO programmer) trying to approach everything like it were nails.

Have you tried to change the way the dump is done?

I assume it's related to PS converting every line into a system.string.

have you tried :

Start-Process '{PATHTOSUBVERSION}\svnadmin' -argumentlist "dump {PATH_TO_REPOSITORY}" -RedirectStandardOutput c:\temp\repodump.dmp -Wait

more examples here : http://www.youtube.com/watch?v=9sn2L0E5jT8

Unfortunately its very verbose for a simple case which works fine in cmd so I'm not sure that it warrants using that tool

You even get autocompletion across commands: if you type "ls | sort _" where _ is the cursor, then you get a list of properties that you can sort objects returned by ls by (LastAccessTime, LastWriteTime, Extension, etc).

Just my experience, but most ms developers have been crippled by their tooling. Powershell is no exception.

"You're weak and have been crippled by your tools."

o_o You're suffering from Stockholm Syndrome. Upgrade your tools and be free from menial labor.

Only if both commands support objects. If one of them doesn't then PowerShell just deals with text. I've sent the output of PowerShell commands to perl scripts and GNU utils without any problems. It just worked. I'm still a powershell newbie, and this has made it easy for me to learn it while still using what I know.

Ever wondered why Microsoft didn't just make a bash-compatible shell? It's not like they couldn't - it's that they don't want. It would make it easier for people to jump ship, after all. And that's something they hope to prevent.

[1]: Yeah, yeah, there's a PS port to Unix land, but no sane human being will seriously use that. It's pretty much just another waste of time to save people from their mistake of investing into a proprietary tool tied to a proprietary environment.

These jumps in "technology" are perhaps forward, but also very much backward. I've seen it time and time again with clients who have bought a new computer and had to deal with growing pains (and hatred) of the blue globe, ribbons, and other 'we changed the gui to make it hard to do what you previously did easily'.

At least in the Linux world, your knowledge isn't decimated on an update. There may be depreciations, but those are rarer than MS "we update the world'.

It's funny that this should come up in a thread about PowerShell, a replacement shell Microsoft released 6 years ago which still hasn't supplanted cmd.exe (which itself is based on syntax from the late 70s).

I'm still using them 22 years later. They still work in most Windows applications and all MS applications even though they're not listed. They could easily have taken them out since Ctrl-C and Ctrl-V have been standard in Windows for so long, but they didn't.

I also got quite comfortable with using F2 and F4 to edit my previous DOS command, which still work in Command Prompt. And since Command Prompt now has tab completion and copy and paste, I don't really feel the need to add a bash-style command history. In fact I can never remember the bash equivalent of some of the cmd history shortcuts I use.

I have, however, installed the GOW package (see bmatzelle on github) for grep, less, wc etc at the command prompt. grep is so much faster than the MS equivalent "find" it's not funny, e.g. I just searched for a 9-digit number across 13 files containing 4 million lines (158MB) and grep took 1 second; find took 57.

[1]: http://www.hanselman.com/blog/SigningPowerShellScripts.aspx

It also isn't a drop in replacement for the command prompt. They exist as two separate programs, instead of the Unix general Terminal and shells run inside.

In my experience, Powershell has a lot of potential but is hampered by clunky interfaces and the lack of a true robust security system across the OS. Add on top of that the large malware industry around Windows, Powershell is basically a non-starter as a replacement for the vanilla command prompt.

"At least in the Linux world, your knowledge isn't decimated on an update."

Of course, so that's why the time I put into learning how LILO worked is now paying off so greatly! Oh no wait it doesn't, because LILO went the way of the dodo (as far as I can tell, I don't use Linux all that often any more). Wait, all that time I used to spend on manually insmod'ing kernel modules to get my audio to work with the various audio systems, that has paid off! Hmm no, that too is a crapshoot that changes every year or so. Config file format? Different between all programs. Desktop integration? Different desktop systems, who each change how they work every 2 or 3 years. Gfx card drivers? Depends on the brand, make and (if you're lucky) distro. Networking setup? Lol, don't get me started.

Of course things like config files change, but unix remains one of the most backwards compatible platforms to build anything on.

What's even more funny is that you use "Unix" instead of "Linux", implying that software written for one Unix would magically work with others (I mean, that would be case if all was backwards compatible, right?). Have you ever written software for more than one Unix, even disregarding historical versions? The most painful concoctions needed to develop for several Unixy OS's (like, say, autotools) exist for the exact reason that they're not compatible at all. While at the same time, I've written code for Win98 almost 15 years ago whose binaries still run, without as much as changing a software setting, on Windows 7 (and probably 8 although I haven't tried) today. (again, there are plenty of things to critisize Windows for, but backward compatibility is not one of them).

"Of course things like config files change"

Yeah, that's like saying "of course a 2012 BMW is different in a few minor ways from a Model T, but essentially they're just machines with engines and wheels." Eh, yeah, sure.