A new "win"

What is it?

A replacement for "win", a program that is used to provide an interface between the editing environment wily and a shell or other interactive program.

Why does it exist?

Because the standard "win" was just not cutting it for me. It works well, but wasn't quite feature-full enough for me. So, I changed a few things:

It now uses a pseudo-terminal interface, rather than pipes for communication with the interactive sub-process.
It is now possible to use Ctrl-D to indicate an end-of-file.
There is now a "Signal" command that sends an arbitrary signal to a process running under win's control.
Many wily-intrinsic commands (for example, "Del" and "Clear") are now passed through to wily rather than being passed to the shell.
There is now a "Scroll" command that controls whether or not the window scrolls to keep up with new output. This is similar to the command of the same name in the acme "win", except that it acts as a toggle.
win now recognizes the escape sequences produced by "gdb -f". This means that if you run "gdb -f" within a "win" window, source files will open up automatically in wily.

Using a pseudo-terminal adds a lot of hassle and portability problems. Currently the code works on Linux and Solaris. I'm sure that it won't work on BSD systems, but I'm happy to incorporate a patch that will make it work on more systems. I considered long and hard whether it was worth doing; in the end I couldn't think of any other way to send an EOF to the subprocess while still keeping the pipe open. As a plus, some programs run under win now need less convincing that they are being used interactively. As a minus, some programs will now spew all sorts of useless noise and terminal control characters (scp seems to be a major offender).

I considered allowing terminal control characters (e.g., Ctrl-C) to send signals, but I consider "Signal" to be more flexible and more in the wily spirit. Unfortunately, I couldn't make it work properly with a job-control shell (anyone who knows how to get the foreground process group of a pty given the file descriptor of the master, please educate me). Not that there is any good reason to be using job control, especially within wily, but most modern shells turn it on by default when interactive. "set +m" seems to be the POSIX way of turning it off.

The "Scroll" and gdb features need a patch to wily 0.13.41 (9libs version) that allows programs to execute gotos without warping the cursor (both features are very annoying without this patch). Since this patch preserves source and binary compatibility with existing programs using wily's rpc interface, I hope that it can be integrated into the official wily.

The gdb extension will undoubtedly be construed by some as a misfeature. Running gdb without the -f option will avoid windows popping up, so really the choice is yours.

How do I get it?

Download the source code for win, pop it into your tools/c directory in place of the old one, and make.

Who is to blame for this?

My name is Richard C. Bilson, and I am the sole author of the above enhancements. I am not the author of the original; it is not clear from the contents of the distribution that the identity of the original author has been firmly established. This code is a derivative of the original, and if the original author wishes to take issue with my modifications he or she is invited to contact me. Indeed, anyone having comments regarding win is invited to discuss them with me personally or on the wilyfans mailing list. I am sure that there are better ways of doing many of the things that are done here, and I would enjoy hearing about them.