I completely agree, Cygwin has real OpenSSH, well you can even run Gnome on Windows if you want; even as your main shell or I was doing that back in 2002 not sure it would work these days. Overall Cygwin can't be beat. If Gow has enough utility for folks who want to use it; that's cool but for me when I'm stuck using Windows for anything, Cygwin rocks.

I run cygwin X so that I can have the tabbed version of urxvt.

I ditched mrxvt long ago because of lack of Unicode support (though I did use it under Cygwin/X).

https://github.com/simonzack/urxvt-tabbed - is this the project you're using?

No, not an external project, just one of the "official" rxvt variants. I use the same one on linux as on cygwin/X.

rxvt-unicode-256color

I use it on cygwin at work because I use it on linux at home, because of the tabs (which are text-based and have nothing to do with whatever desktop environment it's running in), and because the 256 colors make it easier for me to distinguish different code parts in a colored text editing session.

The default terminal in cygwin is OK, but the small number of colors were really bothering me (old eyes).

As for unicode, I've displayed Japanese and other scripts in rxvt-unicode-256color just fine.

Here we go: http://imgur.com/eRea4I2

The right terminal has two tabs open, and it shows unicode displayed in the last command.

This is on linux, it looks the same on cygwin (except it has window borders there).

FYI, the default terminal for Cygwin these days is mintty, which supports 256 colours.

Oh super, thanks. I'll have to try that out.

Wouldn't it be better just to use ConEmu and mintty? I looked at urxvt but the ConEmu+mintty combo had all the features I wanted and was more up-to-date than urxvt.

mintty doesn't have enough colors for my eyes.

I use conemu for my windows command shell. I have tried it to run a cygwin bash shell, but I recall there being some annoyances, don't remember what anymore.

But fundamentally, no, it wouldn't be better to run ConEmu and mintty, because urxvt is exactly what I like. :)

Fair enough if urxvt is exactly what you like. Not sure what you meant by the colour comment though, both urxvt and mintty support 256 colours... http://superuser.com/questions/736873/enable-256-colors-for-...

I tried the above for colors in mintty, nice, thanks.

As for running mintty in conemu, it's still not quite right. If I figure it out, this will be what I recommend to people.

But for me, I like having urxvt the same at home on linux and at work in cygwin. I use urxvt's keyboard management of its tabs a lot.

I disagree. Having gnu utils available from CMD is a God send. Sometimes a batch script is the right tool but you need the capabilities of something from gnu utils. It's much simpler to just invoke the tool than to rewrite the script as a windows flavored bash script you run from Cygwin.

Additionally you'll find a lot of scripting language libraries just wrap gnu utils and invoke commands using a sub shell. Being able to run those scripts/libraries from batch files or other windows processes without dealing with Cygwin is awesome too.

Indeed. Cygwin is fantastic, but one must always remember: once you go there, you can never go back. If you mix native Windows binaries with ones from Cygwin, all kinds of weird things can happen. I mostly work with native Windows binaries from ezwinports nowadays, together with ConEmu, Eclipse and a native Emacs; I can use normal Windows paths and things Just Work. Granted, it's more cumbersome to set this up than just installing Cygwin, but people are working on that (see for instance: MSYS2 at http://msys2.github.io/)

> once you go there, you can never go back. If you mix native Windows binaries with ones from Cygwin, all kinds of weird things can happen.

I used that setup all the time and it worked fine for me. Mixing win32 and Cygwin binaries is the point of Cygwin, as far as I'm concerned.

Then you are a lucky man. Ever tried to work with MsysGit in a Cygwin shell? For starters, there's the CR-LF vs LF problem, which can screw you big time. Then there's the problem that Cygwin handles Windows paths differently from MSYS (C:\foo becomes /cygdrive/c/foo on Cygwin, /c/foo on MSYS, but that's just the obvious difference, filename handling is actually much more subtle). And then there's the stuff which you won't notice until it bites you, like for instance '.cmd' and '.bat' not being treated as executables in Cygwin.

> Then there's the problem that Cygwin handles Windows paths differently from MSYS

I don't use MSYS, but my Cygwin installs are rooted at C:\. Win32 path functions actually accept forward slashes as well as backward slashes as path separators, so often, Win32 programs interpret paths like "/etc/passwd" just fine (with the drive resolving to C:\).

LF-versus-CRLF is an annoyance, but I've always solved it by using wrapper scripts that invoke u2d and d2u to perform the proper translation.

I think I previously my "injob" utility. Thanks to your comment, I got around to putting it on github: https://github.com/dcolascione/injob

> Give mintty a shot: you'll never go back to conhost.

No, give cmder a shot: http://bliker.github.io/cmder/ I've tried mintty and cmder, and cmder was just perfect for me.

I use Mintty because Cygwin's tmux didn't work with ConEmu or Cmder, but Mintty was ok.

FWIW, I took a quick stab at the tmux & ncurses code to try to find a fix, but it was far from obvious. Maximus (ConEmu author) said it had to do with how cygwin flags stdin streams, which just happens to break when ConEmu provides them. (sorry details vague)

Quickly scanning the code, it looks like ConEmu is using hooking to implement the Win32 console API and forward calls to the terminal emulator. That's a good approach, but it needs to be integrated into the Cygwin pty system to really work well in that environment.

How does cmder compare to ConEmu?

https://code.google.com/p/conemu-maximus5/

It appears to be built on ConEmu. From the homepage:

> Think about cmder more as a software package than a separate app. All the magic is happening through Conemu. With enhancements from Clink.

Oh my goodness thank-you! I'm forced to use Windows at work, and this is the first terminal emulator that looks not terrible!

Might take a look at Babun[1] as well. It's a fairly pretty emulator with a built-in cygwin tree, and integrated (default) zsh.

[1] https://github.com/babun/babun

The problem I have with console replacements is most of them break readline. You can't run many interactive programs with them. On the other hand, you can't have full unicode support without a console replacement.

Indeed. People need to stop thinking in terms of building win32 "terminal emulators" (most of which involve god-awful hacks, like scraping hidden conhost windows) and instead emulate the Win32 console API in userspace (just like Windows itself did before Windows 7) and implement the Cygwin pty interface in terms of this library. This way, Cygwin programs think they have a pty and Win32 programs think they have a console, and everything Just Works.

But people would rather just hack up a "terminal emulator" instead of doing things the properly and the hard way.

The issue with Cygwin is that disk IO in particular is incredibly slow. Which makes things like git substantially slower than on Linux or OSX.

The problem isn't with disk IO as much as it's with speed of the stat() syscall. IIRC Cygwin stat() is backed by three different NT syscalls, so it's slow because it requires three transitions to kernel mode, where Linux only needs one. Setting core.fileMode to false makes Git use a Windows optimized version of stat(), so it runs a lot faster.

Unfortunately it's still not quite as fast as on Linux and OS X, but it's about as fast as native/MSYS versions of Git on Windows.

> three transitions to kernel mode,

It's not the number of "transitions to kernel mode" (which is actually really fast), but the cost of performing the UID mapping, especially considering that this effort is frequently wasted when programs don't bother inspecting st_uid and friends. That's why I wish the Linux xstat syscall, the one that let programs ask for just what they need, had gone through: it'd have made other systems more efficient too.

Can't the UID mapping be cached.

MsysGit is still way slower than Git on Linux, at least on larger repositories. Calling stat() on lots of small files is pretty much a worst-case scenario for NTFS.

On Cygwin, I wonder if a SetCurrentDirectoryEx function would be a good idea: https://cygwin.com/ml/cygwin/2012-04/msg00632.html

A very convenient improvement that makes a difference is http://mridgers.github.io/clink/ (readline mostly). Tiny, useful, fresh air.

Oh, wow. I don't run windows anymore, but that's quite an amazing little tool. My work mates who use windows are going to be stoked with this, thanks. Currently they're all use cmder, but some struggle with the impedance mismatch of a GNU/NT system like that. This with native binaries will be an amazing setup!

Yeah, clink author hit the nail on the head. `Minimally Enjoyable Upgrade` I guess.