PuTTY wish cygwin-terminal-window

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Snapshot | Docs | Changes | Wishlist

It would be nice to be able to use PuTTY as a local terminal window application for Cygwin shell sessions: a sort of local xterm-alike (or rather, pterm-alike).

This is a perfectly feasible piece of work (much, much more so than the superficially similar-looking but far more difficult win-command-prompt), and in fact it can just about be achieved without any actual changes to PuTTY. PuTTY's support for talking to a local Windows proxy subprocess in place of making a network connection permits a solution in which that proxy subprocess sets up a Cygwin pseudo-terminal, and speaks Telnet on its standard input and output (which connect to PuTTY). So you would configure PuTTY to think it was making a telnet connection to localhost, but actually interpose this helper program via the Proxy configuration panel – and the effect is that PuTTY speaks directly to the Telnet implementation in the helper program, which starts a Cygwin pty and runs a shell in it.

So the helper process has to be a Cygwin application (it must link against the Cygwin DLL so it can work with the Cygwin emulation of ptys), and it needs to speak Telnet on its standard I/O channels and at the other end talk to a pty. In other words, it's actually very similar to a Unix telnet daemon, of the type that can be launched from inetd.

In fact, it would be really nice if Cygwin's own telnetd could be used to do this job. Then an unmodified PuTTY could talk to an unmodified Cygwin installation with only a mildly fiddly piece of configuration.

However, when I actually tried this I found that Cygwin's telnet server wouldn't quite do the job: for instance, it wouldn't operate in the absence of syslogd, and it didn't have a command-line option to make it invoke some program other than login in its pseudo-terminal. I wouldn't expect that those should be difficult features to add, but I've never got round to making a serious effort to write them properly and get them accepted upstream.

However, I have written a small and specialist Telnet server of my own which is suitable for this job. (That was a lot less work than it sounds, since several pieces of PuTTY were easily reused to do most of the heavy lifting – client-side and server-side Telnet are very similar.) I'm just not sure how to sensibly package it, since really it should be a Cygwin application so as to work with Cygwin installations of all versions, but in that case it's better just to adapt Cygwin telnetd...

In the meantime, though, for anyone who wants to use it, here's the (currently rather long and involved) process for setting it up:

• For a start, make sure you have a PuTTY containing the fix for local-proxy-telnet, which is critical to this mechanism working at all.
• Get the source code for my Telnet server, which is in the subdirectory contrib/cygtermd of the PuTTY source tree. (You can get the PuTTY source code from the Download page, as a zip or tar file or by checking it out from Git.)
• In the contrib/cygtermd directory, run the Cygwin make command. (You will need Cygwin's make and gcc installed.) This will create an executable file called cygtermd.exe.
• Copy cygtermd.exe into Cygwin's /bin directory. (This is unfortunately necessary because it will be run by a non-Cygwin application and will therefore need to be in the same directory as the Cygwin DLL in order to find it.)
• Now configure PuTTY to run a session using cygtermd, as follows.
  • On the front page (Session panel):
    • Set connection type to Telnet.
    • Enter something in the host name box. (PuTTY won't launch a session at all unless it believes it's connecting to something; also whatever you type here will go in the window title bar. "localhost" is probably sufficient, if you have no better idea.)
  • In the Proxy panel:
    • Tick the box labelled "Consider proxying local host connections". (Otherwise, PuTTY will not use the information in this panel to override its default behaviour of just making a normal Telnet connection to your local machine.)
    • Set "Proxy type" to Local.
    • Enter in the command line field a Windows command line which launches cygtermd in the right directory and with the right subcommand. cygtermd will expect a directory name as its first argument (in Cygwin style), and will interpret the rest of its arguments as a command line. So you might, for instance, do something like this:

      c:\cygwin\bin\cygtermd.exe /home/simon /bin/bash -login
      

      which would arrange that the helper program will be run in Cygwin's /home/simon directory, and will launch the program "/bin/bash -login" (i.e. a normal Cygwin login shell) inside the telnet session.
      • 2015-11-26: it's been reported that a Windows 10 update breaks this. A 64-bit Cygwin proccess with a 32-bit parent process apparently runs into a memory error when it tries to fork(), so that cygtermd won't be able to run your shell. Reports suggest that this worked in Windows 10.0.10240 and failed in 10.0.10586, and that you can work around it by putting a non-Cygwin 64-bit process in between PuTTY and cygtermd, e.g. by changing the proxy command to something more like this:

        c:\windows\sysnative\cmd /c c:\cygwin\bin\cygtermd.exe /home/simon /bin/bash -login
        

  • In the Data panel:
    • You should be able to configure your terminal type and set environment variables, if you want to do either of those things. cygtermd supports the Telnet options for both.

This is all a lot of hassle, even though it only has to be set up once. If Cygwin telnetd were fixed so that it could do the job of my cygtermd utility, I would probably think it reasonable to add a piece of dedicated PuTTY user interface to make it trivially easy to run a local Cygwin shell session.

Our Links page links to a modified version of PuTTY called PuTTYcyg, which was able to act as a Cygwin local terminal (again using a helper process linked against Cygwin) before PuTTY proper could do so.

Contact us:mirrors@uni-ruse.bg

Developed and supported by the Centre for Information and Computing Technologies