My biggest gripe with Cygwin (aside performance on some syscalls) has been package management, which used to require setup.exe to add or upgrade packages. That was nicely mitigated when I found out about apt-cyg[1]. It's a apt-getish frontend for setup.exe command line. Not as nice as real apt-get of course, but "apt-cyg install something" takes care of the most important use case.

1: https://github.com/transcode-open/apt-cyg

EDIT: changed to github url

It would also be really nice if Cygwin did a quick ping on all of the package hosts and then ordered them in order of least latency relative to you. Oftentimes I have to re-start the install process because I accidentally chose a host that's slow enough to delay the install for hours.

I wish it would sort by network throughput instead of latency.

Babun provides an nice layer over cygwin (preinstalled oh-my-z and other goodies) along with an excellent package manager as well. https://github.com/babun/babun

Which is based on apt-cyg AFAIK. And I missed the the ``apt-get upgrade`` functionality in both pact/apt-cyg.

Indeed. It's kind of weird there's no package manager beyond setup.exe in Cygwin. There's even a port of rpm in the package collection. I wonder if Cygwin misses some bigger piece of functionality that is a requirement for rpm. Or maybe it's just good enough for most of use cases.

Problem with apt-cyg is the occasional need to "rebaseall" to keep the cygwin dll's happy. a proper package manager would be nice, though it is a good solution all things considered.

Couple apt-cyg with a batch script to install updates unattended - this made cygwin much nicer:

cd C:\distr\cygwin setup-x86_64.exe --no-desktop --no-shortcuts --no-startmenu --quiet-mode

For me, Cygwin makes Windows bearable. It's still Windows, but, at least, it has a proper shell, interpreters, compilers, compressors (no need for WinZip or WinRAR - think about it!) and so on. For the same reason you need MacPorts or Brew on a Mac, you need Cygwin on Windows.

Unless you are happy to spend your day in Visual Studio, in which case Cygwin will not be that useful.

Windows has had a proper shell for a while now, in the form of PowerShell. It's quite different from the standard Unix shell, and I'm nowhere near as productive in it as I am in Bash, but that's more a function of lack of familiarity than any weaknesses of the shell. In fact, I'd say that it's actually much nicer than unix-y shells for a wide variety of tasks.

All I really find missing these days is good line-editing, and a half-decent terminal emulator in which to run the shell.

> All I really find missing these days is good line-editing

Probably familiar enough for bash people:

https://github.com/lzybkr/PSReadLine

> and a half-decent terminal emulator in which to run the shell.

Not a terminal emulator (although I think it can do Terminal escape sequences if needed):

https://github.com/Maximus5/ConEmu

It's still not a terminal emulator, but you can use Clink [1] to get readline in cmd. Works great with ConEmu or as part of cmder, as others have mentioned.

[1]: http://mridgers.github.io/clink/

Very high ROI. Removes a lot of stress you got just typing cmd.exe.

I knew about ConEmu (though I'm not 100% happy with it either). I'll take a look at PSReadLine, thanks.

However great powershell is, the fact that bash is so universal everywhere else makes it too hard for me to use. With Cygwin I can often move seamlessly between Linux, OSX and Windows without changing anything I do, including all the utility scripts I write etc.

> and a half-decent terminal emulator in which to run the shell.

On Cygwin, try MinTTY. The default cmd.exe console is horrendous. This is derived from PuTTY and much, much nicer.

You can even use MinTTY with cmd.exe (and probably powershell) for dramatically improved user experience.

And, you can also find MinTTY standalone separate from the burden of cygwin. I got it from the msys project.

> It's quite different from the standard Unix shell

And that's the issue. Most people don't want to relearn everything, and I don't see why MS had to reinvent the wheel.

Do you know how to echo text in ASCII or UTF-8? > "text" or > echo "text" For me both come out with weird character encoding

> WinZip or WinRAR

Everyone uses 7Zip now which has a very good command line version and is OSS/free (mostly LGPL licensed, but some of their source code is licenced otherwise because it is from third parties).

Plus Powershell can zip/unzip using the shell.application.Namespace API if you wish. I prefer 7zip myself, but Windows handles basic zip files fine.

Explorer does too when not at command-line.

>(no need for WinZip or WinRAR - think about it!)

I'd be surprised if compressor utilities running through Cygwin's emulation layer could achieve the same speed as a native tool. 7-zip is an open source tool that will handle all your compression / decompression needs on Windows (including rar, gz, many self-extracting exes, and a bunch of very exotic formats). You should really give it a try if you're compressing or decompressing large archives on Windows.

http://www.7-zip.org/

Cygwin should only slow down syscalls. Syscalls should not be a significant fraction of the running time of compression software.

> I'd be surprised if compressor utilities running through Cygwin's emulation layer could achieve the same speed as a native tool.

Why do you think so? The emulation layer should only be relevant for the IO part of the compressors and IO is usually severely limited by the harddisk anyway.

cygwin is fine, but if you want to spend most of your time in bash or using software designed for Unix you probably shouldn't be using Windows in the first place.

Unless you need Windows just slightly more than you need Linux, or your hardware doesn't work properly under Linux, or you need software that Linux, even Wine, can't run. Or your processor isn't even capable of booting Linux, but it can run Windows (Intel Atom Bay Trail comes to mind).

--edit apparently Bay Trail does support Linux. The big hype when it was launched was that it would not, that's where my confusion came in

I mean, no problem, but, ultimately, cygwin is walled off from certain parts of the system and you're just going to have to deal with the fact that WinNT has major differences from Linux for some tasks. I use cygwin sometimes too but it makes more sense "in addition to" than "instead of."

Linux runs on Bay Trail, e.g. https://www.happyassassin.net/fedlet-a-fedora-remix-for-bay-...

the problem was the 32 bit UEFI. Also solved: http://unix.stackexchange.com/questions/155557/installing-li...

actually I'm pretty sure Bay Trail do run Linux.

Unless your business requires software which only runs on Windows, and using cygwin allows you to do a lot of things better on Windows, and lets you do a lot of things cross platform that would be a waste of time to implement two ways.

I'd be more inclined to agree with you if you'd ended that statement with "... designed for Unix, perhaps you should consider whether you should be using Windows in the first place".

There are a lot of people out there that have to use Windows for a variety of reasons, but are glad to be able to do some shell-related things on it in a unix-like shell.

I'm a bit split at this point.. in general, I have an ubuntu server VM running (with docker), with my home directory mounted via samba as a drive in windows, and have a couple conemu tabs open ssh'd into the VM... I can continue to edit in windows, but run in Linux.

At least for my stuff that will run in Linux (node/iojs and golang) targeting docker containers, it works well.

A lot of people are stuck at jobs where they need Windows for some reason or another (maybe simply because their boss says so). In those cases, Cygwin makes their life bearable.

I also want to out in a good word for Cygwin. It's fantastic, I have absolutely no complaints about it. I have python and GCC, as well as a fully working shell. I can do Linux development in either of my favorite languages (Python and C++) without any kind of worry, and they work without modification on Linux.

Plus, having a working Bash with everything I want on Windows blows my mind.

Is it better than using virtualbox?

It applies a Linux-like polish to a Windows machine. You can manipulate the whole Windows filesystem from within a Linux-like environment. With a VM you get a full Linux environment that cannot simply get to your Windows environment - you get a clear separation between the two.

I like to say Cygwin "civilizes" Windows.

I agree. And when you add Chocolatey to the mix (just add it with an elevated cmd.exe as stated on chocolatey.org), you're about half-way to a GNU/Linux-ish Windows. (In elevated PowerShell, I actually used "choco install cygwin -y" after doing so!) I think in Windows 10 this is supposed to be even better with their OneGet framework that will be compatible with Choco. Things are looking better for those who have to use Windows but want the power of the GNU/Linux environment. It is thanks to which I no longer need VirtualBox anymore, granting the benefit of allowing me to run code a little more efficiently.

The only gripe I have is I would really like to use openssh-server on Windows the way I do on GNU/Linux. I have yet to find a comparable solution that is opensourced and free.

Chocolatey is a bit of a security nightmare just waiting to happen. I heard it has a veto system now but it would have been better to design it from the ground up to use a central repo where people could do pull requests. The lack of review and arbitrary ownership of packages makes it very iffy, particularly on work/production workstations or servers.

You're right about the security aspect, which is what Microsoft says OneGet will also attempt to resolve (in effect, replacing chocolatey's repo with theirs, I'd assume).

I believe MS wants you to use remote Powershell instead of SSH.

I dig the ability to cross into remote file systems transparently (much like PowerShell). Running "df -h //devwinserver1/c$" is cool, as is the ability to clean up cruft when a Nagios disk alert goes off, all from the comfort of my bash shell.

Plus, with Xwin running, I can utilize cluster SSH to make managing Unix servers a bit less painful from my Windows machine (corporate standard image I have no control over).

I like to say that Cygwin gives me the best of both worlds because Linux desktop environments simply lack the polish that the Windows desktop has.

Sometimes a linux VM won't cut it, like on corporate networks heavily invested in Windows infrastructure (activedirectory domains and many layers of authentication that are either difficult or impossible to interop with linux).

It took many years before I realized and tried it, but Cygwin also very easily lets you run an OpenSSH server on Windows, which I find incredibly useful.

And it's also the only reasonable and free option for this. (Correct me if I'm wrong but I've tried)

I've used Cygwin a lot in the past; it's great provided you don't have to stray outside the Cygwin world. If you need to interact with standard Windows executables it gets very hairy. In order to maintain Unix-ish semantics, it needs to do some rather odd things --- IIRC stderr is passed via a Windows named pipe rather than via the Windows file descriptor 2?

And heaven help you if you need to run a Cygwin binary on a system with a different version of Cygwin installed on it...

We found ourselves switching to MSYS whereever possible simply because it was less clever, and therefore more predictable.

(Also the Cygwin package manager makes me sad.)

For me I've had too many problems with cygwin and $DAYJOB installs BLODA, so I'm really interested to see what comes of this, also since it uses arch and pacman, which are my distro of choice, it sounds pretty perfect to me! (no more having to recompile everything from source with cygwin or `rebaseall` and suchlike)

BLODA: Big List Of Dodgy Apps

Hmm, Have you looked at http://mobaxterm.mobatek.net/ before. I found this less of a hassle to install and work with, than cygwin.

Hmm... seems interesting, I still like the idea of this foreign-linux, it seems like the idea has a lot of potential. Thanks.

I don't think it is fair to compare it with Arch packages in numbers. How many of these are really usable? Cygwin is a limited environment per se.

In this sense, it is better to compare msys2 with Arch packages, since msys2 uses pacman.