Bringing Bash's powerful command line editing to Microsoft Windows' cmd.exe (opens in new tab)

I'm not a fan of powershell but I have to use it in my line of work.

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!

I do only easy things with Powershell and I found it much nicer than classical shells. It's more consistent in the command names and parameter passing. You also need to learn far fewer commands, because Powershell follows the Unix philosophy of small tools that do one thing well much more than Bash+Unix tools. For example if you do "ls" then you get a table where one of the columns is LastWriteTime. Want to sort by that column? "ls | sort lastwritetime". This works without hassle because ls returns a list of objects, and sort sorts a list of objects by a given property, instead of serializing everything to text that would need to be parsed first. I'm sure that Unixes' ls has an option built in to ls to sort by that column, but off the top of my head I have no idea what it is, and many commands that output lists of things do not have that option.

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

> it means the output of one command goes to the input of another command as "objects".

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.

May I ask why?

Not sure why I'm getting hate for this. If you want to write a client for MSOffice365 you have to be on a Windows machine... and its a web-based "cloud" service. Makes no sense if you ask me.

Are you sure it's kept up to date?

The initial github commit has comment "Initial import of the code I developed back in 2006. Nothing has been changed since then.", and nothing has been changed since that commit (with exception of docs, Gow.nsi and gow.vbs files).

Thanks. I used to use GNUWin32 (http://gnuwin32.sourceforge.net/), but this seems like a good alternative.

Which is nice, because you get fine grained control over which bandaids you put over cmd.exe. This basically gives you readline and not much else, and you don't have to install multiple possibly overlapping bandaids to get it.

Console2 looks releases 1-2 releases per yer. Looks quite stable while not active as some other projects. Check dates here: http://sourceforge.net/projects/console/files/console-devel/...

I've never had a single crash (of Console2) on my Win7.

yea, i've been using Console2 for the last year and absolutely love it.

It doesn't make any difference. It required 3.5 as win7 shipped with that framework. You may actually have 3.5 installed already. Check for the following dir: c:\windows\Microsoft.net\framework\v3.5

If it's there you have it already.

Not yet - will fire up my vm later. Thanks for the tip!

on my PC it is instantaneous, it is a matter of hardware.

I have the same problem.

Almost nothing, except in-memory processing, requires 64-bit for dealing with files over 2GB. Piping with utilities is the Unix way, and it works well with files of any size in Cygwin.

Cygwin commands that run slower than Windows counterparts are typically those that are syscall heavy, where those syscalls are significantly different on Windows and need lots of work for emulation. The biggie is fork(); it's better by far to write scripts etc. in such a way that they stream results rather than iterate and create new processes.

So, for example, rather than write a script that converts Unix paths to Windows paths with iterated calls to cygpath -w, instead pipe the paths to cygpath -w -f -. Rather than use pipe-to-sed (like "$(echo $foo | sed 's|bar|baz|')") for ad-hoc edits, try to use shell substitutions instead (like "${foo/bar/baz}").

Another thing that can be slower in Cygwin is find, when run over very large directory trees. I wrote a wrapper script (I call it rdir) that runs "cmd.exe /c dir /b" and massages the output into a Cygwin-style format. I also have the same script written in terms of find, so that my scripts that use it work on Windows, Solaris, Linux and OS X.

But I have to say, the biggest limiting factor in me solving ad-hoc problems is composing the tools available, rather than the actual runtime speed of the tools themselves. Having all the Unix tools available makes my life far easier in this respect. They could be even slower, and I wouldn't mind, because I would still be saving lots of time compared to what Windows provides; and my scripts usually also work on all my other systems running different OSes.

PowerShell doesn't even support simple fork-join like bash does trivially:

    for x in {1..10}; do (sleep $x; echo $x) & done; wait

I use this idiom a lot when dealing with lots of multi-gigabyte files. PowerShell is mostly useful to me when I need to access Windows-specific stuff that Cygwin doesn't do well, like WMI.

I'm with you there -- I find Cygwin starts slow and unstable, and then seems to rot at an astonishing speed, to the point where it's usually unusable after I've had it installed for a couple of months.

When I sometimes have to work in Windows (which really makes no sense at those companies since the products I build 99% of the time run on Linux); Cygwin makes Windows usable.

You can run cygwin shell from FAR, or any other shell. Seriously.

Think of Far Manager as Midnight Commander, more or less.