I'd missed out an if statement in the Unix proxy stderr code
introduced by commit 297efff30, causing ret->cmd_err to be passed to
uxsel_set even when it was -1 (which happened in the non-GUI tools).
Unfortunately, putting a negative fd into the uxsel tree has really
bad effects, because the first_fd / next_fd interface returns a
negative number to signal end-of-list - and since the uxsel tree is
sorted by fd, that happens _immediately_.
Added the missing if statement, and also an assertion to make sure we
never pass -1 to uxsel_set by mistake again!
In case a front end needs to store more than an integer id to be
returned to uxsel_input_remove, we now return a pointer to a
frontend-defined structure.
inside one single uxsel front end, better to do it centrally and
avoid passing zero flags on to the front end in the first place. I'm
sure other similarly structured front ends could get confused by it
too.
[originally from svn r7171]
[r7164 == 65f9735b95]
being able to be a PuTTY as well as a pterm. In the process I've
also moved icky things like actually reading from the pty fd and
printing the `terminated on signal' messages into pty.c where they
obviously should have been in the first place. Also there's been one
interesting repercussion in the terminal code: terminal.c's
from_backend now calls term_out() directly rather than expecting the
front end to call it afterwards. This has had the entertaining side
effect of fixing a Windows-specific bug whereby activity in a port
forwarding through a PuTTY with a blinking cursor caused the cursor
to blink to ON (!!!!). So, a surprisingly far-reaching checkin as it
turns out...
[originally from svn r3017]
functionality that deal with selectable fds in general. The idea is
that pty.c will stop passing its fd straight to pterm.c and hand it
to this module instead, and pterm.c will start requesting a general
list of fds from this module rather than expecting a single one from
pty.c, with the ultimate aim of pterm.c being able to form the basis
of a Unix PuTTY as well as pterm proper.
[originally from svn r3015]