nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-10 09:58:01 +00:00
Code Issues Projects Releases Wiki Activity
c9e6118246
putty-source/unix/uxpty.c

1605 lines
43 KiB
C
Raw Normal View History

pty backend now supports the changed function interface, so pterm now compiles and runs again after the major destabilisation. Unfortunately it wasn't feasible to actually encapsulate all of the pty backend's data, since the utmp helper and the need to fork and drop privileges before doing anything else at all rather confuses matters. So the data handle passed around to the pty backend is a null pointer, and the pty backend is just as global-ridden as it always has been. Shame, but such is life. [originally from svn r2128]
2002-10-25 11:50:51 +00:00
/*
* Pseudo-tty backend for pterm.
*/
pterm now uses the new uxsel module, so it's one step closer to 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]
2003-03-29 18:30:14 +00:00
#define _GNU_SOURCE
And that's it! pty.c is now a real pty backend rather than a loopback interface; pterm now runs $SHELL and gives every impression of being not a bad terminal emulator. I'm quite pleased with that. :-) [originally from svn r2015]
2002-10-10 12:40:05 +00:00
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
#include <stdio.h>
#include <stdlib.h>
And that's it! pty.c is now a real pty backend rather than a loopback interface; pterm now runs $SHELL and gives every impression of being not a bad terminal emulator. I'm quite pleased with that. :-) [originally from svn r2015]
2002-10-10 12:40:05 +00:00
#include <string.h>
#include <unistd.h>
xterm-class programs should exit when their primary child process dies, rather than waiting around until the last open handle on the pty closes. [originally from svn r2044]
2002-10-14 09:18:34 +00:00
#include <signal.h>
Do proper select-for-write on ptys. Currently, pasting a sufficiently large string into pterm in any circumstances in which it's echoed back to the terminal will cause a deadlock once the pty's write buffer fills up. [originally from svn r6582]
2006-02-23 13:38:44 +00:00
#include <assert.h>
And that's it! pty.c is now a real pty backend rather than a loopback interface; pterm now runs $SHELL and gives every impression of being not a bad terminal emulator. I'm quite pleased with that. :-) [originally from svn r2015]
2002-10-10 12:40:05 +00:00
#include <fcntl.h>
Resizing of pterm now works, and the size information is correctly sent on to the pty. [originally from svn r2036]
2002-10-13 12:44:01 +00:00
#include <termios.h>
Support for BSD-style pty devices. Tested under Linux; might need minor tweaks to run under other BSD-style OSes. [originally from svn r2056]
2002-10-15 10:49:38 +00:00
#include <grp.h>
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
#include <utmp.h>
#include <pwd.h>
#include <time.h>
xterm-class programs should exit when their primary child process dies, rather than waiting around until the last open handle on the pty closes. [originally from svn r2044]
2002-10-14 09:18:34 +00:00
#include <sys/types.h>
RJK's OS X portability patch: - initialise blank mbstate_t using memset rather than an ad-hoc initialiser. - expand the OMIT_UTMP ifdefs to enclose a load of entire functions that would generate `static function never called' warnings if left as empty shells. - couple of other fiddly things. [originally from svn r4896]
2004-11-24 11:36:08 +00:00
#include <sys/stat.h>
xterm-class programs should exit when their primary child process dies, rather than waiting around until the last open handle on the pty closes. [originally from svn r2044]
2002-10-14 09:18:34 +00:00
#include <sys/wait.h>
Resizing of pterm now works, and the size information is correctly sent on to the pty. [originally from svn r2036]
2002-10-13 12:44:01 +00:00
#include <sys/ioctl.h>
RJK's general signal-handling robustness patch. Should fix the weird spin behaviour occasionally seen after pterm's child process dies. [originally from svn r2181]
2002-11-02 14:35:57 +00:00
#include <errno.h>
uxpty: give pty_backend_create a struct ssh_ttymodes. This will be applied to the pty's termios settings at creation time, superseding the default settings uxpty has always used. It works by including the new sshttymodes.h with TTYMODES_LOCAL_ONLY defined, so that modes not supported by a particular Unix system are automatically quietly ignored. Of course, a struct ssh_ttymodes always has the option of representing "please make no change to the defaults", and of course, that's precisely what is done by the one that pty_init constructs for clients that aren't calling pty_backend_create directly.
2018-10-18 19:37:33 +00:00
#include <termios.h>
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
#include "putty.h"
uxpty: give pty_backend_create a struct ssh_ttymodes. This will be applied to the pty's termios settings at creation time, superseding the default settings uxpty has always used. It works by including the new sshttymodes.h with TTYMODES_LOCAL_ONLY defined, so that modes not supported by a particular Unix system are automatically quietly ignored. Of course, a struct ssh_ttymodes always has the option of representing "please make no change to the defaults", and of course, that's precisely what is done by the one that pty_init constructs for clients that aren't calling pty_backend_create directly.
2018-10-18 19:37:33 +00:00
#include "ssh.h"
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
#include "tree234.h"
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
Make Makefile.gtk build again on Linux (assume <utmpx.h>). [originally from svn r5764]
2005-05-09 13:27:51 +00:00
#ifndef OMIT_UTMP
Use pututxline() in place of pututline(), since the former is standardised by X/Open and actually seems to be more common (NetBSD has it). Also use updwtmpx() rather than directly writing to the wtmpx file, though more for reasons of aesthetics than anything practical. [originally from svn r5678]
2005-04-25 23:28:25 +00:00
#include <utmpx.h>
#endif
/* updwtmpx() needs the name of the wtmp file. Try to find it. */
#ifndef WTMPX_FILE
#ifdef _PATH_WTMPX
#define WTMPX_FILE _PATH_WTMPX
#else
#define WTMPX_FILE "/var/log/wtmpx"
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
#endif
#endif
Use pututxline() in place of pututline(), since the former is standardised by X/Open and actually seems to be more common (NetBSD has it). Also use updwtmpx() rather than directly writing to the wtmpx file, though more for reasons of aesthetics than anything practical. [originally from svn r5678]
2005-04-25 23:28:25 +00:00
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
#ifndef LASTLOG_FILE
#ifdef _PATH_LASTLOG
#define LASTLOG_FILE _PATH_LASTLOG
#else
#define LASTLOG_FILE "/var/log/lastlog"
#endif
#endif
Finish up utmp processing: add the -ut- command-line option to suppress stamping it at all. (I suppose this ought to be part of the cfg structure really.) [originally from svn r2059]
2002-10-15 12:42:58 +00:00
/*
* Set up a default for vaguely sane systems. The idea is that if
* OMIT_UTMP is not defined, then at least one of the symbols which
* enable particular forms of utmp processing should be, if only so
* that a link error can warn you that you should have defined
* OMIT_UTMP if you didn't want any. Currently HAVE_PUTUTLINE is
* the only such symbol.
*/
#ifndef OMIT_UTMP
#if !defined HAVE_PUTUTLINE
#define HAVE_PUTUTLINE
#endif
#endif
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
typedef struct Pty Pty;
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
/*
* The pty_signal_pipe, along with the SIGCHLD handler, must be
* process-global rather than session-specific.
*/
static int pty_signal_pipe[2] = { -1, -1 }; /* obviously bogus initial val */
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
typedef struct PtyFd {
int fd;
Pty *pty;
} PtyFd;
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
struct Pty {
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
Conf *conf;
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
int master_fd, slave_fd;
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
int pipefds[6];
PtyFd fds[3];
int master_i, master_o, master_e;
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
Seat *seat;
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
char name[FILENAME_MAX];
Use pid_t more consistently. Should shut up a warning from GCC 4.6, and may conceivably help on platforms where int and pid_t aren't sufficiently similar. [originally from svn r9110]
2011-03-01 23:00:32 +00:00
pid_t child_pid;
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
int term_width, term_height;
int child_dead, finished;
int exit_code;
Do proper select-for-write on ptys. Currently, pasting a sufficiently large string into pterm in any circumstances in which it's echoed back to the terminal will cause a deadlock once the pty's write buffer fills up. [originally from svn r6582]
2006-02-23 13:38:44 +00:00
bufchain output_data;
uxpty: support SS_EOF, when in pipe mode. If the child process's standard input is provided by a pipe that's separate from its output channels, we can - and should - honour a request to cause that process to receive input EOF, by closing the output end of that pipe. As usual, we do this by setting a pending-EOF flag and calling try_write, to ensure that any buffered output data is sent before the pipe actually closes.
2018-10-18 17:04:31 +00:00
int pending_eof;
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
Backend backend;
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
};
/*
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
* We store all the (active) PtyFd structures in a tree sorted by fd,
* so that when we get an uxsel notification we know which backend
* instance is the owner of the pty that caused it, and then we can
* find out which fd is the relevant one too.
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
*/
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
static int ptyfd_compare(void *av, void *bv)
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
{
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
PtyFd *a = (PtyFd *)av;
PtyFd *b = (PtyFd *)bv;
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
if (a->fd < b->fd)
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
return -1;
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
else if (a->fd > b->fd)
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
return +1;
return 0;
}
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
static int ptyfd_find(void *av, void *bv)
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
{
int a = *(int *)av;
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
PtyFd *b = (PtyFd *)bv;
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
if (a < b->fd)
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
return -1;
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
else if (a > b->fd)
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
return +1;
return 0;
}
And that's it! pty.c is now a real pty backend rather than a loopback interface; pterm now runs $SHELL and gives every impression of being not a bad terminal emulator. I'm quite pleased with that. :-) [originally from svn r2015]
2002-10-10 12:40:05 +00:00
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
static tree234 *ptyfds = NULL;
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
/*
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
* We also have a tree of Pty structures themselves, sorted by child
* pid, so that when we wait() in response to the signal we know which
* backend instance is the owner of the process that caused the
* signal.
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
*/
static int pty_compare_by_pid(void *av, void *bv)
{
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
Pty *a = (Pty *)av;
Pty *b = (Pty *)bv;
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
if (a->child_pid < b->child_pid)
return -1;
else if (a->child_pid > b->child_pid)
return +1;
return 0;
}
static int pty_find_by_pid(void *av, void *bv)
{
Use pid_t more consistently. Should shut up a warning from GCC 4.6, and may conceivably help on platforms where int and pid_t aren't sufficiently similar. [originally from svn r9110]
2011-03-01 23:00:32 +00:00
pid_t a = *(pid_t *)av;
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
Pty *b = (Pty *)bv;
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
if (a < b->child_pid)
return -1;
else if (a > b->child_pid)
return +1;
return 0;
}
static tree234 *ptys_by_pid = NULL;
/*
* If we are using pty_pre_init(), it will need to have already
* allocated a pty structure, which we must then return from
* pty_init() rather than allocating a new one. Here we store that
* structure between allocation and use.
*
* Note that although most of this module is entirely capable of
* handling multiple ptys in a single process, pty_pre_init() is
* fundamentally _dependent_ on there being at most one pty per
* process, so the normal static-data constraints don't apply.
*
* Likewise, since utmp is only used via pty_pre_init, it too must
* be single-instance, so we can declare utmp-related variables
* here.
*/
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static Pty *single_pty = NULL;
pterm now uses the new uxsel module, so it's one step closer to 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]
2003-03-29 18:30:14 +00:00
RJK's OS X portability patch: - initialise blank mbstate_t using memset rather than an ad-hoc initialiser. - expand the OMIT_UTMP ifdefs to enclose a load of entire functions that would generate `static function never called' warnings if left as empty shells. - couple of other fiddly things. [originally from svn r4896]
2004-11-24 11:36:08 +00:00
#ifndef OMIT_UTMP
We shouldn't fork off a utmp helper subprocess when we aren't setuid, because (a) under that circumstance we won't be writing to utmp anyway, and (b) if we aren't setuid, then we won't have created the pty at the point we fork, so even if our subprocess _could_ have written to utmp it wouldn't have done it right! Spotted by valgrind (triggering on the access beyond the end of the ttyname string in setup_utmp, clueing me in to it having been empty). [originally from svn r9309]
2011-09-19 16:38:23 +00:00
static pid_t pty_utmp_helper_pid = -1;
static int pty_utmp_helper_pipe = -1;
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
static int pty_stamped_utmp;
Use pututxline() in place of pututline(), since the former is standardised by X/Open and actually seems to be more common (NetBSD has it). Also use updwtmpx() rather than directly writing to the wtmpx file, though more for reasons of aesthetics than anything practical. [originally from svn r5678]
2005-04-25 23:28:25 +00:00
static struct utmpx utmp_entry;
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
#endif
/*
* pty_argv is a grievous hack to allow a proper argv to be passed
* through from the Unix command line. Again, it doesn't really
* make sense outside a one-pty-per-process setup.
*/
char **pty_argv;
New program 'osxlaunch', to use as an OS X bundle launcher. The big problem with making an OS X application out of a GTK program is that it won't start unless DYLD_LIBRARY_PATH and several other environment variables point at all the GTK machinery. So your app bundle has to contain two programs: a launcher to set up that environment, and then the real main program that the launcher execs once it's done so. But in our case, we also need pterm to start subprocesses _without_ all that stuff in the environment - so our launcher has to be more complicated than the usual one, because it's also got to save every detail of how the environment was when it started up. So this is the launcher program I'm going to use. Comments in the header explain in more detail how it'll work. Also in this commit, I add the other end of the same machinery to gtkapp.c and uxpty.c: the former catches an extra command-line argument that the launcher used to indicate how it had munged the environment, and stores it in a global variable where the latter can pick it up after fork() and use to actually undo the munging.
2016-03-23 22:13:30 +00:00
char *pty_osx_envrestore_prefix;
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static void pty_close(Pty *pty);
static void pty_try_write(Pty *pty);
RJK's OS X portability patch: - initialise blank mbstate_t using memset rather than an ad-hoc initialiser. - expand the OMIT_UTMP ifdefs to enclose a load of entire functions that would generate `static function never called' warnings if left as empty shells. - couple of other fiddly things. [originally from svn r4896]
2004-11-24 11:36:08 +00:00
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
#ifndef OMIT_UTMP
Fix utmp and pty handling so that GTK never complains about running set[ug]id. All privs-requiring pty operations are done at the very start of the run, then privs are dropped before initialising GTK. Utmp is handled by forking a still-privileged subprocess at this point, and later asking it (through a pipe) to stamp utmp. The subprocess cleans up utmp on exit, which has the additional advantage that if the main pterm process suffers some sort of unexpected termination (up to and including SIGKILL) the subprocess can still mop up utmp. [originally from svn r2082]
2002-10-16 12:17:51 +00:00
static void setup_utmp(char *ttyname, char *location)
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
{
#ifdef HAVE_LASTLOG
struct lastlog lastlog_entry;
FILE *lastlog;
#endif
struct passwd *pw;
Use pututxline() in place of pututline(), since the former is standardised by X/Open and actually seems to be more common (NetBSD has it). Also use updwtmpx() rather than directly writing to the wtmpx file, though more for reasons of aesthetics than anything practical. [originally from svn r5678]
2005-04-25 23:28:25 +00:00
struct timeval tv;
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
pw = getpwuid(getuid());
memset(&utmp_entry, 0, sizeof(utmp_entry));
utmp_entry.ut_type = USER_PROCESS;
utmp_entry.ut_pid = getpid();
Suppress strncpy truncation warnings with GCC 8 and later. These warnings are bogus as the code is correct so we suppress them in the places they occur.
2018-09-26 13:20:25 +00:00
#if __GNUC__ >= 8
# pragma GCC diagnostic push
# pragma GCC diagnostic ignored "-Wstringop-truncation"
#endif // __GNUC__ >= 8
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
strncpy(utmp_entry.ut_line, ttyname+5, lenof(utmp_entry.ut_line));
strncpy(utmp_entry.ut_id, ttyname+8, lenof(utmp_entry.ut_id));
strncpy(utmp_entry.ut_user, pw->pw_name, lenof(utmp_entry.ut_user));
strncpy(utmp_entry.ut_host, location, lenof(utmp_entry.ut_host));
Suppress strncpy truncation warnings with GCC 8 and later. These warnings are bogus as the code is correct so we suppress them in the places they occur.
2018-09-26 13:20:25 +00:00
#if __GNUC__ >= 8
# pragma GCC diagnostic pop
#endif // __GNUC__ >= 8
Use pututxline() in place of pututline(), since the former is standardised by X/Open and actually seems to be more common (NetBSD has it). Also use updwtmpx() rather than directly writing to the wtmpx file, though more for reasons of aesthetics than anything practical. [originally from svn r5678]
2005-04-25 23:28:25 +00:00
/*
* Apparently there are some architectures where (struct
* utmpx).ut_tv is not essentially struct timeval (e.g. Linux
* amd64). Hence the temporary.
*/
gettimeofday(&tv, NULL);
utmp_entry.ut_tv.tv_sec = tv.tv_sec;
utmp_entry.ut_tv.tv_usec = tv.tv_usec;
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
Use pututxline() in place of pututline(), since the former is standardised by X/Open and actually seems to be more common (NetBSD has it). Also use updwtmpx() rather than directly writing to the wtmpx file, though more for reasons of aesthetics than anything practical. [originally from svn r5678]
2005-04-25 23:28:25 +00:00
setutxent();
pututxline(&utmp_entry);
endutxent();
updwtmpx(WTMPX_FILE, &utmp_entry);
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
#ifdef HAVE_LASTLOG
memset(&lastlog_entry, 0, sizeof(lastlog_entry));
strncpy(lastlog_entry.ll_line, ttyname+5, lenof(lastlog_entry.ll_line));
strncpy(lastlog_entry.ll_host, location, lenof(lastlog_entry.ll_host));
time(&lastlog_entry.ll_time);
if ((lastlog = fopen(LASTLOG_FILE, "r+")) != NULL) {
fseek(lastlog, sizeof(lastlog_entry) * getuid(), SEEK_SET);
fwrite(&lastlog_entry, 1, sizeof(lastlog_entry), lastlog);
fclose(lastlog);
}
#endif
Finish up utmp processing: add the -ut- command-line option to suppress stamping it at all. (I suppose this ought to be part of the cfg structure really.) [originally from svn r2059]
2002-10-15 12:42:58 +00:00
pty_stamped_utmp = 1;
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
}
static void cleanup_utmp(void)
{
Use pututxline() in place of pututline(), since the former is standardised by X/Open and actually seems to be more common (NetBSD has it). Also use updwtmpx() rather than directly writing to the wtmpx file, though more for reasons of aesthetics than anything practical. [originally from svn r5678]
2005-04-25 23:28:25 +00:00
struct timeval tv;
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
Fix utmp and pty handling so that GTK never complains about running set[ug]id. All privs-requiring pty operations are done at the very start of the run, then privs are dropped before initialising GTK. Utmp is handled by forking a still-privileged subprocess at this point, and later asking it (through a pipe) to stamp utmp. The subprocess cleans up utmp on exit, which has the additional advantage that if the main pterm process suffers some sort of unexpected termination (up to and including SIGKILL) the subprocess can still mop up utmp. [originally from svn r2082]
2002-10-16 12:17:51 +00:00
if (!pty_stamped_utmp)
Finish up utmp processing: add the -ut- command-line option to suppress stamping it at all. (I suppose this ought to be part of the cfg structure really.) [originally from svn r2059]
2002-10-15 12:42:58 +00:00
return;
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
utmp_entry.ut_type = DEAD_PROCESS;
memset(utmp_entry.ut_user, 0, lenof(utmp_entry.ut_user));
Use pututxline() in place of pututline(), since the former is standardised by X/Open and actually seems to be more common (NetBSD has it). Also use updwtmpx() rather than directly writing to the wtmpx file, though more for reasons of aesthetics than anything practical. [originally from svn r5678]
2005-04-25 23:28:25 +00:00
gettimeofday(&tv, NULL);
utmp_entry.ut_tv.tv_sec = tv.tv_sec;
utmp_entry.ut_tv.tv_usec = tv.tv_usec;
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
Use pututxline() in place of pututline(), since the former is standardised by X/Open and actually seems to be more common (NetBSD has it). Also use updwtmpx() rather than directly writing to the wtmpx file, though more for reasons of aesthetics than anything practical. [originally from svn r5678]
2005-04-25 23:28:25 +00:00
updwtmpx(WTMPX_FILE, &utmp_entry);
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
memset(utmp_entry.ut_line, 0, lenof(utmp_entry.ut_line));
Use pututxline() in place of pututline(), since the former is standardised by X/Open and actually seems to be more common (NetBSD has it). Also use updwtmpx() rather than directly writing to the wtmpx file, though more for reasons of aesthetics than anything practical. [originally from svn r5678]
2005-04-25 23:28:25 +00:00
utmp_entry.ut_tv.tv_sec = 0;
utmp_entry.ut_tv.tv_usec = 0;
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
Use pututxline() in place of pututline(), since the former is standardised by X/Open and actually seems to be more common (NetBSD has it). Also use updwtmpx() rather than directly writing to the wtmpx file, though more for reasons of aesthetics than anything practical. [originally from svn r5678]
2005-04-25 23:28:25 +00:00
setutxent();
pututxline(&utmp_entry);
endutxent();
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
Finish up utmp processing: add the -ut- command-line option to suppress stamping it at all. (I suppose this ought to be part of the cfg structure really.) [originally from svn r2059]
2002-10-15 12:42:58 +00:00
pty_stamped_utmp = 0; /* ensure we never double-cleanup */
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
}
RJK's OS X portability patch: - initialise blank mbstate_t using memset rather than an ad-hoc initialiser. - expand the OMIT_UTMP ifdefs to enclose a load of entire functions that would generate `static function never called' warnings if left as empty shells. - couple of other fiddly things. [originally from svn r4896]
2004-11-24 11:36:08 +00:00
#endif
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
xterm-class programs should exit when their primary child process dies, rather than waiting around until the last open handle on the pty closes. [originally from svn r2044]
2002-10-14 09:18:34 +00:00
static void sigchld_handler(int signum)
{
Workarounds for compiling with -D_FORTIFY_SOURCE=2 (as Ubuntu does), which doesn't like you to ignore the return value from read()/write()/etc (and apparently can't be shut up with a cast to void). [originally from svn r8614]
2009-08-07 00:19:04 +00:00
if (write(pty_signal_pipe[1], "x", 1) <= 0)
/* not much we can do about it */;
xterm-class programs should exit when their primary child process dies, rather than waiting around until the last open handle on the pty closes. [originally from svn r2044]
2002-10-14 09:18:34 +00:00
}
Reinstate the SIGCHLD handler in ptermapp. Detecting that the child process in a pterm has terminated is important for _any_ kind of pterm, so it's a mistake to put the signal handler setup _solely_ inside the optional pty_pre_init function which does the privileged setup and forks off a utmp watchdog process. Now the signal handler is installed even in the GtkApplication-based multi-window front end to pterm, meaning it will exist even on OS X.
2017-11-25 21:49:31 +00:00
static void pty_setup_sigchld_handler(void)
{
static int setup = FALSE;
if (!setup) {
putty_signal(SIGCHLD, sigchld_handler);
setup = TRUE;
}
}
xterm-class programs should exit when their primary child process dies, rather than waiting around until the last open handle on the pty closes. [originally from svn r2044]
2002-10-14 09:18:34 +00:00
RJK's OS X portability patch: - initialise blank mbstate_t using memset rather than an ad-hoc initialiser. - expand the OMIT_UTMP ifdefs to enclose a load of entire functions that would generate `static function never called' warnings if left as empty shells. - couple of other fiddly things. [originally from svn r4896]
2004-11-24 11:36:08 +00:00
#ifndef OMIT_UTMP
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
static void fatal_sig_handler(int signum)
{
RJK's general signal-handling robustness patch. Should fix the weird spin behaviour occasionally seen after pterm's child process dies. [originally from svn r2181]
2002-11-02 14:35:57 +00:00
putty_signal(signum, SIG_DFL);
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
cleanup_utmp();
raise(signum);
}
RJK's OS X portability patch: - initialise blank mbstate_t using memset rather than an ad-hoc initialiser. - expand the OMIT_UTMP ifdefs to enclose a load of entire functions that would generate `static function never called' warnings if left as empty shells. - couple of other fiddly things. [originally from svn r4896]
2004-11-24 11:36:08 +00:00
#endif
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static int pty_open_slave(Pty *pty)
When allocating BSD-style ptys, we should not be satisfied with a /dev/ptyXX we can open: we must also check that we can open and use the corresponding /dev/ttyXX, because if it's been left in the wrong mode then we will look terribly silly when we fork and _then_ discover our pty is unusable. [originally from svn r5257]
2005-02-05 15:33:36 +00:00
{
I've just discovered that using the saved sessions menu from Unix PuTTY causes the child process to inherit a lot of socket fds from its parent, which is a pain if one of them then ends up holding open a listening socket which the parent was using for port forwarding after the parent itself is dead. Therefore, this checkin sprinkles FD_CLOEXEC throughout the Unix platform directory wherever there looks like being a long-lived fd. [originally from svn r6917]
2006-11-23 14:32:11 +00:00
if (pty->slave_fd < 0) {
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
pty->slave_fd = open(pty->name, O_RDWR);
Set FD_CLOEXEC in a little convenience function that does the right thing with F_GETFD and F_SETFD. [originally from svn r6978]
2006-12-09 15:44:31 +00:00
cloexec(pty->slave_fd);
I've just discovered that using the saved sessions menu from Unix PuTTY causes the child process to inherit a lot of socket fds from its parent, which is a pain if one of them then ends up holding open a listening socket which the parent was using for port forwarding after the parent itself is dead. Therefore, this checkin sprinkles FD_CLOEXEC throughout the Unix platform directory wherever there looks like being a long-lived fd. [originally from svn r6917]
2006-11-23 14:32:11 +00:00
}
When allocating BSD-style ptys, we should not be satisfied with a /dev/ptyXX we can open: we must also check that we can open and use the corresponding /dev/ttyXX, because if it's been left in the wrong mode then we will look terribly silly when we fork and _then_ discover our pty is unusable. [originally from svn r5257]
2005-02-05 15:33:36 +00:00
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
return pty->slave_fd;
When allocating BSD-style ptys, we should not be satisfied with a /dev/ptyXX we can open: we must also check that we can open and use the corresponding /dev/ttyXX, because if it's been left in the wrong mode then we will look terribly silly when we fork and _then_ discover our pty is unusable. [originally from svn r5257]
2005-02-05 15:33:36 +00:00
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static void pty_open_master(Pty *pty)
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
{
Support for BSD-style pty devices. Tested under Linux; might need minor tweaks to run under other BSD-style OSes. [originally from svn r2056]
2002-10-15 10:49:38 +00:00
#ifdef BSD_PTYS
Fix utmp and pty handling so that GTK never complains about running set[ug]id. All privs-requiring pty operations are done at the very start of the run, then privs are dropped before initialising GTK. Utmp is handled by forking a still-privileged subprocess at this point, and later asking it (through a pipe) to stamp utmp. The subprocess cleans up utmp on exit, which has the additional advantage that if the main pterm process suffers some sort of unexpected termination (up to and including SIGKILL) the subprocess can still mop up utmp. [originally from svn r2082]
2002-10-16 12:17:51 +00:00
const char chars1[] = "pqrstuvwxyz";
const char chars2[] = "0123456789abcdef";
const char *p1, *p2;
char master_name[20];
struct group *gp;
for (p1 = chars1; *p1; p1++)
for (p2 = chars2; *p2; p2++) {
sprintf(master_name, "/dev/pty%c%c", *p1, *p2);
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
pty->master_fd = open(master_name, O_RDWR);
if (pty->master_fd >= 0) {
Fix utmp and pty handling so that GTK never complains about running set[ug]id. All privs-requiring pty operations are done at the very start of the run, then privs are dropped before initialising GTK. Utmp is handled by forking a still-privileged subprocess at this point, and later asking it (through a pipe) to stamp utmp. The subprocess cleans up utmp on exit, which has the additional advantage that if the main pterm process suffers some sort of unexpected termination (up to and including SIGKILL) the subprocess can still mop up utmp. [originally from svn r2082]
2002-10-16 12:17:51 +00:00
if (geteuid() == 0 ||
When allocating BSD-style ptys, we should not be satisfied with a /dev/ptyXX we can open: we must also check that we can open and use the corresponding /dev/ttyXX, because if it's been left in the wrong mode then we will look terribly silly when we fork and _then_ discover our pty is unusable. [originally from svn r5257]
2005-02-05 15:33:36 +00:00
access(master_name, R_OK | W_OK) == 0) {
/*
* We must also check at this point that we are
* able to open the slave side of the pty. We
* wouldn't want to allocate the wrong master,
* get all the way down to forking, and _then_
* find we're unable to open the slave.
*/
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
strcpy(pty->name, master_name);
pty->name[5] = 't'; /* /dev/ptyXX -> /dev/ttyXX */
When allocating BSD-style ptys, we should not be satisfied with a /dev/ptyXX we can open: we must also check that we can open and use the corresponding /dev/ttyXX, because if it's been left in the wrong mode then we will look terribly silly when we fork and _then_ discover our pty is unusable. [originally from svn r5257]
2005-02-05 15:33:36 +00:00
Set FD_CLOEXEC in a little convenience function that does the right thing with F_GETFD and F_SETFD. [originally from svn r6978]
2006-12-09 15:44:31 +00:00
cloexec(pty->master_fd);
I've just discovered that using the saved sessions menu from Unix PuTTY causes the child process to inherit a lot of socket fds from its parent, which is a pain if one of them then ends up holding open a listening socket which the parent was using for port forwarding after the parent itself is dead. Therefore, this checkin sprinkles FD_CLOEXEC throughout the Unix platform directory wherever there looks like being a long-lived fd. [originally from svn r6917]
2006-11-23 14:32:11 +00:00
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
if (pty_open_slave(pty) >= 0 &&
access(pty->name, R_OK | W_OK) == 0)
When allocating BSD-style ptys, we should not be satisfied with a /dev/ptyXX we can open: we must also check that we can open and use the corresponding /dev/ttyXX, because if it's been left in the wrong mode then we will look terribly silly when we fork and _then_ discover our pty is unusable. [originally from svn r5257]
2005-02-05 15:33:36 +00:00
goto got_one;
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
if (pty->slave_fd > 0)
close(pty->slave_fd);
pty->slave_fd = -1;
When allocating BSD-style ptys, we should not be satisfied with a /dev/ptyXX we can open: we must also check that we can open and use the corresponding /dev/ttyXX, because if it's been left in the wrong mode then we will look terribly silly when we fork and _then_ discover our pty is unusable. [originally from svn r5257]
2005-02-05 15:33:36 +00:00
}
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
close(pty->master_fd);
Support for BSD-style pty devices. Tested under Linux; might need minor tweaks to run under other BSD-style OSes. [originally from svn r2056]
2002-10-15 10:49:38 +00:00
}
Fix utmp and pty handling so that GTK never complains about running set[ug]id. All privs-requiring pty operations are done at the very start of the run, then privs are dropped before initialising GTK. Utmp is handled by forking a still-privileged subprocess at this point, and later asking it (through a pipe) to stamp utmp. The subprocess cleans up utmp on exit, which has the additional advantage that if the main pterm process suffers some sort of unexpected termination (up to and including SIGKILL) the subprocess can still mop up utmp. [originally from svn r2082]
2002-10-16 12:17:51 +00:00
}
Support for BSD-style pty devices. Tested under Linux; might need minor tweaks to run under other BSD-style OSes. [originally from svn r2056]
2002-10-15 10:49:38 +00:00
Fix utmp and pty handling so that GTK never complains about running set[ug]id. All privs-requiring pty operations are done at the very start of the run, then privs are dropped before initialising GTK. Utmp is handled by forking a still-privileged subprocess at this point, and later asking it (through a pipe) to stamp utmp. The subprocess cleans up utmp on exit, which has the additional advantage that if the main pterm process suffers some sort of unexpected termination (up to and including SIGKILL) the subprocess can still mop up utmp. [originally from svn r2082]
2002-10-16 12:17:51 +00:00
/* If we get here, we couldn't get a tty at all. */
fprintf(stderr, "pterm: unable to open a pseudo-terminal device\n");
exit(1);
Support for BSD-style pty devices. Tested under Linux; might need minor tweaks to run under other BSD-style OSes. [originally from svn r2056]
2002-10-15 10:49:38 +00:00
Fix utmp and pty handling so that GTK never complains about running set[ug]id. All privs-requiring pty operations are done at the very start of the run, then privs are dropped before initialising GTK. Utmp is handled by forking a still-privileged subprocess at this point, and later asking it (through a pipe) to stamp utmp. The subprocess cleans up utmp on exit, which has the additional advantage that if the main pterm process suffers some sort of unexpected termination (up to and including SIGKILL) the subprocess can still mop up utmp. [originally from svn r2082]
2002-10-16 12:17:51 +00:00
got_one:
/* We need to chown/chmod the /dev/ttyXX device. */
gp = getgrnam("tty");
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
chown(pty->name, getuid(), gp ? gp->gr_gid : -1);
chmod(pty->name, 0600);
Support for BSD-style pty devices. Tested under Linux; might need minor tweaks to run under other BSD-style OSes. [originally from svn r2056]
2002-10-15 10:49:38 +00:00
#else
Use O_NOCTTY (if available) when opening /dev/ptmx, just in case any OS doesn't automatically assume it. (It would seem faintly weird to me - surely opening the master end of a given pty is a fairly good indication that you're _not_ a process running inside it which wants to have it available as /dev/tty! But you never know...) [originally from svn r9727]
2012-12-18 09:02:38 +00:00
const int flags = O_RDWR
#ifdef O_NOCTTY
| O_NOCTTY
#endif
;
Patch from Brad Smith to use posix_openpt() instead of open("/dev/ptmx"), where the former is available. Improves portability, since at least one OS (OpenBSD) supports the POSIX pty functions but does it via an underlying mechanism which doesn't involving having a /dev/ptmx. [originally from svn r9728]
2012-12-18 09:02:38 +00:00
#ifdef HAVE_POSIX_OPENPT
Add a bodge to make pty masters nonblocking on OS X. OS X for some reason doesn't let my usual fcntl approach (wrapped in nonblock()) work on pty masters - the fcntl(F_SETFL) fails, with the (in this context) hilariously inappropriate error code ENOTTY. Work around it by instead passing O_NONBLOCK to posix_openpt.
2015-08-31 12:00:19 +00:00
#ifdef SET_NONBLOCK_VIA_OPENPT
/*
* OS X, as of 10.10 at least, doesn't permit me to set O_NONBLOCK
* on pty master fds via the usual fcntl mechanism. Fortunately,
* it does let me work around this by adding O_NONBLOCK to the
* posix_openpt flags parameter, which isn't a documented use of
* the API but seems to work. So we'll do that for now.
*/
pty->master_fd = posix_openpt(flags | O_NONBLOCK);
#else
Patch from Brad Smith to use posix_openpt() instead of open("/dev/ptmx"), where the former is available. Improves portability, since at least one OS (OpenBSD) supports the POSIX pty functions but does it via an underlying mechanism which doesn't involving having a /dev/ptmx. [originally from svn r9728]
2012-12-18 09:02:38 +00:00
pty->master_fd = posix_openpt(flags);
Add a bodge to make pty masters nonblocking on OS X. OS X for some reason doesn't let my usual fcntl approach (wrapped in nonblock()) work on pty masters - the fcntl(F_SETFL) fails, with the (in this context) hilariously inappropriate error code ENOTTY. Work around it by instead passing O_NONBLOCK to posix_openpt.
2015-08-31 12:00:19 +00:00
#endif
Patch from Brad Smith to use posix_openpt() instead of open("/dev/ptmx"), where the former is available. Improves portability, since at least one OS (OpenBSD) supports the POSIX pty functions but does it via an underlying mechanism which doesn't involving having a /dev/ptmx. [originally from svn r9728]
2012-12-18 09:02:38 +00:00
if (pty->master_fd < 0) {
perror("posix_openpt");
exit(1);
}
#else
Use O_NOCTTY (if available) when opening /dev/ptmx, just in case any OS doesn't automatically assume it. (It would seem faintly weird to me - surely opening the master end of a given pty is a fairly good indication that you're _not_ a process running inside it which wants to have it available as /dev/tty! But you never know...) [originally from svn r9727]
2012-12-18 09:02:38 +00:00
pty->master_fd = open("/dev/ptmx", flags);
And that's it! pty.c is now a real pty backend rather than a loopback interface; pterm now runs $SHELL and gives every impression of being not a bad terminal emulator. I'm quite pleased with that. :-) [originally from svn r2015]
2002-10-10 12:40:05 +00:00
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
if (pty->master_fd < 0) {
And that's it! pty.c is now a real pty backend rather than a loopback interface; pterm now runs $SHELL and gives every impression of being not a bad terminal emulator. I'm quite pleased with that. :-) [originally from svn r2015]
2002-10-10 12:40:05 +00:00
perror("/dev/ptmx: open");
exit(1);
}
Patch from Brad Smith to use posix_openpt() instead of open("/dev/ptmx"), where the former is available. Improves portability, since at least one OS (OpenBSD) supports the POSIX pty functions but does it via an underlying mechanism which doesn't involving having a /dev/ptmx. [originally from svn r9728]
2012-12-18 09:02:38 +00:00
#endif
And that's it! pty.c is now a real pty backend rather than a loopback interface; pterm now runs $SHELL and gives every impression of being not a bad terminal emulator. I'm quite pleased with that. :-) [originally from svn r2015]
2002-10-10 12:40:05 +00:00
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
if (grantpt(pty->master_fd) < 0) {
And that's it! pty.c is now a real pty backend rather than a loopback interface; pterm now runs $SHELL and gives every impression of being not a bad terminal emulator. I'm quite pleased with that. :-) [originally from svn r2015]
2002-10-10 12:40:05 +00:00
perror("grantpt");
exit(1);
}
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
if (unlockpt(pty->master_fd) < 0) {
And that's it! pty.c is now a real pty backend rather than a loopback interface; pterm now runs $SHELL and gives every impression of being not a bad terminal emulator. I'm quite pleased with that. :-) [originally from svn r2015]
2002-10-10 12:40:05 +00:00
perror("unlockpt");
exit(1);
}
Set FD_CLOEXEC in a little convenience function that does the right thing with F_GETFD and F_SETFD. [originally from svn r6978]
2006-12-09 15:44:31 +00:00
cloexec(pty->master_fd);
I've just discovered that using the saved sessions menu from Unix PuTTY causes the child process to inherit a lot of socket fds from its parent, which is a pain if one of them then ends up holding open a listening socket which the parent was using for port forwarding after the parent itself is dead. Therefore, this checkin sprinkles FD_CLOEXEC throughout the Unix platform directory wherever there looks like being a long-lived fd. [originally from svn r6917]
2006-11-23 14:32:11 +00:00
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
pty->name[FILENAME_MAX-1] = '\0';
strncpy(pty->name, ptsname(pty->master_fd), FILENAME_MAX-1);
Support for BSD-style pty devices. Tested under Linux; might need minor tweaks to run under other BSD-style OSes. [originally from svn r2056]
2002-10-15 10:49:38 +00:00
#endif
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
Add a bodge to make pty masters nonblocking on OS X. OS X for some reason doesn't let my usual fcntl approach (wrapped in nonblock()) work on pty masters - the fcntl(F_SETFL) fails, with the (in this context) hilariously inappropriate error code ENOTTY. Work around it by instead passing O_NONBLOCK to posix_openpt.
2015-08-31 12:00:19 +00:00
#ifndef SET_NONBLOCK_VIA_OPENPT
Centralise calls to fcntl into functions that carefully check the error returns. [originally from svn r9940]
2013-07-19 18:10:02 +00:00
nonblock(pty->master_fd);
Add a bodge to make pty masters nonblocking on OS X. OS X for some reason doesn't let my usual fcntl approach (wrapped in nonblock()) work on pty masters - the fcntl(F_SETFL) fails, with the (in this context) hilariously inappropriate error code ENOTTY. Work around it by instead passing O_NONBLOCK to posix_openpt.
2015-08-31 12:00:19 +00:00
#endif
Fix utmp and pty handling so that GTK never complains about running set[ug]id. All privs-requiring pty operations are done at the very start of the run, then privs are dropped before initialising GTK. Utmp is handled by forking a still-privileged subprocess at this point, and later asking it (through a pipe) to stamp utmp. The subprocess cleans up utmp on exit, which has the additional advantage that if the main pterm process suffers some sort of unexpected termination (up to and including SIGKILL) the subprocess can still mop up utmp. [originally from svn r2082]
2002-10-16 12:17:51 +00:00
}
And that's it! pty.c is now a real pty backend rather than a loopback interface; pterm now runs $SHELL and gives every impression of being not a bad terminal emulator. I'm quite pleased with that. :-) [originally from svn r2015]
2002-10-10 12:40:05 +00:00
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static Pty *new_pty_struct(void)
Fix an uninitialised bufchain in NO_PTY_PRE_INIT mode. The Pty that we created in pty_pre_init had its bufchain properly initialised, but if that one didn't get created, then the one we create in pty_init did not. Now both should go through the same init routine.
2015-08-31 15:11:37 +00:00
{
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
Pty *pty = snew(Pty);
Fix an uninitialised bufchain in NO_PTY_PRE_INIT mode. The Pty that we created in pty_pre_init had its bufchain properly initialised, but if that one didn't get created, then the one we create in pty_init did not. Now both should go through the same init routine.
2015-08-31 15:11:37 +00:00
pty->conf = NULL;
bufchain_init(&pty->output_data);
return pty;
}
Fix utmp and pty handling so that GTK never complains about running set[ug]id. All privs-requiring pty operations are done at the very start of the run, then privs are dropped before initialising GTK. Utmp is handled by forking a still-privileged subprocess at this point, and later asking it (through a pipe) to stamp utmp. The subprocess cleans up utmp on exit, which has the additional advantage that if the main pterm process suffers some sort of unexpected termination (up to and including SIGKILL) the subprocess can still mop up utmp. [originally from svn r2082]
2002-10-16 12:17:51 +00:00
/*
* Pre-initialisation. This is here to get around the fact that GTK
* doesn't like being run in setuid/setgid programs (probably
* sensibly). So before we initialise GTK - and therefore before we
* even process the command line - we check to see if we're running
* set[ug]id. If so, we open our pty master _now_, chown it as
* necessary, and drop privileges. We can always close it again
* later. If we're potentially going to be doing utmp as well, we
* also fork off a utmp helper process and communicate with it by
* means of a pipe; the utmp helper will keep privileges in order
* to clean up utmp when we exit (i.e. when its end of our pipe
* closes).
*/
void pty_pre_init(void)
{
Add a new #define to disable pty_pre_init. OS X dislikes us calling the setuid or setgid syscalls when not privileged, even if we try to set ourselves to the _same_ uid/gid. Since I don't anticipate this code needing to run setuid on OS X, and since I do anticipate wanting to handle multiple ptys in a single process so that pty_pre_init would be useless anyway, the simplest fix seems to me to be just conditioning out the whole of pty_pre_init completely.
2015-08-31 11:51:25 +00:00
#ifndef NO_PTY_PRE_INIT
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
Pty *pty;
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
RJK's OS X portability patch: - initialise blank mbstate_t using memset rather than an ad-hoc initialiser. - expand the OMIT_UTMP ifdefs to enclose a load of entire functions that would generate `static function never called' warnings if left as empty shells. - couple of other fiddly things. [originally from svn r4896]
2004-11-24 11:36:08 +00:00
#ifndef OMIT_UTMP
Fix utmp and pty handling so that GTK never complains about running set[ug]id. All privs-requiring pty operations are done at the very start of the run, then privs are dropped before initialising GTK. Utmp is handled by forking a still-privileged subprocess at this point, and later asking it (through a pipe) to stamp utmp. The subprocess cleans up utmp on exit, which has the additional advantage that if the main pterm process suffers some sort of unexpected termination (up to and including SIGKILL) the subprocess can still mop up utmp. [originally from svn r2082]
2002-10-16 12:17:51 +00:00
pid_t pid;
int pipefd[2];
RJK's OS X portability patch: - initialise blank mbstate_t using memset rather than an ad-hoc initialiser. - expand the OMIT_UTMP ifdefs to enclose a load of entire functions that would generate `static function never called' warnings if left as empty shells. - couple of other fiddly things. [originally from svn r4896]
2004-11-24 11:36:08 +00:00
#endif
Fix utmp and pty handling so that GTK never complains about running set[ug]id. All privs-requiring pty operations are done at the very start of the run, then privs are dropped before initialising GTK. Utmp is handled by forking a still-privileged subprocess at this point, and later asking it (through a pipe) to stamp utmp. The subprocess cleans up utmp on exit, which has the additional advantage that if the main pterm process suffers some sort of unexpected termination (up to and including SIGKILL) the subprocess can still mop up utmp. [originally from svn r2082]
2002-10-16 12:17:51 +00:00
Fix an uninitialised bufchain in NO_PTY_PRE_INIT mode. The Pty that we created in pty_pre_init had its bufchain properly initialised, but if that one didn't get created, then the one we create in pty_init did not. Now both should go through the same init routine.
2015-08-31 15:11:37 +00:00
pty = single_pty = new_pty_struct();
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
RJK's general signal-handling robustness patch. Should fix the weird spin behaviour occasionally seen after pterm's child process dies. [originally from svn r2181]
2002-11-02 14:35:57 +00:00
/* set the child signal handler straight away; it needs to be set
* before we ever fork. */
Reinstate the SIGCHLD handler in ptermapp. Detecting that the child process in a pterm has terminated is important for _any_ kind of pterm, so it's a mistake to put the signal handler setup _solely_ inside the optional pty_pre_init function which does the privileged setup and forks off a utmp watchdog process. Now the signal handler is installed even in the GtkApplication-based multi-window front end to pterm, meaning it will exist even on OS X.
2017-11-25 21:49:31 +00:00
pty_setup_sigchld_handler();
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
pty->master_fd = pty->slave_fd = -1;
#ifndef OMIT_UTMP
pty_stamped_utmp = FALSE;
#endif
Fix utmp and pty handling so that GTK never complains about running set[ug]id. All privs-requiring pty operations are done at the very start of the run, then privs are dropped before initialising GTK. Utmp is handled by forking a still-privileged subprocess at this point, and later asking it (through a pipe) to stamp utmp. The subprocess cleans up utmp on exit, which has the additional advantage that if the main pterm process suffers some sort of unexpected termination (up to and including SIGKILL) the subprocess can still mop up utmp. [originally from svn r2082]
2002-10-16 12:17:51 +00:00
if (geteuid() != getuid() || getegid() != getgid()) {
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
pty_open_master(pty);
Configure the pty so that it agrees with our idea of whether Backspace sends ^H or ^?. [originally from svn r2076]
2002-10-15 18:36:18 +00:00
Fix utmp and pty handling so that GTK never complains about running set[ug]id. All privs-requiring pty operations are done at the very start of the run, then privs are dropped before initialising GTK. Utmp is handled by forking a still-privileged subprocess at this point, and later asking it (through a pipe) to stamp utmp. The subprocess cleans up utmp on exit, which has the additional advantage that if the main pterm process suffers some sort of unexpected termination (up to and including SIGKILL) the subprocess can still mop up utmp. [originally from svn r2082]
2002-10-16 12:17:51 +00:00
#ifndef OMIT_UTMP
We shouldn't fork off a utmp helper subprocess when we aren't setuid, because (a) under that circumstance we won't be writing to utmp anyway, and (b) if we aren't setuid, then we won't have created the pty at the point we fork, so even if our subprocess _could_ have written to utmp it wouldn't have done it right! Spotted by valgrind (triggering on the access beyond the end of the ttyname string in setup_utmp, clueing me in to it having been empty). [originally from svn r9309]
2011-09-19 16:38:23 +00:00
/*
* Fork off the utmp helper.
*/
if (pipe(pipefd) < 0) {
perror("pterm: pipe");
exit(1);
}
cloexec(pipefd[0]);
cloexec(pipefd[1]);
pid = fork();
if (pid < 0) {
perror("pterm: fork");
exit(1);
} else if (pid == 0) {
char display[128], buffer[128];
int dlen, ret;
close(pipefd[1]);
/*
* Now sit here until we receive a display name from the
* other end of the pipe, and then stamp utmp. Unstamp utmp
* again, and exit, when the pipe closes.
*/
Fix utmp and pty handling so that GTK never complains about running set[ug]id. All privs-requiring pty operations are done at the very start of the run, then privs are dropped before initialising GTK. Utmp is handled by forking a still-privileged subprocess at this point, and later asking it (through a pipe) to stamp utmp. The subprocess cleans up utmp on exit, which has the additional advantage that if the main pterm process suffers some sort of unexpected termination (up to and including SIGKILL) the subprocess can still mop up utmp. [originally from svn r2082]
2002-10-16 12:17:51 +00:00
We shouldn't fork off a utmp helper subprocess when we aren't setuid, because (a) under that circumstance we won't be writing to utmp anyway, and (b) if we aren't setuid, then we won't have created the pty at the point we fork, so even if our subprocess _could_ have written to utmp it wouldn't have done it right! Spotted by valgrind (triggering on the access beyond the end of the ttyname string in setup_utmp, clueing me in to it having been empty). [originally from svn r9309]
2011-09-19 16:38:23 +00:00
dlen = 0;
while (1) {
Fix utmp and pty handling so that GTK never complains about running set[ug]id. All privs-requiring pty operations are done at the very start of the run, then privs are dropped before initialising GTK. Utmp is handled by forking a still-privileged subprocess at this point, and later asking it (through a pipe) to stamp utmp. The subprocess cleans up utmp on exit, which has the additional advantage that if the main pterm process suffers some sort of unexpected termination (up to and including SIGKILL) the subprocess can still mop up utmp. [originally from svn r2082]
2002-10-16 12:17:51 +00:00
We shouldn't fork off a utmp helper subprocess when we aren't setuid, because (a) under that circumstance we won't be writing to utmp anyway, and (b) if we aren't setuid, then we won't have created the pty at the point we fork, so even if our subprocess _could_ have written to utmp it wouldn't have done it right! Spotted by valgrind (triggering on the access beyond the end of the ttyname string in setup_utmp, clueing me in to it having been empty). [originally from svn r9309]
2011-09-19 16:38:23 +00:00
ret = read(pipefd[0], buffer, lenof(buffer));
if (ret <= 0) {
cleanup_utmp();
_exit(0);
} else if (!pty_stamped_utmp) {
if (dlen < lenof(display))
memcpy(display+dlen, buffer,
min(ret, lenof(display)-dlen));
if (buffer[ret-1] == '\0') {
/*
* Now we have a display name. NUL-terminate
* it, and stamp utmp.
*/
display[lenof(display)-1] = '\0';
/*
* Trap as many fatal signals as we can in the
* hope of having the best possible chance to
* clean up utmp before termination. We are
* unfortunately unprotected against SIGKILL,
* but that's life.
*/
putty_signal(SIGHUP, fatal_sig_handler);
putty_signal(SIGINT, fatal_sig_handler);
putty_signal(SIGQUIT, fatal_sig_handler);
putty_signal(SIGILL, fatal_sig_handler);
putty_signal(SIGABRT, fatal_sig_handler);
putty_signal(SIGFPE, fatal_sig_handler);
putty_signal(SIGPIPE, fatal_sig_handler);
putty_signal(SIGALRM, fatal_sig_handler);
putty_signal(SIGTERM, fatal_sig_handler);
putty_signal(SIGSEGV, fatal_sig_handler);
putty_signal(SIGUSR1, fatal_sig_handler);
putty_signal(SIGUSR2, fatal_sig_handler);
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
#ifdef SIGBUS
We shouldn't fork off a utmp helper subprocess when we aren't setuid, because (a) under that circumstance we won't be writing to utmp anyway, and (b) if we aren't setuid, then we won't have created the pty at the point we fork, so even if our subprocess _could_ have written to utmp it wouldn't have done it right! Spotted by valgrind (triggering on the access beyond the end of the ttyname string in setup_utmp, clueing me in to it having been empty). [originally from svn r9309]
2011-09-19 16:38:23 +00:00
putty_signal(SIGBUS, fatal_sig_handler);
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
#endif
#ifdef SIGPOLL
We shouldn't fork off a utmp helper subprocess when we aren't setuid, because (a) under that circumstance we won't be writing to utmp anyway, and (b) if we aren't setuid, then we won't have created the pty at the point we fork, so even if our subprocess _could_ have written to utmp it wouldn't have done it right! Spotted by valgrind (triggering on the access beyond the end of the ttyname string in setup_utmp, clueing me in to it having been empty). [originally from svn r9309]
2011-09-19 16:38:23 +00:00
putty_signal(SIGPOLL, fatal_sig_handler);
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
#endif
#ifdef SIGPROF
We shouldn't fork off a utmp helper subprocess when we aren't setuid, because (a) under that circumstance we won't be writing to utmp anyway, and (b) if we aren't setuid, then we won't have created the pty at the point we fork, so even if our subprocess _could_ have written to utmp it wouldn't have done it right! Spotted by valgrind (triggering on the access beyond the end of the ttyname string in setup_utmp, clueing me in to it having been empty). [originally from svn r9309]
2011-09-19 16:38:23 +00:00
putty_signal(SIGPROF, fatal_sig_handler);
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
#endif
#ifdef SIGSYS
We shouldn't fork off a utmp helper subprocess when we aren't setuid, because (a) under that circumstance we won't be writing to utmp anyway, and (b) if we aren't setuid, then we won't have created the pty at the point we fork, so even if our subprocess _could_ have written to utmp it wouldn't have done it right! Spotted by valgrind (triggering on the access beyond the end of the ttyname string in setup_utmp, clueing me in to it having been empty). [originally from svn r9309]
2011-09-19 16:38:23 +00:00
putty_signal(SIGSYS, fatal_sig_handler);
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
#endif
#ifdef SIGTRAP
We shouldn't fork off a utmp helper subprocess when we aren't setuid, because (a) under that circumstance we won't be writing to utmp anyway, and (b) if we aren't setuid, then we won't have created the pty at the point we fork, so even if our subprocess _could_ have written to utmp it wouldn't have done it right! Spotted by valgrind (triggering on the access beyond the end of the ttyname string in setup_utmp, clueing me in to it having been empty). [originally from svn r9309]
2011-09-19 16:38:23 +00:00
putty_signal(SIGTRAP, fatal_sig_handler);
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
#endif
#ifdef SIGVTALRM
We shouldn't fork off a utmp helper subprocess when we aren't setuid, because (a) under that circumstance we won't be writing to utmp anyway, and (b) if we aren't setuid, then we won't have created the pty at the point we fork, so even if our subprocess _could_ have written to utmp it wouldn't have done it right! Spotted by valgrind (triggering on the access beyond the end of the ttyname string in setup_utmp, clueing me in to it having been empty). [originally from svn r9309]
2011-09-19 16:38:23 +00:00
putty_signal(SIGVTALRM, fatal_sig_handler);
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
#endif
#ifdef SIGXCPU
We shouldn't fork off a utmp helper subprocess when we aren't setuid, because (a) under that circumstance we won't be writing to utmp anyway, and (b) if we aren't setuid, then we won't have created the pty at the point we fork, so even if our subprocess _could_ have written to utmp it wouldn't have done it right! Spotted by valgrind (triggering on the access beyond the end of the ttyname string in setup_utmp, clueing me in to it having been empty). [originally from svn r9309]
2011-09-19 16:38:23 +00:00
putty_signal(SIGXCPU, fatal_sig_handler);
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
#endif
#ifdef SIGXFSZ
We shouldn't fork off a utmp helper subprocess when we aren't setuid, because (a) under that circumstance we won't be writing to utmp anyway, and (b) if we aren't setuid, then we won't have created the pty at the point we fork, so even if our subprocess _could_ have written to utmp it wouldn't have done it right! Spotted by valgrind (triggering on the access beyond the end of the ttyname string in setup_utmp, clueing me in to it having been empty). [originally from svn r9309]
2011-09-19 16:38:23 +00:00
putty_signal(SIGXFSZ, fatal_sig_handler);
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
#endif
#ifdef SIGIO
We shouldn't fork off a utmp helper subprocess when we aren't setuid, because (a) under that circumstance we won't be writing to utmp anyway, and (b) if we aren't setuid, then we won't have created the pty at the point we fork, so even if our subprocess _could_ have written to utmp it wouldn't have done it right! Spotted by valgrind (triggering on the access beyond the end of the ttyname string in setup_utmp, clueing me in to it having been empty). [originally from svn r9309]
2011-09-19 16:38:23 +00:00
putty_signal(SIGIO, fatal_sig_handler);
#endif
setup_utmp(pty->name, display);
}
}
}
} else {
close(pipefd[0]);
pty_utmp_helper_pid = pid;
pty_utmp_helper_pipe = pipefd[1];
}
Fix utmp and pty handling so that GTK never complains about running set[ug]id. All privs-requiring pty operations are done at the very start of the run, then privs are dropped before initialising GTK. Utmp is handled by forking a still-privileged subprocess at this point, and later asking it (through a pipe) to stamp utmp. The subprocess cleans up utmp on exit, which has the additional advantage that if the main pterm process suffers some sort of unexpected termination (up to and including SIGKILL) the subprocess can still mop up utmp. [originally from svn r2082]
2002-10-16 12:17:51 +00:00
#endif
}
/* Drop privs. */
{
#ifndef HAVE_NO_SETRESUID
RJK's OS X portability patch: - initialise blank mbstate_t using memset rather than an ad-hoc initialiser. - expand the OMIT_UTMP ifdefs to enclose a load of entire functions that would generate `static function never called' warnings if left as empty shells. - couple of other fiddly things. [originally from svn r4896]
2004-11-24 11:36:08 +00:00
int gid = getgid(), uid = getuid();
Fix utmp and pty handling so that GTK never complains about running set[ug]id. All privs-requiring pty operations are done at the very start of the run, then privs are dropped before initialising GTK. Utmp is handled by forking a still-privileged subprocess at this point, and later asking it (through a pipe) to stamp utmp. The subprocess cleans up utmp on exit, which has the additional advantage that if the main pterm process suffers some sort of unexpected termination (up to and including SIGKILL) the subprocess can still mop up utmp. [originally from svn r2082]
2002-10-16 12:17:51 +00:00
int setresgid(gid_t, gid_t, gid_t);
int setresuid(uid_t, uid_t, uid_t);
Don't forget to check the return values of setuid and friends. [originally from svn r9764]
2013-02-23 21:00:29 +00:00
if (setresgid(gid, gid, gid) < 0) {
perror("setresgid");
exit(1);
}
if (setresuid(uid, uid, uid) < 0) {
perror("setresuid");
exit(1);
}
Fix utmp and pty handling so that GTK never complains about running set[ug]id. All privs-requiring pty operations are done at the very start of the run, then privs are dropped before initialising GTK. Utmp is handled by forking a still-privileged subprocess at this point, and later asking it (through a pipe) to stamp utmp. The subprocess cleans up utmp on exit, which has the additional advantage that if the main pterm process suffers some sort of unexpected termination (up to and including SIGKILL) the subprocess can still mop up utmp. [originally from svn r2082]
2002-10-16 12:17:51 +00:00
#else
Don't forget to check the return values of setuid and friends. [originally from svn r9764]
2013-02-23 21:00:29 +00:00
if (setgid(getgid()) < 0) {
perror("setgid");
exit(1);
}
if (setuid(getuid()) < 0) {
perror("setuid");
exit(1);
}
Fix utmp and pty handling so that GTK never complains about running set[ug]id. All privs-requiring pty operations are done at the very start of the run, then privs are dropped before initialising GTK. Utmp is handled by forking a still-privileged subprocess at this point, and later asking it (through a pipe) to stamp utmp. The subprocess cleans up utmp on exit, which has the additional advantage that if the main pterm process suffers some sort of unexpected termination (up to and including SIGKILL) the subprocess can still mop up utmp. [originally from svn r2082]
2002-10-16 12:17:51 +00:00
#endif
}
Add a new #define to disable pty_pre_init. OS X dislikes us calling the setuid or setgid syscalls when not privileged, even if we try to set ourselves to the _same_ uid/gid. Since I don't anticipate this code needing to run setuid on OS X, and since I do anticipate wanting to handle multiple ptys in a single process so that pty_pre_init would be useless anyway, the simplest fix seems to me to be just conditioning out the whole of pty_pre_init completely.
2015-08-31 11:51:25 +00:00
#endif /* NO_PTY_PRE_INIT */
Fix utmp and pty handling so that GTK never complains about running set[ug]id. All privs-requiring pty operations are done at the very start of the run, then privs are dropped before initialising GTK. Utmp is handled by forking a still-privileged subprocess at this point, and later asking it (through a pipe) to stamp utmp. The subprocess cleans up utmp on exit, which has the additional advantage that if the main pterm process suffers some sort of unexpected termination (up to and including SIGKILL) the subprocess can still mop up utmp. [originally from svn r2082]
2002-10-16 12:17:51 +00:00
}
uxpty: propagate exit code more reliably on pty EIO. There was a bit of a race condition depending on whether uxpty spotted the EOF/EIO on the process's output first, or the SIGCHLD for its actual termination: if the former came first, it would never bother to reap the exit code at all. It still doesn't bother if it's closing the session immediately and the process genuinely _hasn't_ died (say, if it detaches itself completely from the controlling tty to run in the background like a weird parody of an old DOS TSR). But now when we see EOF, we make an immediate (but nonblocking) attempt to wait for the child process, in case its exit code was already available and we just hadn't noticed yet.
2018-10-13 09:36:18 +00:00
static void pty_try_wait(void);
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
static void pty_real_select_result(Pty *pty, int fd, int event, int status)
pterm now uses the new uxsel module, so it's one step closer to 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]
2003-03-29 18:30:14 +00:00
{
char buf[4096];
int ret;
int finished = FALSE;
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
if (event < 0) {
pterm now uses the new uxsel module, so it's one step closer to 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]
2003-03-29 18:30:14 +00:00
/*
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
* We've been called because our child process did
* something. `status' tells us what.
pterm now uses the new uxsel module, so it's one step closer to 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]
2003-03-29 18:30:14 +00:00
*/
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
if ((WIFEXITED(status) || WIFSIGNALED(status))) {
pterm now uses the new uxsel module, so it's one step closer to 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]
2003-03-29 18:30:14 +00:00
/*
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
* The primary child process died.
*/
pty->child_dead = TRUE;
del234(ptys_by_pid, pty);
pty->exit_code = status;
/*
* If this is an ordinary pty session, this is also the
* moment to terminate the whole backend.
*
* We _could_ instead keep the terminal open for remaining
* subprocesses to output to, but conventional wisdom
* seems to feel that that's the Wrong Thing for an
* xterm-alike, so we bail out now (though we don't
* necessarily _close_ the window, depending on the state
* of Close On Exit). This would be easy enough to change
* or make configurable if necessary.
pterm now uses the new uxsel module, so it's one step closer to 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]
2003-03-29 18:30:14 +00:00
*/
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
if (pty->master_fd >= 0)
finished = TRUE;
pterm now uses the new uxsel module, so it's one step closer to 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]
2003-03-29 18:30:14 +00:00
}
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
} else {
if (event == 1) {
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
int is_stdout = (fd == pty->master_o);
pterm now uses the new uxsel module, so it's one step closer to 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]
2003-03-29 18:30:14 +00:00
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
ret = read(fd, buf, sizeof(buf));
pterm now uses the new uxsel module, so it's one step closer to 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]
2003-03-29 18:30:14 +00:00
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
/*
* Treat EIO on a pty master as equivalent to EOF (because
* that's how the kernel seems to report the event where
* the last process connected to the other end of the pty
* went away).
*/
if (fd == pty->master_fd && ret < 0 && errno == EIO)
ret = 0;
if (ret == 0) {
/*
* EOF on this input fd, so to begin with, we may as
* well close it, and remove all references to it in
* the pty's fd fields.
*/
uxsel_del(fd);
close(fd);
if (pty->master_fd == fd)
pty->master_fd = -1;
if (pty->master_o == fd)
pty->master_o = -1;
if (pty->master_e == fd)
pty->master_e = -1;
if (is_stdout) {
/*
* We assume a clean exit if the pty (or stdout
* pipe) has closed, but the actual child process
* hasn't. The only way I can imagine this
* happening is if it detaches itself from the pty
* and goes daemonic - in which case the expected
* usage model would precisely _not_ be for the
* pterm window to hang around!
*/
finished = TRUE;
pty_try_wait(); /* one last effort to collect exit code */
if (!pty->child_dead)
pty->exit_code = 0;
}
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
} else if (ret < 0) {
perror("read pty master");
exit(1);
} else if (ret > 0) {
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
seat_output(pty->seat, !is_stdout, buf, ret);
pterm now uses the new uxsel module, so it's one step closer to 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]
2003-03-29 18:30:14 +00:00
}
Do proper select-for-write on ptys. Currently, pasting a sufficiently large string into pterm in any circumstances in which it's echoed back to the terminal will cause a deadlock once the pty's write buffer fills up. [originally from svn r6582]
2006-02-23 13:38:44 +00:00
} else if (event == 2) {
/*
* Attempt to send data down the pty.
*/
pty_try_write(pty);
}
pterm now uses the new uxsel module, so it's one step closer to 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]
2003-03-29 18:30:14 +00:00
}
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
if (finished && !pty->finished) {
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
int close_on_exit;
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
int i;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
for (i = 0; i < 3; i++)
if (pty->fds[i].fd >= 0)
uxsel_del(pty->fds[i].fd);
pty_close(pty);
pterm now uses the new uxsel module, so it's one step closer to 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]
2003-03-29 18:30:14 +00:00
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
pty->finished = TRUE;
pterm now uses the new uxsel module, so it's one step closer to 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]
2003-03-29 18:30:14 +00:00
/*
* This is a slight layering-violation sort of hack: only
* if we're not closing on exit (COE is set to Never, or to
* Only On Clean and it wasn't a clean exit) do we output a
* `terminated' message.
*/
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
close_on_exit = conf_get_int(pty->conf, CONF_close_on_exit);
if (close_on_exit == FORCE_OFF ||
(close_on_exit == AUTO && pty->exit_code != 0)) {
pterm now uses the new uxsel module, so it's one step closer to 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]
2003-03-29 18:30:14 +00:00
char message[512];
A collection of small bug fixes from Chris West, apparently spotted by Coverity: assorted language-use goofs like freeing the wrong thing or forgetting to initialise a string on all code paths. [originally from svn r9889]
2013-07-01 17:56:33 +00:00
message[0] = '\0';
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
if (WIFEXITED(pty->exit_code))
pterm now uses the new uxsel module, so it's one step closer to 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]
2003-03-29 18:30:14 +00:00
sprintf(message, "\r\n[pterm: process terminated with exit"
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
" code %d]\r\n", WEXITSTATUS(pty->exit_code));
else if (WIFSIGNALED(pty->exit_code))
pterm now uses the new uxsel module, so it's one step closer to 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]
2003-03-29 18:30:14 +00:00
#ifdef HAVE_NO_STRSIGNAL
sprintf(message, "\r\n[pterm: process terminated on signal"
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
" %d]\r\n", WTERMSIG(pty->exit_code));
pterm now uses the new uxsel module, so it's one step closer to 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]
2003-03-29 18:30:14 +00:00
#else
sprintf(message, "\r\n[pterm: process terminated on signal"
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
" %d (%.400s)]\r\n", WTERMSIG(pty->exit_code),
strsignal(WTERMSIG(pty->exit_code)));
pterm now uses the new uxsel module, so it's one step closer to 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]
2003-03-29 18:30:14 +00:00
#endif
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
seat_stdout(pty->seat, message, strlen(message));
pterm now uses the new uxsel module, so it's one step closer to 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]
2003-03-29 18:30:14 +00:00
}
New timing infrastructure. There's a new function schedule_timer() which pretty much any module can call to request a call-back in the future. So terminal.c can do its own handling of blinking, visual bells and deferred screen updates, without having to rely on term_update() being called 50 times a second (fixes: pterm-timer); and ssh.c and telnet.c both invoke a new module pinger.c which takes care of sending keepalives, so they get sent uniformly in all front ends (fixes: plink-keepalives, unix-keepalives). [originally from svn r4906] [this svn revision also touched putty-wishlist]
2004-11-27 13:20:21 +00:00
uxpty: send seat_eof when the pty master gives EIO. The uxpty backend is going to be reused to implement the "session" channel type in the upcoming SSH server implementation, which puts quite a few new requirements on it. The first of them is that when we get EOF from the subprocess's output channel (or rather, EIO from the pty), we should actually notify the Seat of this. In principle we should have been doing this all along, I'm pretty sure. It hasn't happened to matter until now because the receiving Seats haven't done much with that notification. But it will matter when that's what controls the sending of SSH_MSG_CHANNEL_EOF.
2018-10-13 09:15:47 +00:00
seat_eof(pty->seat);
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
seat_notify_remote_exit(pty->seat);
pterm now uses the new uxsel module, so it's one step closer to 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]
2003-03-29 18:30:14 +00:00
}
}
uxpty: propagate exit code more reliably on pty EIO. There was a bit of a race condition depending on whether uxpty spotted the EOF/EIO on the process's output first, or the SIGCHLD for its actual termination: if the former came first, it would never bother to reap the exit code at all. It still doesn't bother if it's closing the session immediately and the process genuinely _hasn't_ died (say, if it detaches itself completely from the controlling tty to run in the background like a weird parody of an old DOS TSR). But now when we see EOF, we make an immediate (but nonblocking) attempt to wait for the child process, in case its exit code was already available and we just hadn't noticed yet.
2018-10-13 09:36:18 +00:00
static void pty_try_wait(void)
{
Pty *pty;
pid_t pid;
int status;
do {
pid = waitpid(-1, &status, WNOHANG);
pty = find234(ptys_by_pid, &pid, pty_find_by_pid);
if (pty)
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
pty_real_select_result(pty, -1, -1, status);
uxpty: propagate exit code more reliably on pty EIO. There was a bit of a race condition depending on whether uxpty spotted the EOF/EIO on the process's output first, or the SIGCHLD for its actual termination: if the former came first, it would never bother to reap the exit code at all. It still doesn't bother if it's closing the session immediately and the process genuinely _hasn't_ died (say, if it detaches itself completely from the controlling tty to run in the background like a weird parody of an old DOS TSR). But now when we see EOF, we make an immediate (but nonblocking) attempt to wait for the child process, in case its exit code was already available and we just hadn't noticed yet.
2018-10-13 09:36:18 +00:00
} while (pid > 0);
}
unix: make uxsel callback functions return void. Nothing used their return values anyway. At least, not after the previous commit.
2016-05-30 21:52:30 +00:00
void pty_select_result(int fd, int event)
pterm now uses the new uxsel module, so it's one step closer to 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]
2003-03-29 18:30:14 +00:00
{
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
if (fd == pty_signal_pipe[0]) {
char c[1];
Workarounds for compiling with -D_FORTIFY_SOURCE=2 (as Ubuntu does), which doesn't like you to ignore the return value from read()/write()/etc (and apparently can't be shut up with a cast to void). [originally from svn r8614]
2009-08-07 00:19:04 +00:00
if (read(pty_signal_pipe[0], c, 1) <= 0)
/* ignore error */;
/* ignore its value; it'll be `x' */
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
uxpty: propagate exit code more reliably on pty EIO. There was a bit of a race condition depending on whether uxpty spotted the EOF/EIO on the process's output first, or the SIGCHLD for its actual termination: if the former came first, it would never bother to reap the exit code at all. It still doesn't bother if it's closing the session immediately and the process genuinely _hasn't_ died (say, if it detaches itself completely from the controlling tty to run in the background like a weird parody of an old DOS TSR). But now when we see EOF, we make an immediate (but nonblocking) attempt to wait for the child process, in case its exit code was already available and we just hadn't noticed yet.
2018-10-13 09:36:18 +00:00
pty_try_wait();
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
} else {
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
PtyFd *ptyfd = find234(ptyfds, &fd, ptyfd_find);
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
if (ptyfd)
pty_real_select_result(ptyfd->pty, fd, event, 0);
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
}
}
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
static void pty_uxsel_setup_fd(Pty *pty, int fd)
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
{
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
int rwx = 0;
if (fd < 0)
return;
/* read from standard output and standard error pipes */
if (pty->master_o == fd || pty->master_e == fd)
rwx |= 1;
/* write to standard input pipe if we have any data */
if (pty->master_i == fd && bufchain_size(&pty->output_data))
rwx |= 2;
Do proper select-for-write on ptys. Currently, pasting a sufficiently large string into pterm in any circumstances in which it's echoed back to the terminal will cause a deadlock once the pty's write buffer fills up. [originally from svn r6582]
2006-02-23 13:38:44 +00:00
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
uxsel_set(fd, rwx, pty_select_result);
}
static void pty_uxsel_setup(Pty *pty)
{
/*
* We potentially have three separate fds here, but on the other
* hand, some of them might be the same (if they're a pty master).
* So we can't just call uxsel_set(master_o, 1) and then
* uxsel_set(master_i, 2), without the latter potentially undoing
* the work of the former if master_o == master_i.
*
* Instead, here we call a single uxsel on each one of these fds
* (if it exists at all), and for each one, check it against all
* three to see which bits to set.
*/
pty_uxsel_setup_fd(pty, pty->master_o);
pty_uxsel_setup_fd(pty, pty->master_e);
pty_uxsel_setup_fd(pty, pty->master_i);
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
/*
* In principle this only needs calling once for all pty
* backend instances, but it's simplest just to call it every
* time; uxsel won't mind.
*/
pterm now uses the new uxsel module, so it's one step closer to 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]
2003-03-29 18:30:14 +00:00
uxsel_set(pty_signal_pipe[0], 1, pty_select_result);
}
uxpty: give pty_backend_create a struct ssh_ttymodes. This will be applied to the pty's termios settings at creation time, superseding the default settings uxpty has always used. It works by including the new sshttymodes.h with TTYMODES_LOCAL_ONLY defined, so that modes not supported by a particular Unix system are automatically quietly ignored. Of course, a struct ssh_ttymodes always has the option of representing "please make no change to the defaults", and of course, that's precisely what is done by the one that pty_init constructs for clients that aren't calling pty_backend_create directly.
2018-10-18 19:37:33 +00:00
static void copy_ttymodes_into_termios(
struct termios *attrs, struct ssh_ttymodes modes)
{
#define TTYMODE_CHAR(name, ssh_opcode, cc_index) { \
if (modes.have_mode[ssh_opcode]) \
attrs->c_cc[cc_index] = modes.mode_val[ssh_opcode]; \
}
#define TTYMODE_FLAG(flagval, ssh_opcode, field, flagmask) { \
if (modes.have_mode[ssh_opcode]) { \
attrs->c_##field##flag &= ~flagmask; \
if (modes.mode_val[ssh_opcode]) \
attrs->c_##field##flag |= flagval; \
} \
}
#define TTYMODES_LOCAL_ONLY /* omit any that this platform doesn't know */
#include "sshttymodes.h"
#undef TTYMODES_LOCAL_ONLY
#undef TTYMODE_CHAR
#undef TTYMODE_FLAG
if (modes.have_mode[TTYMODE_ISPEED])
cfsetispeed(attrs, modes.mode_val[TTYMODE_ISPEED]);
if (modes.have_mode[TTYMODE_OSPEED])
cfsetospeed(attrs, modes.mode_val[TTYMODE_OSPEED]);
}
Fix utmp and pty handling so that GTK never complains about running set[ug]id. All privs-requiring pty operations are done at the very start of the run, then privs are dropped before initialising GTK. Utmp is handled by forking a still-privileged subprocess at this point, and later asking it (through a pipe) to stamp utmp. The subprocess cleans up utmp on exit, which has the additional advantage that if the main pterm process suffers some sort of unexpected termination (up to and including SIGKILL) the subprocess can still mop up utmp. [originally from svn r2082]
2002-10-16 12:17:51 +00:00
/*
uxpty: new specialist backend-creation API. The function that does the main pty setup is now called pty_backend_create(), and has an API better suited to uxpty in particular than the standard backend_init() virtual constructor. It leaves off a load of standard parameters to backend_init() which aren't really relevant to this backend, and it adds the 'argv' parameter to pass in a split-up command line, which is unique to it. The old creation function still exists, as a tiny wrapper that calls the new pty_backend_create. And that version still gets the argv parameter from the process-global variable pty_argv[], so the call sites in pterm haven't had to change for this. This will make it possible to instantiate a pty backend directly from the SSH server code, without having to do anything really excessively cumbersome to pass in a subcommand in the form of pre-split argv. (And I'll add a few more specialist parameters to the new function shortly.)
2018-10-13 07:32:40 +00:00
* The main setup function for the pty back end. This doesn't match
* the signature of backend_init(), partly because it has to be able
* to take extra arguments such as an argv array, and also because
* once we're changing the type signature _anyway_ we can discard the
* stuff that's not really applicable to this backend like host names
* and port numbers.
Fix utmp and pty handling so that GTK never complains about running set[ug]id. All privs-requiring pty operations are done at the very start of the run, then privs are dropped before initialising GTK. Utmp is handled by forking a still-privileged subprocess at this point, and later asking it (through a pipe) to stamp utmp. The subprocess cleans up utmp on exit, which has the additional advantage that if the main pterm process suffers some sort of unexpected termination (up to and including SIGKILL) the subprocess can still mop up utmp. [originally from svn r2082]
2002-10-16 12:17:51 +00:00
*/
uxpty: new specialist backend-creation API. The function that does the main pty setup is now called pty_backend_create(), and has an API better suited to uxpty in particular than the standard backend_init() virtual constructor. It leaves off a load of standard parameters to backend_init() which aren't really relevant to this backend, and it adds the 'argv' parameter to pass in a split-up command line, which is unique to it. The old creation function still exists, as a tiny wrapper that calls the new pty_backend_create. And that version still gets the argv parameter from the process-global variable pty_argv[], so the call sites in pterm haven't had to change for this. This will make it possible to instantiate a pty backend directly from the SSH server code, without having to do anything really excessively cumbersome to pass in a subcommand in the form of pre-split argv. (And I'll add a few more specialist parameters to the new function shortly.)
2018-10-13 07:32:40 +00:00
Backend *pty_backend_create(
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
Seat *seat, LogContext *logctx, Conf *conf, char **argv, const char *cmd,
struct ssh_ttymodes ttymodes, int pipes_instead)
Fix utmp and pty handling so that GTK never complains about running set[ug]id. All privs-requiring pty operations are done at the very start of the run, then privs are dropped before initialising GTK. Utmp is handled by forking a still-privileged subprocess at this point, and later asking it (through a pipe) to stamp utmp. The subprocess cleans up utmp on exit, which has the additional advantage that if the main pterm process suffers some sort of unexpected termination (up to and including SIGKILL) the subprocess can still mop up utmp. [originally from svn r2082]
2002-10-16 12:17:51 +00:00
{
int slavefd;
pid_t pid, pgrp;
The pty backend won't _always_ be running under X, so it should be possible to compile it without the WINDOWID variable. [originally from svn r5259]
2005-02-06 13:33:41 +00:00
#ifndef NOT_X_WINDOWS /* for Mac OS X native compilation */
Basic support for running under GDK Wayland back end. GTK 3 PuTTY/pterm has always assumed that if it was compiled with _support_ for talking to the raw X11 layer underneath GTK and GDK, then it was entitled to expect that raw X11 layer to exist at all times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X display that it could do useful things with. So if you ran it over the GDK Wayland backend, it would immediately segfault. Modern GTK applications need to cope with multiple GDK backends at run time. It's fine for GTK PuTTY to _contain_ the code to find and use underlying X11 primitives like the display and the X window id, but it should be prepared to find that it's running on Wayland (or something else again!) so those functions don't return anything useful - in which case it should degrade gracefully to the subset of functionality that can be accessed through backend-independent GTK calls. Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a support function get_x_display() in gtkmisc.c, which starts by checking that there actually is one first. All previous direct uses of GDK_*_XDISPLAY now go via that function, and check the result for NULL afterwards. (To save faffing about calling that function too many times, I'm also caching the display pointer in more places, and passing it as an extra argument to various subfunctions, mostly in gtkfont.c.) Similarly, the get_windowid() function that retrieves the window id to put in the environment of pterm's child process has to be prepared for there not to be a window id. This isn't a complete fix for all Wayland-related problems. The other one I'm currently aware of is that the default font is "server:fixed", which is a bad default now that it won't be available on all backends. And I expect that further problems will show up with more testing. But it's a start.
2018-05-09 08:18:20 +00:00
int got_windowid;
Richard B's patch to add WINDOWID support to pterm. [originally from svn r2912]
2003-03-06 12:57:37 +00:00
long windowid;
The pty backend won't _always_ be running under X, so it should be possible to compile it without the WINDOWID variable. [originally from svn r5259]
2005-02-06 13:33:41 +00:00
#endif
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
Pty *pty;
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
int i;
Fix utmp and pty handling so that GTK never complains about running set[ug]id. All privs-requiring pty operations are done at the very start of the run, then privs are dropped before initialising GTK. Utmp is handled by forking a still-privileged subprocess at this point, and later asking it (through a pipe) to stamp utmp. The subprocess cleans up utmp on exit, which has the additional advantage that if the main pterm process suffers some sort of unexpected termination (up to and including SIGKILL) the subprocess can still mop up utmp. [originally from svn r2082]
2002-10-16 12:17:51 +00:00
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
if (single_pty) {
pty = single_pty;
Fix a pty-freeing error which caused a segfault if you attempted to use Restart Session in a post-not-close-on-exit pterm. [originally from svn r9909]
2013-07-11 17:24:23 +00:00
assert(pty->conf == NULL);
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
} else {
Fix an uninitialised bufchain in NO_PTY_PRE_INIT mode. The Pty that we created in pty_pre_init had its bufchain properly initialised, but if that one didn't get created, then the one we create in pty_init did not. Now both should go through the same init routine.
2015-08-31 15:11:37 +00:00
pty = new_pty_struct();
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
pty->master_fd = pty->slave_fd = -1;
#ifndef OMIT_UTMP
pty_stamped_utmp = FALSE;
#endif
}
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
for (i = 0; i < 6; i++)
pty->pipefds[i] = -1;
for (i = 0; i < 3; i++) {
pty->fds[i].fd = -1;
pty->fds[i].pty = pty;
}
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
pty->seat = seat;
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
pty->backend.vt = &pty_backend;
pty backend now supports the changed function interface, so pterm now compiles and runs again after the major destabilisation. Unfortunately it wasn't feasible to actually encapsulate all of the pty backend's data, since the utmp helper and the need to fork and drop privileges before doing anything else at all rather confuses matters. So the data handle passed around to the pty backend is a null pointer, and the pty backend is just as global-ridden as it always has been. Shame, but such is life. [originally from svn r2128]
2002-10-25 11:50:51 +00:00
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
pty->conf = conf_copy(conf);
pty->term_width = conf_get_int(conf, CONF_width);
pty->term_height = conf_get_int(conf, CONF_height);
Cleanups from yesterday's destabilisation: lots of stuff in terminal.c was apparently relying on implicit initialisation to zero, and also I've removed the backends' dependency on terminal.h by having terminal sizes explicitly passed in to back->size(). [originally from svn r2117]
2002-10-23 12:41:35 +00:00
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
if (!ptyfds)
ptyfds = newtree234(ptyfd_compare);
if (pipes_instead) {
if (pty->master_fd >= 0) {
/* If somehow we've got a pty master already and don't
* need it, throw it away! */
close(pty->master_fd);
Add missing #ifndef OMIT_UTMP over pty_utmp_helper_pipe closing
2018-10-21 11:57:16 +00:00
#ifndef OMIT_UTMP
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
if (pty_utmp_helper_pipe >= 0) {
close(pty_utmp_helper_pipe); /* don't need this either */
pty_utmp_helper_pipe = -1;
}
Add missing #ifndef OMIT_UTMP over pty_utmp_helper_pipe closing
2018-10-21 11:57:16 +00:00
#endif
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
}
for (i = 0; i < 6; i += 2) {
if (pipe(pty->pipefds + i) < 0) {
backend_free(&pty->backend);
return NULL;
}
}
pty->fds[0].fd = pty->master_i = pty->pipefds[1];
pty->fds[1].fd = pty->master_o = pty->pipefds[2];
pty->fds[2].fd = pty->master_e = pty->pipefds[4];
add234(ptyfds, &pty->fds[0]);
add234(ptyfds, &pty->fds[1]);
add234(ptyfds, &pty->fds[2]);
} else {
if (pty->master_fd < 0)
pty_open_master(pty);
Fix utmp and pty handling so that GTK never complains about running set[ug]id. All privs-requiring pty operations are done at the very start of the run, then privs are dropped before initialising GTK. Utmp is handled by forking a still-privileged subprocess at this point, and later asking it (through a pipe) to stamp utmp. The subprocess cleans up utmp on exit, which has the additional advantage that if the main pterm process suffers some sort of unexpected termination (up to and including SIGKILL) the subprocess can still mop up utmp. [originally from svn r2082]
2002-10-16 12:17:51 +00:00
RJK's OS X portability patch: - initialise blank mbstate_t using memset rather than an ad-hoc initialiser. - expand the OMIT_UTMP ifdefs to enclose a load of entire functions that would generate `static function never called' warnings if left as empty shells. - couple of other fiddly things. [originally from svn r4896]
2004-11-24 11:36:08 +00:00
#ifndef OMIT_UTMP
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
/*
* Stamp utmp (that is, tell the utmp helper process to do so),
* or not.
*/
if (pty_utmp_helper_pipe >= 0) { /* if it's < 0, we can't anyway */
if (!conf_get_int(conf, CONF_stamp_utmp)) {
/* We're not stamping utmp, so just let the child
* process die that was waiting to unstamp it later. */
close(pty_utmp_helper_pipe);
pty_utmp_helper_pipe = -1;
} else {
const char *location = seat_get_x_display(pty->seat);
int len = strlen(location)+1, pos = 0; /* +1 to include NUL */
while (pos < len) {
int ret = write(pty_utmp_helper_pipe,
location + pos, len - pos);
if (ret < 0) {
perror("pterm: writing to utmp helper process");
close(pty_utmp_helper_pipe); /* arrgh, just give up */
pty_utmp_helper_pipe = -1;
break;
}
pos += ret;
Switch round a bogus if statement I've just noticed. Both the write to pty_utmp_helper_pipe _and_ the close of it if we're not going to write should be conditionalised on the pipe existing, rather than just the former! [originally from svn r9729]
2012-12-18 09:19:04 +00:00
}
}
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
}
RJK's OS X portability patch: - initialise blank mbstate_t using memset rather than an ad-hoc initialiser. - expand the OMIT_UTMP ifdefs to enclose a load of entire functions that would generate `static function never called' warnings if left as empty shells. - couple of other fiddly things. [originally from svn r4896]
2004-11-24 11:36:08 +00:00
#endif
Support for utmp, wtmp and lastlog. Probably not terribly portable as yet, but seems to work plausibly on Linux. [originally from svn r2058]
2002-10-15 12:29:52 +00:00
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
pty->master_i = pty->master_fd;
pty->master_o = pty->master_fd;
pty->master_e = -1;
pty->fds[0].fd = pty->master_fd;
add234(ptyfds, &pty->fds[0]);
}
The pty backend won't _always_ be running under X, so it should be possible to compile it without the WINDOWID variable. [originally from svn r5259]
2005-02-06 13:33:41 +00:00
#ifndef NOT_X_WINDOWS /* for Mac OS X native compilation */
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
got_windowid = seat_get_windowid(pty->seat, &windowid);
The pty backend won't _always_ be running under X, so it should be possible to compile it without the WINDOWID variable. [originally from svn r5259]
2005-02-06 13:33:41 +00:00
#endif
Richard B's patch to add WINDOWID support to pterm. [originally from svn r2912]
2003-03-06 12:57:37 +00:00
Reinstate the SIGCHLD handler in ptermapp. Detecting that the child process in a pterm has terminated is important for _any_ kind of pterm, so it's a mistake to put the signal handler setup _solely_ inside the optional pty_pre_init function which does the privileged setup and forks off a utmp watchdog process. Now the signal handler is installed even in the GtkApplication-based multi-window front end to pterm, meaning it will exist even on OS X.
2017-11-25 21:49:31 +00:00
/*
* Set up the signal handler to catch SIGCHLD, if pty_pre_init
* didn't already do it.
*/
pty_setup_sigchld_handler();
And that's it! pty.c is now a real pty backend rather than a loopback interface; pterm now runs $SHELL and gives every impression of being not a bad terminal emulator. I'm quite pleased with that. :-) [originally from svn r2015]
2002-10-10 12:40:05 +00:00
/*
* Fork and execute the command.
*/
pid = fork();
if (pid < 0) {
perror("fork");
Resizing of pterm now works, and the size information is correctly sent on to the pty. [originally from svn r2036]
2002-10-13 12:44:01 +00:00
exit(1);
And that's it! pty.c is now a real pty backend rather than a loopback interface; pterm now runs $SHELL and gives every impression of being not a bad terminal emulator. I'm quite pleased with that. :-) [originally from svn r2015]
2002-10-10 12:40:05 +00:00
}
if (pid == 0) {
pterm: move termios setup to after the fork. On OS X, apparently, we can't do termios setup on the pty master, so instead we have to leave it until we've opened the slave fd in the child process. That works on Linux too, so let's leave it here rather than having another cumbersome ifdef.
2015-09-01 17:45:51 +00:00
struct termios attrs;
And that's it! pty.c is now a real pty backend rather than a loopback interface; pterm now runs $SHELL and gives every impression of being not a bad terminal emulator. I'm quite pleased with that. :-) [originally from svn r2015]
2002-10-10 12:40:05 +00:00
/*
* We are the child.
*/
Various faffs in the pty allocation process to get controlling terminals right. Irritatingly this was working when run from another [xsp]term but not when run from my GNOME panel. I think it's now more robust. [originally from svn r2041]
2002-10-14 08:56:55 +00:00
New program 'osxlaunch', to use as an OS X bundle launcher. The big problem with making an OS X application out of a GTK program is that it won't start unless DYLD_LIBRARY_PATH and several other environment variables point at all the GTK machinery. So your app bundle has to contain two programs: a launcher to set up that environment, and then the real main program that the launcher execs once it's done so. But in our case, we also need pterm to start subprocesses _without_ all that stuff in the environment - so our launcher has to be more complicated than the usual one, because it's also got to save every detail of how the environment was when it started up. So this is the launcher program I'm going to use. Comments in the header explain in more detail how it'll work. Also in this commit, I add the other end of the same machinery to gtkapp.c and uxpty.c: the former catches an extra command-line argument that the launcher used to indicate how it had munged the environment, and stores it in a global variable where the latter can pick it up after fork() and use to actually undo the munging.
2016-03-23 22:13:30 +00:00
if (pty_osx_envrestore_prefix) {
int plen = strlen(pty_osx_envrestore_prefix);
extern char **environ;
char **ep;
restart_osx_env_restore:
for (ep = environ; *ep; ep++) {
char *e = *ep;
if (!strncmp(e, pty_osx_envrestore_prefix, plen)) {
int unset = (e[plen] == 'u');
char *pname = dupprintf("%.*s", (int)strcspn(e, "="), e);
char *name = pname + plen + 1;
char *value = e + strcspn(e, "=");
if (*value) value++;
value = dupstr(value);
if (unset)
unsetenv(name);
else
setenv(name, value, 1);
unsetenv(pname);
sfree(pname);
sfree(value);
goto restart_osx_env_restore;
}
}
}
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
pgrp = getpid();
Various faffs in the pty allocation process to get controlling terminals right. Irritatingly this was working when run from another [xsp]term but not when run from my GNOME panel. I think it's now more robust. [originally from svn r2041]
2002-10-14 08:56:55 +00:00
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
if (pipes_instead) {
int i;
dup2(pty->pipefds[0], 0);
dup2(pty->pipefds[3], 1);
dup2(pty->pipefds[5], 2);
for (i = 0; i < 6; i++)
close(pty->pipefds[i]);
setsid();
} else {
slavefd = pty_open_slave(pty);
if (slavefd < 0) {
perror("slave pty: open");
_exit(1);
}
close(pty->master_fd);
noncloexec(slavefd);
dup2(slavefd, 0);
dup2(slavefd, 1);
dup2(slavefd, 2);
close(slavefd);
setsid();
Some hosts don't have TIOCSCTTY. Don't try to use it on them. Patch from Mike Protts. [originally from svn r6306]
2005-09-13 19:57:37 +00:00
#ifdef TIOCSCTTY
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
ioctl(0, TIOCSCTTY, 1);
Some hosts don't have TIOCSCTTY. Don't try to use it on them. Patch from Mike Protts. [originally from svn r6306]
2005-09-13 19:57:37 +00:00
#endif
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
tcsetpgrp(0, pgrp);
pterm: move termios setup to after the fork. On OS X, apparently, we can't do termios setup on the pty master, so instead we have to leave it until we've opened the slave fd in the child process. That works on Linux too, so let's leave it here rather than having another cumbersome ifdef.
2015-09-01 17:45:51 +00:00
/*
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
* Set up configuration-dependent termios settings on the new
* pty. Linux would have let us do this on the pty master
* before we forked, but that fails on OS X, so we do it here
* instead.
pterm: move termios setup to after the fork. On OS X, apparently, we can't do termios setup on the pty master, so instead we have to leave it until we've opened the slave fd in the child process. That works on Linux too, so let's leave it here rather than having another cumbersome ifdef.
2015-09-01 17:45:51 +00:00
*/
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
if (tcgetattr(0, &attrs) == 0) {
/*
* Set the backspace character to be whichever of ^H and
* ^? is specified by bksp_is_delete.
*/
attrs.c_cc[VERASE] = conf_get_int(conf, CONF_bksp_is_delete)
? '\177' : '\010';
/*
* Set the IUTF8 bit iff the character set is UTF-8.
*/
pterm: move termios setup to after the fork. On OS X, apparently, we can't do termios setup on the pty master, so instead we have to leave it until we've opened the slave fd in the child process. That works on Linux too, so let's leave it here rather than having another cumbersome ifdef.
2015-09-01 17:45:51 +00:00
#ifdef IUTF8
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
if (seat_is_utf8(seat))
attrs.c_iflag |= IUTF8;
else
attrs.c_iflag &= ~IUTF8;
pterm: move termios setup to after the fork. On OS X, apparently, we can't do termios setup on the pty master, so instead we have to leave it until we've opened the slave fd in the child process. That works on Linux too, so let's leave it here rather than having another cumbersome ifdef.
2015-09-01 17:45:51 +00:00
#endif
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
copy_ttymodes_into_termios(&attrs, ttymodes);
uxpty: give pty_backend_create a struct ssh_ttymodes. This will be applied to the pty's termios settings at creation time, superseding the default settings uxpty has always used. It works by including the new sshttymodes.h with TTYMODES_LOCAL_ONLY defined, so that modes not supported by a particular Unix system are automatically quietly ignored. Of course, a struct ssh_ttymodes always has the option of representing "please make no change to the defaults", and of course, that's precisely what is done by the one that pty_init constructs for clients that aren't calling pty_backend_create directly.
2018-10-18 19:37:33 +00:00
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
tcsetattr(0, TCSANOW, &attrs);
}
pterm: move termios setup to after the fork. On OS X, apparently, we can't do termios setup on the pty master, so instead we have to leave it until we've opened the slave fd in the child process. That works on Linux too, so let's leave it here rather than having another cumbersome ifdef.
2015-09-01 17:45:51 +00:00
}
I think rjk meant `setpgid', not `setpgrp'. [originally from svn r4897]
2004-11-24 11:42:45 +00:00
setpgid(pgrp, pgrp);
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
if (!pipes_instead) {
Add a missing error check in pterm's child-process setup. Shouldn't really fail, but might as well be careful. [originally from svn r9931]
2013-07-19 17:44:22 +00:00
int ptyfd = open(pty->name, O_WRONLY, 0);
if (ptyfd >= 0)
close(ptyfd);
}
I think rjk meant `setpgid', not `setpgrp'. [originally from svn r4897]
2004-11-24 11:42:45 +00:00
setpgid(pgrp, pgrp);
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
if (!pipes_instead) {
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
char *term_env_var = dupprintf("TERM=%s",
conf_get_str(conf, CONF_termtype));
Don't forget to set $TERM when we spawn the pty. Of course I haven't noticed this until now because I've always been spawning it _from_ another xterm! :-) [originally from svn r2039]
2002-10-13 23:57:40 +00:00
putenv(term_env_var);
Patch from Colin Watson: we were sometimes passing stack storage to putenv(), which is Bad (in his case, it caused TERM to end up unset). Use malloc()'d storage instead. [originally from svn r6095]
2005-07-15 11:47:28 +00:00
/* We mustn't free term_env_var, as putenv links it into the
* environment in place.
*/
Don't forget to set $TERM when we spawn the pty. Of course I haven't noticed this until now because I've always been spawning it _from_ another xterm! :-) [originally from svn r2039]
2002-10-13 23:57:40 +00:00
}
The pty backend won't _always_ be running under X, so it should be possible to compile it without the WINDOWID variable. [originally from svn r5259]
2005-02-06 13:33:41 +00:00
#ifndef NOT_X_WINDOWS /* for Mac OS X native compilation */
Basic support for running under GDK Wayland back end. GTK 3 PuTTY/pterm has always assumed that if it was compiled with _support_ for talking to the raw X11 layer underneath GTK and GDK, then it was entitled to expect that raw X11 layer to exist at all times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X display that it could do useful things with. So if you ran it over the GDK Wayland backend, it would immediately segfault. Modern GTK applications need to cope with multiple GDK backends at run time. It's fine for GTK PuTTY to _contain_ the code to find and use underlying X11 primitives like the display and the X window id, but it should be prepared to find that it's running on Wayland (or something else again!) so those functions don't return anything useful - in which case it should degrade gracefully to the subset of functionality that can be accessed through backend-independent GTK calls. Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a support function get_x_display() in gtkmisc.c, which starts by checking that there actually is one first. All previous direct uses of GDK_*_XDISPLAY now go via that function, and check the result for NULL afterwards. (To save faffing about calling that function too many times, I'm also caching the display pointer in more places, and passing it as an extra argument to various subfunctions, mostly in gtkfont.c.) Similarly, the get_windowid() function that retrieves the window id to put in the environment of pterm's child process has to be prepared for there not to be a window id. This isn't a complete fix for all Wayland-related problems. The other one I'm currently aware of is that the default font is "server:fixed", which is a bad default now that it won't be available on all backends. And I expect that further problems will show up with more testing. But it's a start.
2018-05-09 08:18:20 +00:00
if (got_windowid) {
Patch from Colin Watson: we were sometimes passing stack storage to putenv(), which is Bad (in his case, it caused TERM to end up unset). Use malloc()'d storage instead. [originally from svn r6095]
2005-07-15 11:47:28 +00:00
char *windowid_env_var = dupprintf("WINDOWID=%ld", windowid);
Richard B's patch to add WINDOWID support to pterm. [originally from svn r2912]
2003-03-06 12:57:37 +00:00
putenv(windowid_env_var);
Patch from Colin Watson: we were sometimes passing stack storage to putenv(), which is Bad (in his case, it caused TERM to end up unset). Use malloc()'d storage instead. [originally from svn r6095]
2005-07-15 11:47:28 +00:00
/* We mustn't free windowid_env_var, as putenv links it into the
* environment in place.
*/
Richard B's patch to add WINDOWID support to pterm. [originally from svn r2912]
2003-03-06 12:57:37 +00:00
}
'pterm --display' should set $DISPLAY inside the terminal. If you open a pterm on a different display via the --display command-line option rather than by setting $DISPLAY, I think (and other terminals seem to agree) that it's sensible to set $DISPLAY anyway for processes running inside the terminal.
2015-08-22 14:05:12 +00:00
{
/*
* In case we were invoked with a --display argument that
* doesn't match DISPLAY in our actual environment, we
* should set DISPLAY for processes running inside the
* terminal to match the display the terminal itself is
* on.
*/
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
const char *x_display = seat_get_x_display(pty->seat);
'pterm --display' should set $DISPLAY inside the terminal. If you open a pterm on a different display via the --display command-line option rather than by setting $DISPLAY, I think (and other terminals seem to agree) that it's sensible to set $DISPLAY anyway for processes running inside the terminal.
2015-08-22 14:05:12 +00:00
char *x_display_env_var = dupprintf("DISPLAY=%s", x_display);
putenv(x_display_env_var);
/* As above, we don't free this. */
}
The pty backend won't _always_ be running under X, so it should be possible to compile it without the WINDOWID variable. [originally from svn r5259]
2005-02-06 13:33:41 +00:00
#endif
Moved the environment variables config block out of the Telnet panel into the Connection panel, and implemented support for the SSH2 "env" request. (I haven't yet found a server which accepts this request, so although I've visually checked the packet log and it looks OK, I haven't yet been able to do a full end-to-end test.) Also, the `pty' backend reads this data and does a series of `putenv' commands before launching the shell or application. This is mostly because in last week's UTF-8 faffings I got thoroughly sick of typing `export LANG=en_GB.UTF-8' every time I started a new testing pterm, and it suddenly occurred to me that this would be precisely the sort of thing you'd want to have pterm set up for you, particularly since you can configure it alongside the translation settings and so you can ensure they match up properly. [originally from svn r4645]
2004-10-16 10:56:54 +00:00
{
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
char *key, *val;
for (val = conf_get_str_strs(conf, CONF_environmt, NULL, &key);
val != NULL;
val = conf_get_str_strs(conf, CONF_environmt, key, &key)) {
char *varval = dupcat(key, "=", val, NULL);
Moved the environment variables config block out of the Telnet panel into the Connection panel, and implemented support for the SSH2 "env" request. (I haven't yet found a server which accepts this request, so although I've visually checked the packet log and it looks OK, I haven't yet been able to do a full end-to-end test.) Also, the `pty' backend reads this data and does a series of `putenv' commands before launching the shell or application. This is mostly because in last week's UTF-8 faffings I got thoroughly sick of typing `export LANG=en_GB.UTF-8' every time I started a new testing pterm, and it suddenly occurred to me that this would be precisely the sort of thing you'd want to have pterm set up for you, particularly since you can configure it alongside the translation settings and so you can ensure they match up properly. [originally from svn r4645]
2004-10-16 10:56:54 +00:00
putenv(varval);
/*
* We must not free varval, since putenv links it
* into the environment _in place_. Weird, but
* there we go. Memory usage will be rationalised
* as soon as we exec anyway.
*/
}
}
Make sure SIGINT and SIGQUIT haven't been nobbled in our child process by weird POSIX-required shell behaviour. [originally from svn r2110]
2002-10-21 23:01:34 +00:00
/*
Colin Watson reports that gnome-session has been known to leave SIGPIPE ignored in its child processes, leading to unexpected behaviour inside pterms. (The gnome-session I'm sitting in front of doesn't seem to do this as far as I can tell, but I don't doubt there are some that do.) Add SIGPIPE to the list of signals we reset to default behaviour before launching pterm's child process. [originally from svn r9117]
2011-03-02 19:12:42 +00:00
* SIGINT, SIGQUIT and SIGPIPE may have been set to ignored by
* our parent, particularly by things like sh -c 'pterm &' and
Divide the whole of gtkwin.c into three parts. This lays further groundwork for the OS X GTK3 port, which is going to have to deal with multiple sessions sharing the same process. gtkwin.c was a bit too monolithic for this, since it included some process-global runtime state (timers, toplevel callbacks), some process startup stuff (gtk_init, gtk_main, argv processing) and some per-session-window stuff. The per-session stuff remains in gtkwin.c, with the top-level function now being new_session_window() taking a Conf. The new gtkmain.c contains the outer skeleton of pt_main(), handling argv processing and one-off startup stuff like setlocale; and the new gtkcomm.c contains the pieces of PuTTY infrastructure like timers and uxsel that are shared between multiple sessions rather than reinstantiated per session, which have been rewritten to use global variables rather than fields in 'inst' (since it's now clear to me that they'll have to apply to all the insts in existence at once). There are still some lurking assumptions of one-session-per-process, e.g. the use of gtk_main_quit when a session finishes, and the fact that the config box insists on running as a separate invocation of gtk_main so that one session's preliminary config box can't coexist with another session already active. But this should make it possible to at least write an OS X app good enough to start testing with, even if it doesn't get everything quite right yet. This change is almost entirely rearranging existing code, so it shouldn't be seriously destabilising. But two noticeable actual changes have happened, both pleasantly simplifying: Firstly, the global-variables rewrite of gtkcomm.c has allowed the post_main edifice to become a great deal simpler. Most of its complexity was about remembering what 'inst' it had to call back to, and in fact the right answer is that it shouldn't be calling back to one at all. So now the post_main() called by gtkdlg.c has become the same function as the old inst_post_main() that actually did the work, instead of the two having to be connected by a piece of ugly plumbing. Secondly, a piece of code that's vanished completely in this refactoring is the temporary blocking of SIGCHLD around most of the session setup code. This turns out to have been introduced in 2002, _before_ I switched to using the intra-process signal pipe strategy for SIGCHLD handling in 2003. So I now expect that we should be robust in any case against receiving SIGCHLD at an inconvenient moment, and hence there's no need to block it.
2016-03-22 21:24:30 +00:00
* some window or session managers. SIGPIPE was also
* (potentially) blocked by us during startup. Reverse all
* this for our child process.
Make sure SIGINT and SIGQUIT haven't been nobbled in our child process by weird POSIX-required shell behaviour. [originally from svn r2110]
2002-10-21 23:01:34 +00:00
*/
RJK's general signal-handling robustness patch. Should fix the weird spin behaviour occasionally seen after pterm's child process dies. [originally from svn r2181]
2002-11-02 14:35:57 +00:00
putty_signal(SIGINT, SIG_DFL);
putty_signal(SIGQUIT, SIG_DFL);
Colin Watson reports that gnome-session has been known to leave SIGPIPE ignored in its child processes, leading to unexpected behaviour inside pterms. (The gnome-session I'm sitting in front of doesn't seem to do this as far as I can tell, but I don't doubt there are some that do.) Add SIGPIPE to the list of signals we reset to default behaviour before launching pterm's child process. [originally from svn r9117]
2011-03-02 19:12:42 +00:00
putty_signal(SIGPIPE, SIG_DFL);
Divide the whole of gtkwin.c into three parts. This lays further groundwork for the OS X GTK3 port, which is going to have to deal with multiple sessions sharing the same process. gtkwin.c was a bit too monolithic for this, since it included some process-global runtime state (timers, toplevel callbacks), some process startup stuff (gtk_init, gtk_main, argv processing) and some per-session-window stuff. The per-session stuff remains in gtkwin.c, with the top-level function now being new_session_window() taking a Conf. The new gtkmain.c contains the outer skeleton of pt_main(), handling argv processing and one-off startup stuff like setlocale; and the new gtkcomm.c contains the pieces of PuTTY infrastructure like timers and uxsel that are shared between multiple sessions rather than reinstantiated per session, which have been rewritten to use global variables rather than fields in 'inst' (since it's now clear to me that they'll have to apply to all the insts in existence at once). There are still some lurking assumptions of one-session-per-process, e.g. the use of gtk_main_quit when a session finishes, and the fact that the config box insists on running as a separate invocation of gtk_main so that one session's preliminary config box can't coexist with another session already active. But this should make it possible to at least write an OS X app good enough to start testing with, even if it doesn't get everything quite right yet. This change is almost entirely rearranging existing code, so it shouldn't be seriously destabilising. But two noticeable actual changes have happened, both pleasantly simplifying: Firstly, the global-variables rewrite of gtkcomm.c has allowed the post_main edifice to become a great deal simpler. Most of its complexity was about remembering what 'inst' it had to call back to, and in fact the right answer is that it shouldn't be calling back to one at all. So now the post_main() called by gtkdlg.c has become the same function as the old inst_post_main() that actually did the work, instead of the two having to be connected by a piece of ugly plumbing. Secondly, a piece of code that's vanished completely in this refactoring is the temporary blocking of SIGCHLD around most of the session setup code. This turns out to have been introduced in 2002, _before_ I switched to using the intra-process signal pipe strategy for SIGCHLD handling in 2003. So I now expect that we should be robust in any case against receiving SIGCHLD at an inconvenient moment, and hence there's no need to block it.
2016-03-22 21:24:30 +00:00
block_signal(SIGPIPE, 0);
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
if (argv || cmd) {
If pterm's execvp fails when given the whole argument list after -e, and the argument list contains only one string, try again by passing that single string to "$SHELL -c" to be parsed as a shell command. This matches xterm's behaviour (as of xterm 261, at least), and means in practice that users can do _either_ of 'pterm -e some command' and 'pterm -e "some command"'. (A quick survey suggests that the majority of X terminal programs agree with pterm's old behaviour of only supporting '-e some command', except that gnome-terminal only supports the other behaviour and xterm supports both. With that disagreement, I think supporting both is probably the sensible thing.) [originally from svn r9575]
2012-07-11 18:12:17 +00:00
/*
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
* If we were given a separated argument list, try to exec
* it.
If pterm's execvp fails when given the whole argument list after -e, and the argument list contains only one string, try again by passing that single string to "$SHELL -c" to be parsed as a shell command. This matches xterm's behaviour (as of xterm 261, at least), and means in practice that users can do _either_ of 'pterm -e some command' and 'pterm -e "some command"'. (A quick survey suggests that the majority of X terminal programs agree with pterm's old behaviour of only supporting '-e some command', except that gnome-terminal only supports the other behaviour and xterm supports both. With that disagreement, I think supporting both is probably the sensible thing.) [originally from svn r9575]
2012-07-11 18:12:17 +00:00
*/
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
if (argv) {
execvp(argv[0], argv);
}
If pterm's execvp fails when given the whole argument list after -e, and the argument list contains only one string, try again by passing that single string to "$SHELL -c" to be parsed as a shell command. This matches xterm's behaviour (as of xterm 261, at least), and means in practice that users can do _either_ of 'pterm -e some command' and 'pterm -e "some command"'. (A quick survey suggests that the majority of X terminal programs agree with pterm's old behaviour of only supporting '-e some command', except that gnome-terminal only supports the other behaviour and xterm supports both. With that disagreement, I think supporting both is probably the sensible thing.) [originally from svn r9575]
2012-07-11 18:12:17 +00:00
/*
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
* Otherwise, if we were given a single command string,
* try passing that to $SHELL -c.
If pterm's execvp fails when given the whole argument list after -e, and the argument list contains only one string, try again by passing that single string to "$SHELL -c" to be parsed as a shell command. This matches xterm's behaviour (as of xterm 261, at least), and means in practice that users can do _either_ of 'pterm -e some command' and 'pterm -e "some command"'. (A quick survey suggests that the majority of X terminal programs agree with pterm's old behaviour of only supporting '-e some command', except that gnome-terminal only supports the other behaviour and xterm supports both. With that disagreement, I think supporting both is probably the sensible thing.) [originally from svn r9575]
2012-07-11 18:12:17 +00:00
*
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
* In the case of pterm, this system of fallbacks arranges
* that we can _either_ follow 'pterm -e' with a list of
* argv elements to be fed directly to exec, _or_ with a
* single argument containing a command to be parsed by a
* shell (but, in cases of doubt, the former is more
* reliable). We arrange this by setting argv to the full
* argument list, and also setting cmd to the single
* element of argv if it's a length-1 list.
If pterm's execvp fails when given the whole argument list after -e, and the argument list contains only one string, try again by passing that single string to "$SHELL -c" to be parsed as a shell command. This matches xterm's behaviour (as of xterm 261, at least), and means in practice that users can do _either_ of 'pterm -e some command' and 'pterm -e "some command"'. (A quick survey suggests that the majority of X terminal programs agree with pterm's old behaviour of only supporting '-e some command', except that gnome-terminal only supports the other behaviour and xterm supports both. With that disagreement, I think supporting both is probably the sensible thing.) [originally from svn r9575]
2012-07-11 18:12:17 +00:00
*
* A quick survey of other terminal emulators' -e options
* (as of Debian squeeze) suggests that:
*
* - xterm supports both modes, more or less like this
* - gnome-terminal will only accept a one-string shell command
* - Eterm, kterm and rxvt will only accept a list of
* argv elements (as did older versions of pterm).
*
* It therefore seems important to support both usage
* modes in order to be a drop-in replacement for either
* xterm or gnome-terminal, and hence for anyone's
* plausible uses of the Debian-style alias
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
* 'x-terminal-emulator'.
*
* In other use cases, a caller can set only one of argv
* and cmd to get a fixed handling of the input.
If pterm's execvp fails when given the whole argument list after -e, and the argument list contains only one string, try again by passing that single string to "$SHELL -c" to be parsed as a shell command. This matches xterm's behaviour (as of xterm 261, at least), and means in practice that users can do _either_ of 'pterm -e some command' and 'pterm -e "some command"'. (A quick survey suggests that the majority of X terminal programs agree with pterm's old behaviour of only supporting '-e some command', except that gnome-terminal only supports the other behaviour and xterm supports both. With that disagreement, I think supporting both is probably the sensible thing.) [originally from svn r9575]
2012-07-11 18:12:17 +00:00
*/
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
if (cmd) {
If pterm's execvp fails when given the whole argument list after -e, and the argument list contains only one string, try again by passing that single string to "$SHELL -c" to be parsed as a shell command. This matches xterm's behaviour (as of xterm 261, at least), and means in practice that users can do _either_ of 'pterm -e some command' and 'pterm -e "some command"'. (A quick survey suggests that the majority of X terminal programs agree with pterm's old behaviour of only supporting '-e some command', except that gnome-terminal only supports the other behaviour and xterm supports both. With that disagreement, I think supporting both is probably the sensible thing.) [originally from svn r9575]
2012-07-11 18:12:17 +00:00
char *shell = getenv("SHELL");
if (shell)
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
execl(shell, shell, "-c", cmd, (void *)NULL);
If pterm's execvp fails when given the whole argument list after -e, and the argument list contains only one string, try again by passing that single string to "$SHELL -c" to be parsed as a shell command. This matches xterm's behaviour (as of xterm 261, at least), and means in practice that users can do _either_ of 'pterm -e some command' and 'pterm -e "some command"'. (A quick survey suggests that the majority of X terminal programs agree with pterm's old behaviour of only supporting '-e some command', except that gnome-terminal only supports the other behaviour and xterm supports both. With that disagreement, I think supporting both is probably the sensible thing.) [originally from svn r9575]
2012-07-11 18:12:17 +00:00
}
} else {
Introduce the ability to control whether the shell run in pterm is a login shell or not. Also moved these new pieces of configuration into the Config structure, though they won't stay there forever since they will need to be moved out into platform-dependent config. [originally from svn r2060]
2002-10-15 13:07:18 +00:00
char *shell = getenv("SHELL");
char *shellname;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
if (conf_get_int(conf, CONF_login_shell)) {
Introduce the ability to control whether the shell run in pterm is a login shell or not. Also moved these new pieces of configuration into the Config structure, though they won't stay there forever since they will need to be moved out into platform-dependent config. [originally from svn r2060]
2002-10-15 13:07:18 +00:00
char *p = strrchr(shell, '/');
Introduced wrapper macros snew(), snewn() and sresize() for the malloc functions, which automatically cast to the same type they're allocating the size of. Should prevent any future errors involving mallocing the size of the wrong structure type, and will also make life easier if we ever need to turn the PuTTY core code from real C into C++-friendly C. I haven't touched the Mac frontend in this checkin because I couldn't compile or test it. [originally from svn r3014]
2003-03-29 16:14:26 +00:00
shellname = snewn(2+strlen(shell), char);
Introduce the ability to control whether the shell run in pterm is a login shell or not. Also moved these new pieces of configuration into the Config structure, though they won't stay there forever since they will need to be moved out into platform-dependent config. [originally from svn r2060]
2002-10-15 13:07:18 +00:00
p = p ? p+1 : shell;
sprintf(shellname, "-%s", p);
} else
shellname = shell;
NULL needs to be cast to void * when passed to a variadic function like execl(). Spotted by Damien Miller. [originally from svn r5592]
2005-04-04 13:44:45 +00:00
execl(getenv("SHELL"), shellname, (void *)NULL);
Introduce the ability to control whether the shell run in pterm is a login shell or not. Also moved these new pieces of configuration into the Config structure, though they won't stay there forever since they will need to be moved out into platform-dependent config. [originally from svn r2060]
2002-10-15 13:07:18 +00:00
}
And that's it! pty.c is now a real pty backend rather than a loopback interface; pterm now runs $SHELL and gives every impression of being not a bad terminal emulator. I'm quite pleased with that. :-) [originally from svn r2015]
2002-10-10 12:40:05 +00:00
/*
* If we're here, exec has gone badly foom.
*/
perror("exec");
RJK's general signal-handling robustness patch. Should fix the weird spin behaviour occasionally seen after pterm's child process dies. [originally from svn r2181]
2002-11-02 14:35:57 +00:00
_exit(127);
And that's it! pty.c is now a real pty backend rather than a loopback interface; pterm now runs $SHELL and gives every impression of being not a bad terminal emulator. I'm quite pleased with that. :-) [originally from svn r2015]
2002-10-10 12:40:05 +00:00
} else {
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
pty->child_pid = pid;
pty->child_dead = FALSE;
pty->finished = FALSE;
if (pty->slave_fd > 0)
close(pty->slave_fd);
if (!ptys_by_pid)
ptys_by_pid = newtree234(pty_compare_by_pid);
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
if (pty->pipefds[0] >= 0) {
close(pty->pipefds[0]);
pty->pipefds[0] = -1;
}
if (pty->pipefds[3] >= 0) {
close(pty->pipefds[3]);
pty->pipefds[3] = -1;
}
if (pty->pipefds[5] >= 0) {
close(pty->pipefds[5]);
pty->pipefds[5] = -1;
}
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
add234(ptys_by_pid, pty);
When allocating BSD-style ptys, we should not be satisfied with a /dev/ptyXX we can open: we must also check that we can open and use the corresponding /dev/ttyXX, because if it's been left in the wrong mode then we will look terribly silly when we fork and _then_ discover our pty is unusable. [originally from svn r5257]
2005-02-05 15:33:36 +00:00
}
And that's it! pty.c is now a real pty backend rather than a loopback interface; pterm now runs $SHELL and gives every impression of being not a bad terminal emulator. I'm quite pleased with that. :-) [originally from svn r2015]
2002-10-10 12:40:05 +00:00
Remove the loops that close all open fds before running a subprocess. They were intended to make sure the child process didn't inherit anything embarrassing or inconvenient from us, such as the master end of its own pty, but now we instead do this by making sure to set all our own fds to not-FD_CLOEXEC on creation. This should fix Debian bug #357520. (This doesn't seem to work _quite_ right in uxproxy.c's invocation of a local proxy command: both ends of a GTK internal pipe end up in the child process's fd space. This appears to be another GTK 1 bug, inasmuch as it goes away when I build with Colin's preliminary GTK 2 patch; for the moment I think leaving that pipe lying around is probably less harmful than hampering the proxy process's ability to use extra fds by prior arrangement with PuTTY's parent process.) [originally from svn r7107]
2007-01-14 13:44:07 +00:00
if (pty_signal_pipe[0] < 0) {
if (pipe(pty_signal_pipe) < 0) {
perror("pipe");
exit(1);
}
cloexec(pty_signal_pipe[0]);
cloexec(pty_signal_pipe[1]);
pterm now uses the new uxsel module, so it's one step closer to 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]
2003-03-29 18:30:14 +00:00
}
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
pty_uxsel_setup(pty);
uxpty: new specialist backend-creation API. The function that does the main pty setup is now called pty_backend_create(), and has an API better suited to uxpty in particular than the standard backend_init() virtual constructor. It leaves off a load of standard parameters to backend_init() which aren't really relevant to this backend, and it adds the 'argv' parameter to pass in a split-up command line, which is unique to it. The old creation function still exists, as a tiny wrapper that calls the new pty_backend_create. And that version still gets the argv parameter from the process-global variable pty_argv[], so the call sites in pterm haven't had to change for this. This will make it possible to instantiate a pty backend directly from the SSH server code, without having to do anything really excessively cumbersome to pass in a subcommand in the form of pre-split argv. (And I'll add a few more specialist parameters to the new function shortly.)
2018-10-13 07:32:40 +00:00
return &pty->backend;
}
pty_init should put _something_ into realhost [originally from svn r6679]
2006-05-12 11:02:28 +00:00
uxpty: new specialist backend-creation API. The function that does the main pty setup is now called pty_backend_create(), and has an API better suited to uxpty in particular than the standard backend_init() virtual constructor. It leaves off a load of standard parameters to backend_init() which aren't really relevant to this backend, and it adds the 'argv' parameter to pass in a split-up command line, which is unique to it. The old creation function still exists, as a tiny wrapper that calls the new pty_backend_create. And that version still gets the argv parameter from the process-global variable pty_argv[], so the call sites in pterm haven't had to change for this. This will make it possible to instantiate a pty backend directly from the SSH server code, without having to do anything really excessively cumbersome to pass in a subcommand in the form of pre-split argv. (And I'll add a few more specialist parameters to the new function shortly.)
2018-10-13 07:32:40 +00:00
/*
* This is the pty backend's _official_ init method, for BackendVtable
* purposes. Its job is just to be an API converter, ignoring the
* irrelevant input parameters and making up auxiliary outputs. Also
* it gets the argv array from the global variable pty_argv, expecting
* that it will have been invoked by pterm.
*/
static const char *pty_init(Seat *seat, Backend **backend_handle,
LogContext *logctx, Conf *conf,
const char *host, int port,
char **realhost, int nodelay, int keepalive)
{
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
const char *cmd = NULL;
uxpty: give pty_backend_create a struct ssh_ttymodes. This will be applied to the pty's termios settings at creation time, superseding the default settings uxpty has always used. It works by including the new sshttymodes.h with TTYMODES_LOCAL_ONLY defined, so that modes not supported by a particular Unix system are automatically quietly ignored. Of course, a struct ssh_ttymodes always has the option of representing "please make no change to the defaults", and of course, that's precisely what is done by the one that pty_init constructs for clients that aren't calling pty_backend_create directly.
2018-10-18 19:37:33 +00:00
struct ssh_ttymodes modes;
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
uxpty: give pty_backend_create a struct ssh_ttymodes. This will be applied to the pty's termios settings at creation time, superseding the default settings uxpty has always used. It works by including the new sshttymodes.h with TTYMODES_LOCAL_ONLY defined, so that modes not supported by a particular Unix system are automatically quietly ignored. Of course, a struct ssh_ttymodes always has the option of representing "please make no change to the defaults", and of course, that's precisely what is done by the one that pty_init constructs for clients that aren't calling pty_backend_create directly.
2018-10-18 19:37:33 +00:00
memset(&modes, 0, sizeof(modes));
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
if (pty_argv && pty_argv[0] && !pty_argv[1])
cmd = pty_argv[0];
*backend_handle= pty_backend_create(
seat, logctx, conf, pty_argv, cmd, modes, FALSE);
uxpty: new specialist backend-creation API. The function that does the main pty setup is now called pty_backend_create(), and has an API better suited to uxpty in particular than the standard backend_init() virtual constructor. It leaves off a load of standard parameters to backend_init() which aren't really relevant to this backend, and it adds the 'argv' parameter to pass in a split-up command line, which is unique to it. The old creation function still exists, as a tiny wrapper that calls the new pty_backend_create. And that version still gets the argv parameter from the process-global variable pty_argv[], so the call sites in pterm haven't had to change for this. This will make it possible to instantiate a pty backend directly from the SSH server code, without having to do anything really excessively cumbersome to pass in a subcommand in the form of pre-split argv. (And I'll add a few more specialist parameters to the new function shortly.)
2018-10-13 07:32:40 +00:00
*realhost = dupstr("");
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
return NULL;
}
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
static void pty_reconfig(Backend *be, Conf *conf)
The back ends now contain their own copies of the Config structure, and have a function to pass in a new one. (Well, actually several back ends don't actually bother to do this because they need nothing out of Config after the initial setup phase, but they could if they wanted to.) [originally from svn r2561]
2003-01-12 14:48:29 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
Pty *pty = container_of(be, Pty, backend);
Close On Exit and Warn On Close fixes: (a) pty_reconfig needs to remember changes in COE so it knows whether to print a message, and (b) once the session has already ended, Warn On Close should shut up. [originally from svn r3102]
2003-04-12 08:27:03 +00:00
/*
* We don't have much need to reconfigure this backend, but
* unfortunately we do need to pick up the setting of Close On
* Exit so we know whether to give a `terminated' message.
*/
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
conf_copy_into(pty->conf, conf);
The back ends now contain their own copies of the Config structure, and have a function to pass in a new one. (Well, actually several back ends don't actually bother to do this because they need nothing out of Config after the initial setup phase, but they could if they wanted to.) [originally from svn r2561]
2003-01-12 14:48:29 +00:00
}
Add a stub "free" routine for pterm. Thanks to rjk. [originally from svn r2666]
2003-01-20 20:10:07 +00:00
/*
Close On Exit and Warn On Close fixes: (a) pty_reconfig needs to remember changes in COE so it knows whether to print a message, and (b) once the session has already ended, Warn On Close should shut up. [originally from svn r3102]
2003-04-12 08:27:03 +00:00
* Stub routine (never called in pterm).
Add a stub "free" routine for pterm. Thanks to rjk. [originally from svn r2666]
2003-01-20 20:10:07 +00:00
*/
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
static void pty_free(Backend *be)
Add a stub "free" routine for pterm. Thanks to rjk. [originally from svn r2666]
2003-01-20 20:10:07 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
Pty *pty = container_of(be, Pty, backend);
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
int i;
pty_close(pty);
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
/* Either of these may fail `not found'. That's fine with us. */
del234(ptys_by_pid, pty);
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
for (i = 0; i < 3; i++)
if (pty->fds[i].fd >= 0)
del234(ptyfds, &pty->fds[i]);
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
Fix an uninitialised bufchain in NO_PTY_PRE_INIT mode. The Pty that we created in pty_pre_init had its bufchain properly initialised, but if that one didn't get created, then the one we create in pty_init did not. Now both should go through the same init routine.
2015-08-31 15:11:37 +00:00
bufchain_clear(&pty->output_data);
Fix a pty-freeing error which caused a segfault if you attempted to use Restart Session in a post-not-close-on-exit pterm. [originally from svn r9909]
2013-07-11 17:24:23 +00:00
conf_free(pty->conf);
pty->conf = NULL;
if (pty == single_pty) {
/*
* Leave this structure around in case we need to Restart
* Session.
*/
} else {
sfree(pty);
}
Add a stub "free" routine for pterm. Thanks to rjk. [originally from svn r2666]
2003-01-20 20:10:07 +00:00
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static void pty_try_write(Pty *pty)
Do proper select-for-write on ptys. Currently, pasting a sufficiently large string into pterm in any circumstances in which it's echoed back to the terminal will cause a deadlock once the pty's write buffer fills up. [originally from svn r6582]
2006-02-23 13:38:44 +00:00
{
void *data;
int len, ret;
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
assert(pty->master_i >= 0);
Do proper select-for-write on ptys. Currently, pasting a sufficiently large string into pterm in any circumstances in which it's echoed back to the terminal will cause a deadlock once the pty's write buffer fills up. [originally from svn r6582]
2006-02-23 13:38:44 +00:00
while (bufchain_size(&pty->output_data) > 0) {
bufchain_prefix(&pty->output_data, &data, &len);
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
ret = write(pty->master_i, data, len);
Do proper select-for-write on ptys. Currently, pasting a sufficiently large string into pterm in any circumstances in which it's echoed back to the terminal will cause a deadlock once the pty's write buffer fills up. [originally from svn r6582]
2006-02-23 13:38:44 +00:00
if (ret < 0 && (errno == EWOULDBLOCK)) {
/*
* We've sent all we can for the moment.
*/
break;
}
if (ret < 0) {
perror("write pty master");
exit(1);
}
bufchain_consume(&pty->output_data, ret);
}
uxpty: support SS_EOF, when in pipe mode. If the child process's standard input is provided by a pipe that's separate from its output channels, we can - and should - honour a request to cause that process to receive input EOF, by closing the output end of that pipe. As usual, we do this by setting a pending-EOF flag and calling try_write, to ensure that any buffered output data is sent before the pipe actually closes.
2018-10-18 17:04:31 +00:00
if (pty->pending_eof && bufchain_size(&pty->output_data) == 0) {
/* This should only happen if pty->master_i is a pipe that
* doesn't alias either output fd */
assert(pty->master_i != pty->master_o);
assert(pty->master_i != pty->master_e);
uxsel_del(pty->master_i);
close(pty->master_i);
pty->master_i = -1;
pty->pending_eof = FALSE;
}
Do proper select-for-write on ptys. Currently, pasting a sufficiently large string into pterm in any circumstances in which it's echoed back to the terminal will cause a deadlock once the pty's write buffer fills up. [originally from svn r6582]
2006-02-23 13:38:44 +00:00
pty_uxsel_setup(pty);
}
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
/*
* Called to send data down the pty.
*/
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
static int pty_send(Backend *be, const char *buf, int len)
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
Pty *pty = container_of(be, Pty, backend);
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
uxpty: support SS_EOF, when in pipe mode. If the child process's standard input is provided by a pipe that's separate from its output channels, we can - and should - honour a request to cause that process to receive input EOF, by closing the output end of that pipe. As usual, we do this by setting a pending-EOF flag and calling try_write, to ensure that any buffered output data is sent before the pipe actually closes.
2018-10-18 17:04:31 +00:00
if (pty->master_i < 0 || pty->pending_eof)
Do proper select-for-write on ptys. Currently, pasting a sufficiently large string into pterm in any circumstances in which it's echoed back to the terminal will cause a deadlock once the pty's write buffer fills up. [originally from svn r6582]
2006-02-23 13:38:44 +00:00
return 0; /* ignore all writes if fd closed */
Implement handling of all Close On Exit modes. Default is to close only on clean exit, which is a departure from most xterm-alikes but Ian reckons people will love me for it. If this turns out to be wrong, we can always change the default for Unix. [originally from svn r2120]
2002-10-23 14:21:12 +00:00
Do proper select-for-write on ptys. Currently, pasting a sufficiently large string into pterm in any circumstances in which it's echoed back to the terminal will cause a deadlock once the pty's write buffer fills up. [originally from svn r6582]
2006-02-23 13:38:44 +00:00
bufchain_add(&pty->output_data, buf, len);
pty_try_write(pty);
return bufchain_size(&pty->output_data);
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static void pty_close(Pty *pty)
Implement handling of all Close On Exit modes. Default is to close only on clean exit, which is a departure from most xterm-alikes but Ian reckons people will love me for it. If this turns out to be wrong, we can always change the default for Unix. [originally from svn r2120]
2002-10-23 14:21:12 +00:00
{
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
int i;
if (pty->master_o >= 0)
uxsel_del(pty->master_o);
if (pty->master_e >= 0)
uxsel_del(pty->master_e);
if (pty->master_i >= 0)
uxsel_del(pty->master_i);
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
if (pty->master_fd >= 0) {
close(pty->master_fd);
pty->master_fd = -1;
Implement handling of all Close On Exit modes. Default is to close only on clean exit, which is a departure from most xterm-alikes but Ian reckons people will love me for it. If this turns out to be wrong, we can always change the default for Unix. [originally from svn r2120]
2002-10-23 14:21:12 +00:00
}
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
for (i = 0; i < 6; i++) {
if (pty->pipefds[i] >= 0)
close(pty->pipefds[i]);
pty->pipefds[i] = -1;
}
pty->master_i = pty->master_o = pty->master_e = -1;
RJK's OS X portability patch: - initialise blank mbstate_t using memset rather than an ad-hoc initialiser. - expand the OMIT_UTMP ifdefs to enclose a load of entire functions that would generate `static function never called' warnings if left as empty shells. - couple of other fiddly things. [originally from svn r4896]
2004-11-24 11:36:08 +00:00
#ifndef OMIT_UTMP
I think I've just fixed Debian bug #166396. The +ut option was causing pty_utmp_helper_pipe to be closed, but its fd was kept around even when stale, and closed again when the main child process terminated - by which time the fd number had been reused for a rather more vital fd, which GTK didn't appreciate having closed under its feet. Hence, spin on POLLNVAL. Should now be sorted. [originally from svn r3185]
2003-05-11 12:28:53 +00:00
if (pty_utmp_helper_pipe >= 0) {
close(pty_utmp_helper_pipe); /* this causes utmp to be cleaned up */
pty_utmp_helper_pipe = -1;
}
RJK's OS X portability patch: - initialise blank mbstate_t using memset rather than an ad-hoc initialiser. - expand the OMIT_UTMP ifdefs to enclose a load of entire functions that would generate `static function never called' warnings if left as empty shells. - couple of other fiddly things. [originally from svn r4896]
2004-11-24 11:36:08 +00:00
#endif
Implement handling of all Close On Exit modes. Default is to close only on clean exit, which is a departure from most xterm-alikes but Ian reckons people will love me for it. If this turns out to be wrong, we can always change the default for Unix. [originally from svn r2120]
2002-10-23 14:21:12 +00:00
}
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
/*
* Called to query the current socket sendability status.
*/
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
static int pty_sendbuffer(Backend *be)
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
/* Pty *pty = container_of(be, Pty, backend); */
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
return 0;
}
/*
* Called to set the size of the window
*/
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
static void pty_size(Backend *be, int width, int height)
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
Pty *pty = container_of(be, Pty, backend);
Resizing of pterm now works, and the size information is correctly sent on to the pty. [originally from svn r2036]
2002-10-13 12:44:01 +00:00
struct winsize size;
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
int xpixel = 0, ypixel = 0;
Resizing of pterm now works, and the size information is correctly sent on to the pty. [originally from svn r2036]
2002-10-13 12:44:01 +00:00
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
pty->term_width = width;
pty->term_height = height;
Cleanups from yesterday's destabilisation: lots of stuff in terminal.c was apparently relying on implicit initialisation to zero, and also I've removed the backends' dependency on terminal.h by having terminal sizes explicitly passed in to back->size(). [originally from svn r2117]
2002-10-23 12:41:35 +00:00
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
if (pty->master_fd < 0)
return;
Change Seat's get_char_cell_size to get_window_pixel_size. That's more directly useful in uxpty.c (which is currently the only actual client of the function), and also matches the data that SSH clients send in "pty-req". Also, it makes that method behave more like the GUI query function get_window_pixels used by terminal.c (with the sole exception that unlike g_w_p it's allowed to return failure), so it becomes even more trivial to implement in the GUI front ends.
2018-10-13 06:37:24 +00:00
seat_get_window_pixel_size(pty->seat, &xpixel, &ypixel);
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
size.ws_row = (unsigned short)pty->term_height;
size.ws_col = (unsigned short)pty->term_width;
Change Seat's get_char_cell_size to get_window_pixel_size. That's more directly useful in uxpty.c (which is currently the only actual client of the function), and also matches the data that SSH clients send in "pty-req". Also, it makes that method behave more like the GUI query function get_window_pixels used by terminal.c (with the sole exception that unlike g_w_p it's allowed to return failure), so it becomes even more trivial to implement in the GUI front ends.
2018-10-13 06:37:24 +00:00
size.ws_xpixel = (unsigned short)xpixel;
size.ws_ypixel = (unsigned short)ypixel;
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
ioctl(pty->master_fd, TIOCSWINSZ, (void *)&size);
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
return;
}
/*
* Send special codes.
*/
Rework special-commands system to add an integer argument. In order to list cross-certifiable host keys in the GUI specials menu, the SSH backend has been inventing new values on the end of the Telnet_Special enumeration, starting from the value TS_LOCALSTART. This is inelegant, and also makes it awkward to break up special handlers (e.g. to dispatch different specials to different SSH layers), since if all you know about a special is that it's somewhere in the TS_LOCALSTART+n space, you can't tell what _general kind_ of thing it is. Also, if I ever need another open-ended set of specials in future, I'll have to remember which TS_LOCALSTART+n codes are in which set. So here's a revamp that causes every special to take an extra integer argument. For all previously numbered specials, this argument is passed as zero and ignored, but there's a new main special code for SSH host key cross-certification, in which the integer argument is an index into the backend's list of available keys. TS_LOCALSTART is now a thing of the past: if I need any other open-ended sets of specials in future, I can add a new top-level code with a nicely separated space of arguments. While I'm at it, I've removed the legacy misnomer 'Telnet_Special' from the code completely; the enum is now SessionSpecialCode, the struct containing full details of a menu entry is SessionSpecial, and the enum values now start SS_ rather than TS_.
2018-09-24 08:35:52 +00:00
static void pty_special(Backend *be, SessionSpecialCode code, int arg)
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
{
uxpty: support SS_SIG* and SS_BRK specials. The SS_SIGFOO family are implemented by sending a signal directly to the pid of the immediate child process. I had had the vague idea that it might be more desirable to send the specified signal to the foreground process group in the tty. That way, you'd be able to SIGINT (say) the foreground job in a shell session, and return to the shell _prompt_ without terminating the whole session, and you could do this in an emergency even if the job was a full-screen application which had configured termios so that no keystroke generated SIGINT. But as far as I can see there's no actual way to do that. I wasn't able to find any ioctl or termios call to send a signal to a pty's foreground pgrp, and you can't even do it manually via kill(2) because first you'd have to find out what the pgrp id _is_, and according to the man pages, you can only call tcgetpgrp on the slave end of the pty and even then only if it's your controlling terminal. So SS_SIGFOO goes to the child process, because that's the only place I can find that I _can_ send it to sensibly. SS_BRK translates to tcsendbreak, of course (though I haven't actually seen any effect of calling this on a pty master, not even if I set PARMRK on the slave end which by my understanding _ought_ to show me when break events occur).
2018-10-18 19:37:59 +00:00
Pty *pty = container_of(be, Pty, backend);
if (code == SS_BRK) {
uxpty: option to make three pipes instead of a pty. Not every "session" channel in SSH allocates a pty at all, of course, and so I'll need a way to run a subprocess without doing so. The simplest approach seems to be to expand uxpty's remit so that the pty is optional: now it can open either a pty or a set of pipes for stdin/out/err, according to an option provided to pty_backend_create. (It amuses me that without this option I'd have an SSH server which is incapable of _not_ honouring the "pty-req" channel request. That's normally the easy part!) This breaks the previous one-to-one coupling between pty backend instances and file descriptors passed to uxsel, which I was using to look up the Pty structure in a tree234 indexed by fd when an uxsel notification came back. So now each Pty structure contains a collection of subobjects of a new type PtyFd, and _those_ are what's stored in the fd-indexed tree. Another awkward part is that uxsel_set is not incremental: the rwx flags you pass to it completely supersede the previous set for that file descriptor, so I had to set up the logic that decides whether we're trying to read or write each fd in a way that can cope equally well with the fd aliasing another one (if it's the pty master) or not (if there are three completely separate pipes).
2018-10-18 19:31:13 +00:00
if (pty->master_fd >= 0)
tcsendbreak(pty->master_fd, 0);
uxpty: support SS_SIG* and SS_BRK specials. The SS_SIGFOO family are implemented by sending a signal directly to the pid of the immediate child process. I had had the vague idea that it might be more desirable to send the specified signal to the foreground process group in the tty. That way, you'd be able to SIGINT (say) the foreground job in a shell session, and return to the shell _prompt_ without terminating the whole session, and you could do this in an emergency even if the job was a full-screen application which had configured termios so that no keystroke generated SIGINT. But as far as I can see there's no actual way to do that. I wasn't able to find any ioctl or termios call to send a signal to a pty's foreground pgrp, and you can't even do it manually via kill(2) because first you'd have to find out what the pgrp id _is_, and according to the man pages, you can only call tcgetpgrp on the slave end of the pty and even then only if it's your controlling terminal. So SS_SIGFOO goes to the child process, because that's the only place I can find that I _can_ send it to sensibly. SS_BRK translates to tcsendbreak, of course (though I haven't actually seen any effect of calling this on a pty master, not even if I set PARMRK on the slave end which by my understanding _ought_ to show me when break events occur).
2018-10-18 19:37:59 +00:00
return;
}
uxpty: support SS_EOF, when in pipe mode. If the child process's standard input is provided by a pipe that's separate from its output channels, we can - and should - honour a request to cause that process to receive input EOF, by closing the output end of that pipe. As usual, we do this by setting a pending-EOF flag and calling try_write, to ensure that any buffered output data is sent before the pipe actually closes.
2018-10-18 17:04:31 +00:00
if (code == SS_EOF) {
if (pty->master_i >= 0 && pty->master_i != pty->master_fd) {
pty->pending_eof = TRUE;
pty_try_write(pty);
}
return;
}
uxpty: support SS_SIG* and SS_BRK specials. The SS_SIGFOO family are implemented by sending a signal directly to the pid of the immediate child process. I had had the vague idea that it might be more desirable to send the specified signal to the foreground process group in the tty. That way, you'd be able to SIGINT (say) the foreground job in a shell session, and return to the shell _prompt_ without terminating the whole session, and you could do this in an emergency even if the job was a full-screen application which had configured termios so that no keystroke generated SIGINT. But as far as I can see there's no actual way to do that. I wasn't able to find any ioctl or termios call to send a signal to a pty's foreground pgrp, and you can't even do it manually via kill(2) because first you'd have to find out what the pgrp id _is_, and according to the man pages, you can only call tcgetpgrp on the slave end of the pty and even then only if it's your controlling terminal. So SS_SIGFOO goes to the child process, because that's the only place I can find that I _can_ send it to sensibly. SS_BRK translates to tcsendbreak, of course (though I haven't actually seen any effect of calling this on a pty master, not even if I set PARMRK on the slave end which by my understanding _ought_ to show me when break events occur).
2018-10-18 19:37:59 +00:00
{
int sig = -1;
#define SIGNAL_SUB(name) if (code == SS_SIG ## name) sig = SIG ## name;
#define SIGNAL_MAIN(name, text) SIGNAL_SUB(name)
#define SIGNALS_LOCAL_ONLY
#include "sshsignals.h"
#undef SIGNAL_SUB
#undef SIGNAL_MAIN
#undef SIGNALS_LOCAL_ONLY
if (sig != -1) {
if (!pty->child_dead)
kill(pty->child_pid, sig);
return;
}
}
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
return;
}
Turned the old `Telnet Command' System-submenu into a more general `Special Command' menu, in which any backend can place its own list of magical things the user might want to ask the backend to do. In particular I've implemented the recently proposed "break" extension in SSH2 using this mechanism. NB this checkin slightly breaks the Mac build, since it needs to provide at least a stub form of update_specials_menu(). [originally from svn r3054]
2003-04-04 20:21:05 +00:00
/*
* Return a list of the special codes that make sense in this
* protocol.
*/
Rework special-commands system to add an integer argument. In order to list cross-certifiable host keys in the GUI specials menu, the SSH backend has been inventing new values on the end of the Telnet_Special enumeration, starting from the value TS_LOCALSTART. This is inelegant, and also makes it awkward to break up special handlers (e.g. to dispatch different specials to different SSH layers), since if all you know about a special is that it's somewhere in the TS_LOCALSTART+n space, you can't tell what _general kind_ of thing it is. Also, if I ever need another open-ended set of specials in future, I'll have to remember which TS_LOCALSTART+n codes are in which set. So here's a revamp that causes every special to take an extra integer argument. For all previously numbered specials, this argument is passed as zero and ignored, but there's a new main special code for SSH host key cross-certification, in which the integer argument is an index into the backend's list of available keys. TS_LOCALSTART is now a thing of the past: if I need any other open-ended sets of specials in future, I can add a new top-level code with a nicely separated space of arguments. While I'm at it, I've removed the legacy misnomer 'Telnet_Special' from the code completely; the enum is now SessionSpecialCode, the struct containing full details of a menu entry is SessionSpecial, and the enum values now start SS_ rather than TS_.
2018-09-24 08:35:52 +00:00
static const SessionSpecial *pty_get_specials(Backend *be)
Turned the old `Telnet Command' System-submenu into a more general `Special Command' menu, in which any backend can place its own list of magical things the user might want to ask the backend to do. In particular I've implemented the recently proposed "break" extension in SSH2 using this mechanism. NB this checkin slightly breaks the Mac build, since it needs to provide at least a stub form of update_specials_menu(). [originally from svn r3054]
2003-04-04 20:21:05 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
/* Pty *pty = container_of(be, Pty, backend); */
Turned the old `Telnet Command' System-submenu into a more general `Special Command' menu, in which any backend can place its own list of magical things the user might want to ask the backend to do. In particular I've implemented the recently proposed "break" extension in SSH2 using this mechanism. NB this checkin slightly breaks the Mac build, since it needs to provide at least a stub form of update_specials_menu(). [originally from svn r3054]
2003-04-04 20:21:05 +00:00
/*
* Hmm. When I get round to having this actually usable, it
* might be quite nice to have the ability to deliver a few
* well chosen signals to the child process - SIGINT, SIGTERM,
* SIGKILL at least.
*/
return NULL;
}
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
static int pty_connected(Backend *be)
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
/* Pty *pty = container_of(be, Pty, backend); */
The `socket' function in the backends is only ever checked to see if it's NULL. Since we already have one back end (uxpty) which doesn't in fact talk to a network socket, and may well have more soon, I'm replacing this TCP/IP-centric function with a nice neutral `connected' function returning a boolean. Nothing else about its semantics has currently changed. [originally from svn r6810]
2006-08-27 08:03:19 +00:00
return TRUE;
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
}
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
static int pty_sendok(Backend *be)
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
/* Pty *pty = container_of(be, Pty, backend); */
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
return 1;
}
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
static void pty_unthrottle(Backend *be, int backlog)
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
/* Pty *pty = container_of(be, Pty, backend); */
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
/* do nothing */
}
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
static int pty_ldisc(Backend *be, int option)
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
/* Pty *pty = container_of(be, Pty, backend); */
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
return 0; /* neither editing nor echoing */
}
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
static void pty_provide_ldisc(Backend *be, Ldisc *ldisc)
Line discipline module now uses dynamically allocated data. Also fixed one or two other minor problems. [originally from svn r2141]
2002-10-26 10:16:19 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
/* Pty *pty = container_of(be, Pty, backend); */
Line discipline module now uses dynamically allocated data. Also fixed one or two other minor problems. [originally from svn r2141]
2002-10-26 10:16:19 +00:00
/* This is a stub. */
}
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
static int pty_exitcode(Backend *be)
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
Pty *pty = container_of(be, Pty, backend);
Encapsulated most of the pty backend's variables into a proper data structure, in preparation for wanting more than one of them in a single process. This can't be done cleanly, because the whole business with pty_pre_init pre-allocating the pty rather assumes we want a known number of the things before we drop privileges; so there's a horrid hack to make pty_pre_init work on platforms that have at most one pty instance per process, but at the same time things ought to work sensibly with more than one per process _if_ pty_pre_init isn't required. [originally from svn r5261]
2005-02-06 15:14:34 +00:00
if (!pty->finished)
Implement handling of all Close On Exit modes. Default is to close only on clean exit, which is a departure from most xterm-alikes but Ian reckons people will love me for it. If this turns out to be wrong, we can always change the default for Unix. [originally from svn r2120]
2002-10-23 14:21:12 +00:00
return -1; /* not dead yet */
uxpty: new specialist backend-creation API. The function that does the main pty setup is now called pty_backend_create(), and has an API better suited to uxpty in particular than the standard backend_init() virtual constructor. It leaves off a load of standard parameters to backend_init() which aren't really relevant to this backend, and it adds the 'argv' parameter to pass in a split-up command line, which is unique to it. The old creation function still exists, as a tiny wrapper that calls the new pty_backend_create. And that version still gets the argv parameter from the process-global variable pty_argv[], so the call sites in pterm haven't had to change for this. This will make it possible to instantiate a pty backend directly from the SSH server code, without having to do anything really excessively cumbersome to pass in a subcommand in the form of pre-split argv. (And I'll add a few more specialist parameters to the new function shortly.)
2018-10-13 07:32:40 +00:00
else if (WIFSIGNALED(pty->exit_code))
return 128 + WTERMSIG(pty->exit_code);
Implement handling of all Close On Exit modes. Default is to close only on clean exit, which is a departure from most xterm-alikes but Ian reckons people will love me for it. If this turns out to be wrong, we can always change the default for Unix. [originally from svn r2120]
2002-10-23 14:21:12 +00:00
else
uxpty: new specialist backend-creation API. The function that does the main pty setup is now called pty_backend_create(), and has an API better suited to uxpty in particular than the standard backend_init() virtual constructor. It leaves off a load of standard parameters to backend_init() which aren't really relevant to this backend, and it adds the 'argv' parameter to pass in a split-up command line, which is unique to it. The old creation function still exists, as a tiny wrapper that calls the new pty_backend_create. And that version still gets the argv parameter from the process-global variable pty_argv[], so the call sites in pterm haven't had to change for this. This will make it possible to instantiate a pty backend directly from the SSH server code, without having to do anything really excessively cumbersome to pass in a subcommand in the form of pre-split argv. (And I'll add a few more specialist parameters to the new function shortly.)
2018-10-13 07:32:40 +00:00
return WEXITSTATUS(pty->exit_code);
}
ptrlen pty_backend_exit_signame(Backend *be, char **aux_msg)
{
Pty *pty = container_of(be, Pty, backend);
int sig;
*aux_msg = NULL;
if (!pty->finished || !WIFSIGNALED(pty->exit_code))
return PTRLEN_LITERAL("");
sig = WTERMSIG(pty->exit_code);
#define TRANSLATE_SIGNAL(s) do \
{ \
if (sig == SIG ## s) \
return PTRLEN_LITERAL(#s); \
} while (0)
#ifdef SIGABRT
TRANSLATE_SIGNAL(ABRT);
#endif
#ifdef SIGALRM
TRANSLATE_SIGNAL(ALRM);
#endif
#ifdef SIGFPE
TRANSLATE_SIGNAL(FPE);
#endif
#ifdef SIGHUP
TRANSLATE_SIGNAL(HUP);
#endif
#ifdef SIGILL
TRANSLATE_SIGNAL(ILL);
#endif
#ifdef SIGINT
TRANSLATE_SIGNAL(INT);
#endif
#ifdef SIGKILL
TRANSLATE_SIGNAL(KILL);
#endif
#ifdef SIGPIPE
TRANSLATE_SIGNAL(PIPE);
#endif
#ifdef SIGQUIT
TRANSLATE_SIGNAL(QUIT);
#endif
#ifdef SIGSEGV
TRANSLATE_SIGNAL(SEGV);
#endif
#ifdef SIGTERM
TRANSLATE_SIGNAL(TERM);
#endif
#ifdef SIGUSR1
TRANSLATE_SIGNAL(USR1);
#endif
#ifdef SIGUSR2
TRANSLATE_SIGNAL(USR2);
#endif
#undef TRANSLATE_SIGNAL
*aux_msg = dupprintf("untranslatable signal number %d: %s",
sig, strsignal(sig));
return PTRLEN_LITERAL("HUP"); /* need some kind of default */
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
}
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
static int pty_cfg_info(Backend *be)
Loose end from r5031: the Kex panel should only be displayed in mid-session if we are not using SSHv1. I've done this by introducing a generic `cfg_info' function which every back end can use to communicate an int's worth of data to setup_config_box; in SSH that's the protocol version in use, and in everything else it's currently zero. [originally from svn r5040] [r5031 == d77102a8d535a7000d6d909529a61a1564f6d678]
2004-12-29 12:32:25 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
/* Pty *pty = container_of(be, Pty, backend); */
Loose end from r5031: the Kex panel should only be displayed in mid-session if we are not using SSHv1. I've done this by introducing a generic `cfg_info' function which every back end can use to communicate an int's worth of data to setup_config_box; in SSH that's the protocol version in use, and in everything else it's currently zero. [originally from svn r5040] [r5031 == d77102a8d535a7000d6d909529a61a1564f6d678]
2004-12-29 12:32:25 +00:00
return 0;
}
Name vtable structure types more consistently. Now they're all called FooVtable, instead of a mixture of that and Foo_vtable.
2018-10-05 06:03:46 +00:00
const struct BackendVtable pty_backend = {
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
pty_init,
Add a stub "free" routine for pterm. Thanks to rjk. [originally from svn r2666]
2003-01-20 20:10:07 +00:00
pty_free,
The back ends now contain their own copies of the Config structure, and have a function to pass in a new one. (Well, actually several back ends don't actually bother to do this because they need nothing out of Config after the initial setup phase, but they could if they wanted to.) [originally from svn r2561]
2003-01-12 14:48:29 +00:00
pty_reconfig,
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
pty_send,
pty_sendbuffer,
pty_size,
pty_special,
Turned the old `Telnet Command' System-submenu into a more general `Special Command' menu, in which any backend can place its own list of magical things the user might want to ask the backend to do. In particular I've implemented the recently proposed "break" extension in SSH2 using this mechanism. NB this checkin slightly breaks the Mac build, since it needs to provide at least a stub form of update_specials_menu(). [originally from svn r3054]
2003-04-04 20:21:05 +00:00
pty_get_specials,
The `socket' function in the backends is only ever checked to see if it's NULL. Since we already have one back end (uxpty) which doesn't in fact talk to a network socket, and may well have more soon, I'm replacing this TCP/IP-centric function with a nice neutral `connected' function returning a boolean. Nothing else about its semantics has currently changed. [originally from svn r6810]
2006-08-27 08:03:19 +00:00
pty_connected,
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
pty_exitcode,
pty_sendok,
pty_ldisc,
Line discipline module now uses dynamically allocated data. Also fixed one or two other minor problems. [originally from svn r2141]
2002-10-26 10:16:19 +00:00
pty_provide_ldisc,
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
pty_unthrottle,
Loose end from r5031: the Kex panel should only be displayed in mid-session if we are not using SSHv1. I've done this by introducing a generic `cfg_info' function which every back end can use to communicate an int's worth of data to setup_config_box; in SSH that's the protocol version in use, and in everything else it's currently zero. [originally from svn r5040] [r5031 == d77102a8d535a7000d6d909529a61a1564f6d678]
2004-12-29 12:32:25 +00:00
pty_cfg_info,
New Plink operating mode: 'plink -shareexists'. A Plink invocation of the form 'plink -shareexists <session>' tests for a currently live connection-sharing upstream for the session in question. <session> can be any syntax you'd use with Plink to make the actual connection (a host/port number, a bare saved session name, -load, whatever). I envisage this being useful for things like adaptive proxying - e.g. if you want to connect to host A which you can't route to directly, and you might already have a connection to either of hosts B or C which are viable proxies, then you could write a proxy shell script which checks whether you already have an upstream for B or C and goes via whichever one is currently active. Testing for the upstream's existence has to be done by actually connecting to its socket, because on Unix the mere existence of a Unix-domain socket file doesn't guarantee that there's a process listening to it. So we make a test connection, and then immediately disconnect; hence, that shows up in the upstream's event log.
2015-09-25 10:46:28 +00:00
NULL /* test_for_upstream */,
Rationalise access to, and content of, backends[] array. Should be no significant change in behaviour. (Well, entering usernames containing commas on Plink's command line will be a little harder now.) [originally from svn r7628]
2007-06-30 21:56:44 +00:00
"pty",
-1,
Implement Marcin Bulandra's suggestion of only automatically updating the port number in the GUI when the connection type is changed if the current port number is the standard one for the current protocol. It's not perfect, but it should make the common case of tabbing through the Session panel easier when starting non-SSH connections on odd ports. [originally from svn r7635]
2007-07-01 15:47:31 +00:00
0
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
};
Reference in New Issue Copy Permalink