Real friends don't let friends use Windows without Cygwin. :-D
Seriously, though. If you have machines with lower-end resources, who wants to to wait on a VM. Plus I wouldn't trust testing to a virtualized machine. I wouldn't release software without testing it on a real box.
Plus, you get cron, sshd, and most importantly a bash shell that works much like it does on Linux. For people who prefer a Linux-like environment, but have to deal with Windows (for work, or for whatever reason), Cygwin is a must-have, IMHO.
I realize this is too late (I've been away from the computer for a few days), but I'll respond anyway.
NO that's NOT what I meant.
I meant that I wouldn't release software that was designed to run on, say Windows XP/7/8.x/..., without running it natively on a machine running those operating systems.
I was NOT talking about virtualized Linux systems. I was talking about desktop software (since we were talking about Cygwin, I guess I thought that would be obvious, but perhaps I should have spelled that out).
Yes, people do still write software for desktop operating systems (I realize that's a shock, and "how 1994 of them!", etc). Yeah, it is nice to have Virtualbox or VMWare, etc to test and debug on (so if something hoses the OS, you don't have to reboot the hardware, and stuff like that), but if the app is targeted at a desktop OS, I'll be testing it in a non-virtualized environment at some point. I wouldn't rely strictly on testing in a Windows VM running in Virtualbox under Linux. Call me paranoid if you want, but I still think it makes good sense.
I do production stuff that runs on a Linux VPS also. That's an entirely different ball game. I'd have absolutely no problem releasing that software after only running it on a virtualized system. Of course, in that case, the target environment is a virtualized system, so the production environment is the same as the development environment.
So, that's my response to you if you were being serious. If you were just trying to be funny, then ... oh never mind. :-D
Cygwin is not UNIX. It looks like it and runs UNIX tools but it has some gotchas that can shoot you in the toes and face if you move your stuff to another box.
I'm not sure I understand what you are objecting to (or what exactly of dmourati's response you were agreeing with) . I never claimed that Cygwin was UNIX. Far from it. However, Cygwin gives me enough of a UNIX-like environment in Windows operating systems to make administering and developing software in them almost bearable. I'd rather not have to deal with Windows environments at all, but my work requires it, so I do the best I can.
I don't have any problem moving things from box to box. If I administer a Windows machine, it will almost always have Cygwin on it. I do development and administration on them all the time. I'd be curious to know what kind of "stuff" you were moving to another box that gave you trouble. Perhaps you were talking about moving executables/DLLs between different versions of Cygwin. I keep my machines mostly on the same version of Cygwin, and I'm not developing Cygwin-specific applications, so I'm not linking to the Cygwin DLLS, so I don't have problems with that.
I like to use a familiar set of utilities on Windows. It's not just for software development either. A little while ago I used the Cygwin shell to clean up my downloads folder and it worked like a charm. I also used to have a couple of shell scripts for maintaining my music collection. Spinning up a virtual machine for this kind of stuff seems a little unnecessary, and it seems cumbersome to have to maintain a list of shared folders when I really want my tools to work on whatever directories/mounts Windows has access to.
Even when I do work in a VM, I use a Cygwin terminal and ssh client to connect to it. mintty is fairly amazing.
You can't (as far as I know) run a Windows program from a linux VM. You can browse around the file system all you want from a VM, but can't do anything binary-ish to the files you find.
I work in the cygwin terminal as much as possible on my work Win7 box. I often do this from cygwin:
$ OurWindowsOnlyProprietaryLogReader someLog.log
which runs the windows program to process the log. Similar with Excel.
I do also use a vagrant VM, but I rarely fire it up these days because I do a lot of what I just described. One reason I wanted vagrant was for tmux, and tmux on cygwin will be welcome.
It's been a while since I used Windows so I can't really comment on the current state of Cygwin but the one thing that I still recommend Cygwin for is to use the X server if you want to log on to a *nix box and run something graphical.
I appreciate people doing work like this. I've worked in Windows-only environments and used cygwin and some window manager (such as bblite) for my workflow. Good to know if I were still relying on that crutch that I could get tmux working.
The supplied hardware at these gigs didn't really have the spec for spinning up VMs - this also spared me from fiddly network and other shared resource setup.
I even had a "portable" cygwin install on a USB stick.
Git for Windows uses MSYS, which is actually a fork of Cygwin. Compared to Cygwin, Git's MSYS distro is missing a lot of software and the version of Vim packaged with Git for Windows is a native Windows build (not MSYS-aware,) so it doesn't work in mintty. This can really bite you when editing a commit message or trying to do an interactive rebase. On my machine, Vim will just hang when started from an MSYS mintty.
I've not tried Vagrant on Windows (or indeed used Windows for a while). Is it easy.to give the VM full access to the Windows filesystem, the way that Cygwin has?
It's easy to map a directory on a Windows host to a vagrant VM. By default, Vagrant will share your project directory (the directory with the Vagrantfile) to /vagrant.
Well, I just installed this. I always assumed tmux wasn't compatible with Cygwin, but I guess it is.
Note that you can skip steps 2 and 3 if you install libevent-devel and libncurses-devel in step 1. The Cygwin provided versions of these packages are good enough (in fact, libevent is the same version.) Also, I didn't get any warnings when running autogen.sh, but I have all the available versions of autoconf and automake installed, so that might be why.
You were right until very recently. If I recall correctly, tmux used to send file descriptors over sockets, something which isn't supported by cygwin. Pretty recently someone made a patch to tmux that allowed it to work without the unsupported behaviour.
Weird coincidence: I found this yesterday and spent the afternoon compiling it up on my work machine, where I'm forced to use Cygwin for lack of anything better. Open up HN this morning and it's on the front page!
Anyway, these steps worked fine for me and I didn't even get any complaints at the autogen stage. It took about 40 minutes to get everything compiled and installed, which I didn't think was too bad on my ancient work machine.
While this comment may be a bit out of place, I thought I'd throw it in.
For any OSX users here, iTerm 2 has fantastic tmux integration. Simply launch tmux with the -CC flag (tmux -CC). iTerm 2 will open a new window for your tmux session. Tabs that are opened, split, etc. are created as tmux windows / panes and can be quickly restored upon resuming a tmux session.
But cygwin isn't linux, and on 99% of actual linux distributions you will never have to compile tmux from source. A better statement would be "And people wonder why Windows never became mainstream for developers."
Steps to install cygwin on actual linux? "(package manager) (install) tmux". And on OS X? Install brew by copy and pasting a command into terminal, then "brew install tmux". Even if you're an average consumer you could complete both of those steps without a problem. (Then again, why would the average consumer want tmux?) Windows/cygwin is the problem here, not linux.
This is for installing tmux in Cygwin on Windows. Installing tmux in Ubuntu is as simple as searching and installing tmux from the Ubuntu Software Center (or apt-get install tmux).
I know you're snark is par for the course here, but if you ever do Windows sysadmin work and you need to do some stuff on Windows that is unavoidable, Cygwin makes it much better. Even there terminal app, which can go fullscreen with tail, is worth debugging stuff. Try doing that with PowerShell and get-content -wait YourFileName.txt. I have literally waited minutes after a program exited while PS tries to keep up.
But what do I know, I use Cygwin. Also see why Linux != Cygwin below.
I don't think it makes it any easier. To be honest (as someone who deploys a lot of Windows machines) PowerShell only makes it fractionally easier. There are always packages and bits of software that just don't have a programming interface at all (not even COM) at which point you are, to use the technical term, fucked whether you use PS or Cygwin.
The platform as a whole stinks for programmability and I hate working with it.
For example:
Start your new Ubuntu machine...
$ vagrant init precise32 http://files.vagrantup.com/precise32.box
$ vagrant up
SSH in..
$ vagrant ssh
And install tmux
$ sudo apt-get install tmux
*note: these commands are off the top of my head, please read the getting started guide for proper instructions.