PuTTY wish win-command-prompt

Home | Licence | FAQ | Docs | Download | Keys | Links
Mirrors | Updates | Feedback | Changes | Wishlist | Team

Lots of people ask whether PuTTY would be able to act as a front end for Windows command interpreters (Command Prompt, bash, etc), in place of the not-very-pleasant standard console window.

I haven't investigated this very closely, but it's not clear to me that this would be useful for anything except Cygwin. I've used Windows telnetds, and they look to me as if they're working in a fundamentally different way from a Unix telnetd. When you issue a command that scrolls the screen a lot, it seems to get redrawn from the server end rather than scrolled - as if the server had its own image of what the console screen ought to look like and was running something like libcurses to reproduce that image on the client side.

This leads me to conjecture that Windows's equivalent of a pty works more like /dev/vcs than /dev/pty* - Windows will still do the terminal emulation itself, and all you can do is read the results off a rectangular screen buffer and transfer them to an output device. So there would be no scope, in this model, for PuTTY to supply superior terminal emulation.

The alternative to that, of course, would be to ignore Windows's pty equivalent (whatever it is) and run the application in an ordinary pair of pipes instead. But this doesn't seem to work very well for the ordinary Windows Command Prompt utility: if you do that, you lose the command-line editing and recall which the console device provides.

As far as I can tell (and this is still all deductions based on observation, and might be wrong), the Cygwin library takes a completely different approach: the first Cygwin program you run in a Windows console will turn part of itself into a terminal emulator, create some pipes, and run the rest of the program in those pipes. If the program spawns other programs, they are passed the same pipes, and all terminal emulation is done by whichever program was first to get hold of the real console device. So in this model, PuTTY could contribute: it could run (say) Cygwin bash in a pair of pipes, and apply its own terminal emulation to the data it received from bash. However, there's still the question of what it would do about local line editing (which Unix utilities would still want to enable sometimes). I suspect Cygwin has a means of dealing with this, which a hypothetical local-PuTTY would have to implement.

In summary: I believe Windows does not supply an interface at the right level to make it sensibly possible to run a Command Prompt inside PuTTY's terminal emulator. I believe it would be possible in theory, but quite fiddly, to turn PuTTY into a local xterm-alike for the use of Cygwin programs only; but this is significantly less useful than the original goal of making it a generic replacement for the Command Prompt window. So unless anyone can correct my deductions above, I don't think this has a sufficiently high benefit-to-effort ratio to be worth doing.

A workaround is of course to run an SSH (or telnet) server on your Windows box.

Mark Edgar has created PuTTYcyg (link on Links page), which allows PuTTY to act as a terminal for Cygwin (with the aid of a helper application linked against Cygwin). (further discussion in 4032C9DD.4000202@student.gc.maricopa.edu)

Simon's reaction:

This certainly looks believable enough for the moment.

What I'd _like_ to do is to set up a more general mechanism for
having PuTTY monitor Windows file descriptors as well as network
sockets. This would be useful for supporting the OpenSSH-like
ProxyCommand function (for example running PuTTY over a secondary
Plink), and for talking to serial ports; and it would _also_ be an
interesting alternative approach to your problem, since we could
arrange to run (something like) cthelper with a group of pipes
rather than local network connections.

If we were to do this, it would open up two or three possible
avenues of implementation for your feature:

 (a) cthelper works roughly as it now does, with two data channels
     from PuTTY to it so that data and screen resizes can be
     separated. They could now be pipes rather than network sockets,
     but this would still require an extra back end in PuTTY.

 (b) If cthelper were to speak (a reasonably small subset of) the
     Telnet protocol on its stdin/stdout, then it might be possible
     to do this _without_ any modifications to PuTTY once I
     implement proxy commands: you would supply `cthelper' as a
     proxy command, and select Telnet as the protocol (the host and
     port would then become unimportant). Then cthelper could
     separate the incoming Telnet stream into screen resize events
     and data, perform minimal Telnet encoding on the data it sent
     back, and your code could be completely independent of changes
     to mine.

 (c) I'd also quite like to implement a DLL plugin interface; I've
     been wanting to do this for a while but recently there have
     been some slightly more immediate reasons for wanting it. It
     would obviously be good to have DLL plugins be able to add
     extra back ends, so possibly that would be a good approach.

For the moment, though, yours looks entirely workable and I'll have
to give it a try...

Audit trail for this wish.