Steps to install tmux in Cygwin(java.ociweb.com)
java.ociweb.com
Steps to install tmux in Cygwin
http://java.ociweb.com/mark/programming/tmuxInCygwin.html
37 comments
With the current state of virtualization (vagrant/virtualbox for example), I have to wonder why anyone would choose cygwin. Honest question.
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.
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 misread your comment and thought I agreed with everything you said until I re-read it!
Wouldn't release software without testing it on a real box? We run all our production software on EC2.
Much like it does on Linux? Oh no. Oh no. You are lost my friend.
Wouldn't release software without testing it on a real box? We run all our production software on EC2.
Much like it does on Linux? Oh no. Oh no. You are lost my friend.
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
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
This.
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.
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 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.
When my use-case is to administer a Windows system, Cygwin's property of being a native application is its advantage.
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.
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.
I used Xming a while back, which seemed to work just as well as an X server, just without the Cygwin horrors.
Well one strike against virtualbox that I recently learned is that it bumps the system interrupt from 64Hz to 2048Hz, making it a giant power sink.
Because running a VM still incurs a lot of overhead. Which is a bit excessive if all you want to do is run a terminal.
> if all you want to do is run a terminal
Then Git for Windows (which is built upon MinGW, and includes bash, grep and whatnot) + MinTTY is immensely more useful and lightweight than Cygwin.
Then Git for Windows (which is built upon MinGW, and includes bash, grep and whatnot) + MinTTY is immensely more useful and lightweight than Cygwin.
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 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.
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:
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.
I work in the cygwin terminal as much as possible on my work Win7 box. I often do this from cygwin:
$ OurWindowsOnlyProprietaryLogReader someLog.log
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.
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.
I've found network folder sharing (cifs or vboxfs) to be quite slow and buggy for certain tasks. Is there any known good alternative?
I agree, I have had nothing but trouble from Cygwin when I used it.
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.
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.
I see. It would have been nice to see the problem fixed on the Cygwin side, but either way, it's great to be able to use tmux on Windows. I missed it.
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.
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.
Thanks for the "it worked for me," makes me more willing to give it a shot.
Wow! I didn't know tmux works on Cygwin. Last I checked there was an issue due to Cygwin not supporting proper file descriptors.
Apparently tmux has worked under Cygwin for some time now - since July at least. The actual patch appears to originate here, and is a neat little read: http://sourceforge.net/mailarchive/message.php?msg_id=308508...
Apparently tmux has worked under Cygwin for some time now - since July at least. The actual patch appears to originate here, and is a neat little read: http://sourceforge.net/mailarchive/message.php?msg_id=308508...
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.
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.
Why compile the first two from source? They are available in the package manager.
And people wonder why Linux never became mainstream for consumers.
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.
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.
If it were on the default package list if would just be apt-cyg install tmux (if you have apt-cyg installed)
Windows is mainstream for developers. There are millions of them. Probably more than the open source community.
They just suffer more!
(Note: I do both 50/50 and certainly don't prefer writing code on windows)
They just suffer more!
(Note: I do both 50/50 and certainly don't prefer writing code on windows)
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.
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.
The platform as a whole stinks for programmability and I hate working with it.
Go back to 4chan, kid.
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.