2002-10-25 11:50:51 +00:00
|
|
|
/*
|
|
|
|
|
* Pseudo-tty backend for pterm.
|
|
|
|
|
*/
|
|
|
|
|
|
2003-03-29 18:30:14 +00:00
|
|
|
#define _GNU_SOURCE
|
2002-10-10 12:40:05 +00:00
|
|
|
|
2002-10-09 18:09:42 +00:00
|
|
|
#include <stdio.h>
|
|
|
|
|
#include <stdlib.h>
|
2002-10-10 12:40:05 +00:00
|
|
|
#include <string.h>
|
|
|
|
|
#include <unistd.h>
|
2002-10-14 09:18:34 +00:00
|
|
|
#include <signal.h>
|
2006-02-23 13:38:44 +00:00
|
|
|
#include <assert.h>
|
2002-10-10 12:40:05 +00:00
|
|
|
#include <fcntl.h>
|
2002-10-13 12:44:01 +00:00
|
|
|
#include <termios.h>
|
2002-10-15 10:49:38 +00:00
|
|
|
#include <grp.h>
|
2021-05-13 17:40:05 +00:00
|
|
|
#if HAVE_UTMP_H
|
2002-10-15 12:29:52 +00:00
|
|
|
#include <utmp.h>
|
2021-05-13 17:40:05 +00:00
|
|
|
#endif
|
2002-10-15 12:29:52 +00:00
|
|
|
#include <pwd.h>
|
|
|
|
|
#include <time.h>
|
2002-10-14 09:18:34 +00:00
|
|
|
#include <sys/types.h>
|
2004-11-24 11:36:08 +00:00
|
|
|
#include <sys/stat.h>
|
2002-10-14 09:18:34 +00:00
|
|
|
#include <sys/wait.h>
|
2002-10-13 12:44:01 +00:00
|
|
|
#include <sys/ioctl.h>
|
2002-11-02 14:35:57 +00:00
|
|
|
#include <errno.h>
|
2018-10-18 19:37:33 +00:00
|
|
|
#include <termios.h>
|
2002-10-09 18:09:42 +00:00
|
|
|
|
|
|
|
|
#include "putty.h"
|
2018-10-18 19:37:33 +00:00
|
|
|
#include "ssh.h"
|
2021-04-22 16:58:40 +00:00
|
|
|
#include "ssh/server.h" /* to check the prototypes of server-needed things */
|
2005-02-06 15:14:34 +00:00
|
|
|
#include "tree234.h"
|
2002-10-09 18:09:42 +00:00
|
|
|
|
2005-05-09 13:27:51 +00:00
|
|
|
#ifndef OMIT_UTMP
|
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"
|
2002-10-15 12:29:52 +00:00
|
|
|
#endif
|
|
|
|
|
#endif
|
2005-04-25 23:28:25 +00:00
|
|
|
|
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
|
|
|
|
|
|
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;
|
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 */
|
|
|
|
|
|
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;
|
2018-10-18 19:31:13 +00:00
|
|
|
|
2005-02-06 15:14:34 +00:00
|
|
|
int master_fd, slave_fd;
|
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;
|
2021-12-19 11:15:50 +00:00
|
|
|
size_t output_backlog;
|
2005-02-06 15:14:34 +00:00
|
|
|
char name[FILENAME_MAX];
|
2011-03-01 23:00:32 +00:00
|
|
|
pid_t child_pid;
|
2005-02-06 15:14:34 +00:00
|
|
|
int term_width, term_height;
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
bool child_dead, finished;
|
2005-02-06 15:14:34 +00:00
|
|
|
int exit_code;
|
2006-02-23 13:38:44 +00:00
|
|
|
bufchain output_data;
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
bool pending_eof;
|
2018-09-11 15:23:38 +00:00
|
|
|
Backend backend;
|
2005-02-06 15:14:34 +00:00
|
|
|
};
|
|
|
|
|
|
2021-12-19 11:15:50 +00:00
|
|
|
#define PTY_MAX_BACKLOG 32768
|
|
|
|
|
|
2005-02-06 15:14:34 +00:00
|
|
|
/*
|
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.
|
2005-02-06 15:14:34 +00:00
|
|
|
*/
|
2018-10-18 19:31:13 +00:00
|
|
|
static int ptyfd_compare(void *av, void *bv)
|
2005-02-06 15:14:34 +00:00
|
|
|
{
|
2018-10-18 19:31:13 +00:00
|
|
|
PtyFd *a = (PtyFd *)av;
|
|
|
|
|
PtyFd *b = (PtyFd *)bv;
|
2005-02-06 15:14:34 +00:00
|
|
|
|
2018-10-18 19:31:13 +00:00
|
|
|
if (a->fd < b->fd)
|
2019-09-08 19:29:00 +00:00
|
|
|
return -1;
|
2018-10-18 19:31:13 +00:00
|
|
|
else if (a->fd > b->fd)
|
2019-09-08 19:29:00 +00:00
|
|
|
return +1;
|
2005-02-06 15:14:34 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-18 19:31:13 +00:00
|
|
|
static int ptyfd_find(void *av, void *bv)
|
2005-02-06 15:14:34 +00:00
|
|
|
{
|
|
|
|
|
int a = *(int *)av;
|
2018-10-18 19:31:13 +00:00
|
|
|
PtyFd *b = (PtyFd *)bv;
|
2005-02-06 15:14:34 +00:00
|
|
|
|
2018-10-18 19:31:13 +00:00
|
|
|
if (a < b->fd)
|
2019-09-08 19:29:00 +00:00
|
|
|
return -1;
|
2018-10-18 19:31:13 +00:00
|
|
|
else if (a > b->fd)
|
2019-09-08 19:29:00 +00:00
|
|
|
return +1;
|
2005-02-06 15:14:34 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
2002-10-10 12:40:05 +00:00
|
|
|
|
2018-10-18 19:31:13 +00:00
|
|
|
static tree234 *ptyfds = NULL;
|
2005-02-06 15:14:34 +00:00
|
|
|
|
|
|
|
|
/*
|
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.
|
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;
|
2005-02-06 15:14:34 +00:00
|
|
|
|
|
|
|
|
if (a->child_pid < b->child_pid)
|
2019-09-08 19:29:00 +00:00
|
|
|
return -1;
|
2005-02-06 15:14:34 +00:00
|
|
|
else if (a->child_pid > b->child_pid)
|
2019-09-08 19:29:00 +00:00
|
|
|
return +1;
|
2005-02-06 15:14:34 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int pty_find_by_pid(void *av, void *bv)
|
|
|
|
|
{
|
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;
|
2005-02-06 15:14:34 +00:00
|
|
|
|
|
|
|
|
if (a < b->child_pid)
|
2019-09-08 19:29:00 +00:00
|
|
|
return -1;
|
2005-02-06 15:14:34 +00:00
|
|
|
else if (a > b->child_pid)
|
2019-09-08 19:29:00 +00:00
|
|
|
return +1;
|
2005-02-06 15:14:34 +00:00
|
|
|
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.
|
2019-09-08 19:29:00 +00:00
|
|
|
*
|
2005-02-06 15:14:34 +00:00
|
|
|
* 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.
|
2019-09-08 19:29:00 +00:00
|
|
|
*
|
2005-02-06 15:14:34 +00:00
|
|
|
* 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;
|
2003-03-29 18:30:14 +00:00
|
|
|
|
2004-11-24 11:36:08 +00:00
|
|
|
#ifndef OMIT_UTMP
|
2011-09-19 16:38:23 +00:00
|
|
|
static pid_t pty_utmp_helper_pid = -1;
|
|
|
|
|
static int pty_utmp_helper_pipe = -1;
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
static bool pty_stamped_utmp;
|
2005-04-25 23:28:25 +00:00
|
|
|
static struct utmpx utmp_entry;
|
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;
|
|
|
|
|
|
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);
|
2004-11-24 11:36:08 +00:00
|
|
|
|
2005-02-06 15:14:34 +00:00
|
|
|
#ifndef OMIT_UTMP
|
2002-10-16 12:17:51 +00:00
|
|
|
static void setup_utmp(char *ttyname, char *location)
|
2002-10-15 12:29:52 +00:00
|
|
|
{
|
Replace mkfiles.pl with a CMake build system.
This brings various concrete advantages over the previous system:
- consistent support for out-of-tree builds on all platforms
- more thorough support for Visual Studio IDE project files
- support for Ninja-based builds, which is particularly useful on
Windows where the alternative nmake has no parallel option
- a really simple set of build instructions that work the same way on
all the major platforms (look how much shorter README is!)
- better decoupling of the project configuration from the toolchain
configuration, so that my Windows cross-building doesn't need
(much) special treatment in CMakeLists.txt
- configure-time tests on Windows as well as Linux, so that a lot of
ad-hoc #ifdefs second-guessing a particular feature's presence from
the compiler version can now be replaced by tests of the feature
itself
Also some longer-term software-engineering advantages:
- other people have actually heard of CMake, so they'll be able to
produce patches to the new build setup more easily
- unlike the old mkfiles.pl, CMake is not my personal problem to
maintain
- most importantly, mkfiles.pl was just a horrible pile of
unmaintainable cruft, which even I found it painful to make changes
to or to use, and desperately needed throwing in the bin. I've
already thrown away all the variants of it I had in other projects
of mine, and was only delaying this one so we could make the 0.75
release branch first.
This change comes with a noticeable build-level restructuring. The
previous Recipe worked by compiling every object file exactly once,
and then making each executable by linking a precisely specified
subset of the same object files. But in CMake, that's not the natural
way to work - if you write the obvious command that puts the same
source file into two executable targets, CMake generates a makefile
that compiles it once per target. That can be an advantage, because it
gives you the freedom to compile it differently in each case (e.g.
with a #define telling it which program it's part of). But in a
project that has many executable targets and had carefully contrived
to _never_ need to build any module more than once, all it does is
bloat the build time pointlessly!
To avoid slowing down the build by a large factor, I've put most of
the modules of the code base into a collection of static libraries
organised vaguely thematically (SSH, other backends, crypto, network,
...). That means all those modules can still be compiled just once
each, because once each library is built it's reused unchanged for all
the executable targets.
One upside of this library-based structure is that now I don't have to
manually specify exactly which objects go into which programs any more
- it's enough to specify which libraries are needed, and the linker
will figure out the fine detail automatically. So there's less
maintenance to do in CMakeLists.txt when the source code changes.
But that reorganisation also adds fragility, because of the trad Unix
linker semantics of walking along the library list once each, so that
cyclic references between your libraries will provoke link errors. The
current setup builds successfully, but I suspect it only just manages
it.
(In particular, I've found that MinGW is the most finicky on this
score of the Windows compilers I've tried building with. So I've
included a MinGW test build in the new-look Buildscr, because
otherwise I think there'd be a significant risk of introducing
MinGW-only build failures due to library search order, which wasn't a
risk in the previous library-free build organisation.)
In the longer term I hope to be able to reduce the risk of that, via
gradual reorganisation (in particular, breaking up too-monolithic
modules, to reduce the risk of knock-on references when you included a
module for function A and it also contains function B with an
unsatisfied dependency you didn't really need). Ideally I want to
reach a state in which the libraries all have sensibly described
purposes, a clearly documented (partial) order in which they're
permitted to depend on each other, and a specification of what stubs
you have to put where if you're leaving one of them out (e.g.
nocrypto) and what callbacks you have to define in your non-library
objects to satisfy dependencies from things low in the stack (e.g.
out_of_memory()).
One thing that's gone completely missing in this migration,
unfortunately, is the unfinished MacOS port linked against Quartz GTK.
That's because it turned out that I can't currently build it myself,
on my own Mac: my previous installation of GTK had bit-rotted as a
side effect of an Xcode upgrade, and I haven't yet been able to
persuade jhbuild to make me a new one. So I can't even build the MacOS
port with the _old_ makefiles, and hence, I have no way of checking
that the new ones also work. I hope to bring that port back to life at
some point, but I don't want it to block the rest of this change.
2021-04-10 14:21:11 +00:00
|
|
|
#if HAVE_LASTLOG
|
2002-10-15 12:29:52 +00:00
|
|
|
struct lastlog lastlog_entry;
|
|
|
|
|
FILE *lastlog;
|
|
|
|
|
#endif
|
|
|
|
|
struct passwd *pw;
|
2005-04-25 23:28:25 +00:00
|
|
|
struct timeval tv;
|
2002-10-15 12:29:52 +00:00
|
|
|
|
|
|
|
|
pw = getpwuid(getuid());
|
2020-06-16 16:47:20 +00:00
|
|
|
if (!pw)
|
|
|
|
|
return; /* can't stamp utmp if we don't have a username */
|
2002-10-15 12:29:52 +00:00
|
|
|
memset(&utmp_entry, 0, sizeof(utmp_entry));
|
|
|
|
|
utmp_entry.ut_type = USER_PROCESS;
|
|
|
|
|
utmp_entry.ut_pid = getpid();
|
2018-09-26 13:20:25 +00:00
|
|
|
#if __GNUC__ >= 8
|
|
|
|
|
# pragma GCC diagnostic push
|
|
|
|
|
# pragma GCC diagnostic ignored "-Wstringop-truncation"
|
|
|
|
|
#endif // __GNUC__ >= 8
|
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));
|
2018-09-26 13:20:25 +00:00
|
|
|
#if __GNUC__ >= 8
|
|
|
|
|
# pragma GCC diagnostic pop
|
|
|
|
|
#endif // __GNUC__ >= 8
|
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;
|
2002-10-15 12:29:52 +00:00
|
|
|
|
2005-04-25 23:28:25 +00:00
|
|
|
setutxent();
|
|
|
|
|
pututxline(&utmp_entry);
|
|
|
|
|
endutxent();
|
|
|
|
|
|
Replace mkfiles.pl with a CMake build system.
This brings various concrete advantages over the previous system:
- consistent support for out-of-tree builds on all platforms
- more thorough support for Visual Studio IDE project files
- support for Ninja-based builds, which is particularly useful on
Windows where the alternative nmake has no parallel option
- a really simple set of build instructions that work the same way on
all the major platforms (look how much shorter README is!)
- better decoupling of the project configuration from the toolchain
configuration, so that my Windows cross-building doesn't need
(much) special treatment in CMakeLists.txt
- configure-time tests on Windows as well as Linux, so that a lot of
ad-hoc #ifdefs second-guessing a particular feature's presence from
the compiler version can now be replaced by tests of the feature
itself
Also some longer-term software-engineering advantages:
- other people have actually heard of CMake, so they'll be able to
produce patches to the new build setup more easily
- unlike the old mkfiles.pl, CMake is not my personal problem to
maintain
- most importantly, mkfiles.pl was just a horrible pile of
unmaintainable cruft, which even I found it painful to make changes
to or to use, and desperately needed throwing in the bin. I've
already thrown away all the variants of it I had in other projects
of mine, and was only delaying this one so we could make the 0.75
release branch first.
This change comes with a noticeable build-level restructuring. The
previous Recipe worked by compiling every object file exactly once,
and then making each executable by linking a precisely specified
subset of the same object files. But in CMake, that's not the natural
way to work - if you write the obvious command that puts the same
source file into two executable targets, CMake generates a makefile
that compiles it once per target. That can be an advantage, because it
gives you the freedom to compile it differently in each case (e.g.
with a #define telling it which program it's part of). But in a
project that has many executable targets and had carefully contrived
to _never_ need to build any module more than once, all it does is
bloat the build time pointlessly!
To avoid slowing down the build by a large factor, I've put most of
the modules of the code base into a collection of static libraries
organised vaguely thematically (SSH, other backends, crypto, network,
...). That means all those modules can still be compiled just once
each, because once each library is built it's reused unchanged for all
the executable targets.
One upside of this library-based structure is that now I don't have to
manually specify exactly which objects go into which programs any more
- it's enough to specify which libraries are needed, and the linker
will figure out the fine detail automatically. So there's less
maintenance to do in CMakeLists.txt when the source code changes.
But that reorganisation also adds fragility, because of the trad Unix
linker semantics of walking along the library list once each, so that
cyclic references between your libraries will provoke link errors. The
current setup builds successfully, but I suspect it only just manages
it.
(In particular, I've found that MinGW is the most finicky on this
score of the Windows compilers I've tried building with. So I've
included a MinGW test build in the new-look Buildscr, because
otherwise I think there'd be a significant risk of introducing
MinGW-only build failures due to library search order, which wasn't a
risk in the previous library-free build organisation.)
In the longer term I hope to be able to reduce the risk of that, via
gradual reorganisation (in particular, breaking up too-monolithic
modules, to reduce the risk of knock-on references when you included a
module for function A and it also contains function B with an
unsatisfied dependency you didn't really need). Ideally I want to
reach a state in which the libraries all have sensibly described
purposes, a clearly documented (partial) order in which they're
permitted to depend on each other, and a specification of what stubs
you have to put where if you're leaving one of them out (e.g.
nocrypto) and what callbacks you have to define in your non-library
objects to satisfy dependencies from things low in the stack (e.g.
out_of_memory()).
One thing that's gone completely missing in this migration,
unfortunately, is the unfinished MacOS port linked against Quartz GTK.
That's because it turned out that I can't currently build it myself,
on my own Mac: my previous installation of GTK had bit-rotted as a
side effect of an Xcode upgrade, and I haven't yet been able to
persuade jhbuild to make me a new one. So I can't even build the MacOS
port with the _old_ makefiles, and hence, I have no way of checking
that the new ones also work. I hope to bring that port back to life at
some point, but I don't want it to block the rest of this change.
2021-04-10 14:21:11 +00:00
|
|
|
#if HAVE_UPDWTMPX
|
2022-05-18 17:48:28 +00:00
|
|
|
/* Reportedly, AIX 5.1 has <utmpx.h> and pututxline(), but no
|
|
|
|
|
* updwtmpx(). */
|
2005-04-25 23:28:25 +00:00
|
|
|
updwtmpx(WTMPX_FILE, &utmp_entry);
|
Replace mkfiles.pl with a CMake build system.
This brings various concrete advantages over the previous system:
- consistent support for out-of-tree builds on all platforms
- more thorough support for Visual Studio IDE project files
- support for Ninja-based builds, which is particularly useful on
Windows where the alternative nmake has no parallel option
- a really simple set of build instructions that work the same way on
all the major platforms (look how much shorter README is!)
- better decoupling of the project configuration from the toolchain
configuration, so that my Windows cross-building doesn't need
(much) special treatment in CMakeLists.txt
- configure-time tests on Windows as well as Linux, so that a lot of
ad-hoc #ifdefs second-guessing a particular feature's presence from
the compiler version can now be replaced by tests of the feature
itself
Also some longer-term software-engineering advantages:
- other people have actually heard of CMake, so they'll be able to
produce patches to the new build setup more easily
- unlike the old mkfiles.pl, CMake is not my personal problem to
maintain
- most importantly, mkfiles.pl was just a horrible pile of
unmaintainable cruft, which even I found it painful to make changes
to or to use, and desperately needed throwing in the bin. I've
already thrown away all the variants of it I had in other projects
of mine, and was only delaying this one so we could make the 0.75
release branch first.
This change comes with a noticeable build-level restructuring. The
previous Recipe worked by compiling every object file exactly once,
and then making each executable by linking a precisely specified
subset of the same object files. But in CMake, that's not the natural
way to work - if you write the obvious command that puts the same
source file into two executable targets, CMake generates a makefile
that compiles it once per target. That can be an advantage, because it
gives you the freedom to compile it differently in each case (e.g.
with a #define telling it which program it's part of). But in a
project that has many executable targets and had carefully contrived
to _never_ need to build any module more than once, all it does is
bloat the build time pointlessly!
To avoid slowing down the build by a large factor, I've put most of
the modules of the code base into a collection of static libraries
organised vaguely thematically (SSH, other backends, crypto, network,
...). That means all those modules can still be compiled just once
each, because once each library is built it's reused unchanged for all
the executable targets.
One upside of this library-based structure is that now I don't have to
manually specify exactly which objects go into which programs any more
- it's enough to specify which libraries are needed, and the linker
will figure out the fine detail automatically. So there's less
maintenance to do in CMakeLists.txt when the source code changes.
But that reorganisation also adds fragility, because of the trad Unix
linker semantics of walking along the library list once each, so that
cyclic references between your libraries will provoke link errors. The
current setup builds successfully, but I suspect it only just manages
it.
(In particular, I've found that MinGW is the most finicky on this
score of the Windows compilers I've tried building with. So I've
included a MinGW test build in the new-look Buildscr, because
otherwise I think there'd be a significant risk of introducing
MinGW-only build failures due to library search order, which wasn't a
risk in the previous library-free build organisation.)
In the longer term I hope to be able to reduce the risk of that, via
gradual reorganisation (in particular, breaking up too-monolithic
modules, to reduce the risk of knock-on references when you included a
module for function A and it also contains function B with an
unsatisfied dependency you didn't really need). Ideally I want to
reach a state in which the libraries all have sensibly described
purposes, a clearly documented (partial) order in which they're
permitted to depend on each other, and a specification of what stubs
you have to put where if you're leaving one of them out (e.g.
nocrypto) and what callbacks you have to define in your non-library
objects to satisfy dependencies from things low in the stack (e.g.
out_of_memory()).
One thing that's gone completely missing in this migration,
unfortunately, is the unfinished MacOS port linked against Quartz GTK.
That's because it turned out that I can't currently build it myself,
on my own Mac: my previous installation of GTK had bit-rotted as a
side effect of an Xcode upgrade, and I haven't yet been able to
persuade jhbuild to make me a new one. So I can't even build the MacOS
port with the _old_ makefiles, and hence, I have no way of checking
that the new ones also work. I hope to bring that port back to life at
some point, but I don't want it to block the rest of this change.
2021-04-10 14:21:11 +00:00
|
|
|
#endif
|
2002-10-15 12:29:52 +00:00
|
|
|
|
Replace mkfiles.pl with a CMake build system.
This brings various concrete advantages over the previous system:
- consistent support for out-of-tree builds on all platforms
- more thorough support for Visual Studio IDE project files
- support for Ninja-based builds, which is particularly useful on
Windows where the alternative nmake has no parallel option
- a really simple set of build instructions that work the same way on
all the major platforms (look how much shorter README is!)
- better decoupling of the project configuration from the toolchain
configuration, so that my Windows cross-building doesn't need
(much) special treatment in CMakeLists.txt
- configure-time tests on Windows as well as Linux, so that a lot of
ad-hoc #ifdefs second-guessing a particular feature's presence from
the compiler version can now be replaced by tests of the feature
itself
Also some longer-term software-engineering advantages:
- other people have actually heard of CMake, so they'll be able to
produce patches to the new build setup more easily
- unlike the old mkfiles.pl, CMake is not my personal problem to
maintain
- most importantly, mkfiles.pl was just a horrible pile of
unmaintainable cruft, which even I found it painful to make changes
to or to use, and desperately needed throwing in the bin. I've
already thrown away all the variants of it I had in other projects
of mine, and was only delaying this one so we could make the 0.75
release branch first.
This change comes with a noticeable build-level restructuring. The
previous Recipe worked by compiling every object file exactly once,
and then making each executable by linking a precisely specified
subset of the same object files. But in CMake, that's not the natural
way to work - if you write the obvious command that puts the same
source file into two executable targets, CMake generates a makefile
that compiles it once per target. That can be an advantage, because it
gives you the freedom to compile it differently in each case (e.g.
with a #define telling it which program it's part of). But in a
project that has many executable targets and had carefully contrived
to _never_ need to build any module more than once, all it does is
bloat the build time pointlessly!
To avoid slowing down the build by a large factor, I've put most of
the modules of the code base into a collection of static libraries
organised vaguely thematically (SSH, other backends, crypto, network,
...). That means all those modules can still be compiled just once
each, because once each library is built it's reused unchanged for all
the executable targets.
One upside of this library-based structure is that now I don't have to
manually specify exactly which objects go into which programs any more
- it's enough to specify which libraries are needed, and the linker
will figure out the fine detail automatically. So there's less
maintenance to do in CMakeLists.txt when the source code changes.
But that reorganisation also adds fragility, because of the trad Unix
linker semantics of walking along the library list once each, so that
cyclic references between your libraries will provoke link errors. The
current setup builds successfully, but I suspect it only just manages
it.
(In particular, I've found that MinGW is the most finicky on this
score of the Windows compilers I've tried building with. So I've
included a MinGW test build in the new-look Buildscr, because
otherwise I think there'd be a significant risk of introducing
MinGW-only build failures due to library search order, which wasn't a
risk in the previous library-free build organisation.)
In the longer term I hope to be able to reduce the risk of that, via
gradual reorganisation (in particular, breaking up too-monolithic
modules, to reduce the risk of knock-on references when you included a
module for function A and it also contains function B with an
unsatisfied dependency you didn't really need). Ideally I want to
reach a state in which the libraries all have sensibly described
purposes, a clearly documented (partial) order in which they're
permitted to depend on each other, and a specification of what stubs
you have to put where if you're leaving one of them out (e.g.
nocrypto) and what callbacks you have to define in your non-library
objects to satisfy dependencies from things low in the stack (e.g.
out_of_memory()).
One thing that's gone completely missing in this migration,
unfortunately, is the unfinished MacOS port linked against Quartz GTK.
That's because it turned out that I can't currently build it myself,
on my own Mac: my previous installation of GTK had bit-rotted as a
side effect of an Xcode upgrade, and I haven't yet been able to
persuade jhbuild to make me a new one. So I can't even build the MacOS
port with the _old_ makefiles, and hence, I have no way of checking
that the new ones also work. I hope to bring that port back to life at
some point, but I don't want it to block the rest of this change.
2021-04-10 14:21:11 +00:00
|
|
|
#if HAVE_LASTLOG
|
2002-10-15 12:29:52 +00:00
|
|
|
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) {
|
2019-09-08 19:29:00 +00:00
|
|
|
fseek(lastlog, sizeof(lastlog_entry) * getuid(), SEEK_SET);
|
|
|
|
|
fwrite(&lastlog_entry, 1, sizeof(lastlog_entry), lastlog);
|
|
|
|
|
fclose(lastlog);
|
2002-10-15 12:29:52 +00:00
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
pty_stamped_utmp = true;
|
2002-10-15 12:42:58 +00:00
|
|
|
|
2002-10-15 12:29:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void cleanup_utmp(void)
|
|
|
|
|
{
|
2005-04-25 23:28:25 +00:00
|
|
|
struct timeval tv;
|
2002-10-15 12:29:52 +00:00
|
|
|
|
2002-10-16 12:17:51 +00:00
|
|
|
if (!pty_stamped_utmp)
|
2019-09-08 19:29:00 +00:00
|
|
|
return;
|
2002-10-15 12:42:58 +00:00
|
|
|
|
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));
|
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;
|
2002-10-15 12:29:52 +00:00
|
|
|
|
Replace mkfiles.pl with a CMake build system.
This brings various concrete advantages over the previous system:
- consistent support for out-of-tree builds on all platforms
- more thorough support for Visual Studio IDE project files
- support for Ninja-based builds, which is particularly useful on
Windows where the alternative nmake has no parallel option
- a really simple set of build instructions that work the same way on
all the major platforms (look how much shorter README is!)
- better decoupling of the project configuration from the toolchain
configuration, so that my Windows cross-building doesn't need
(much) special treatment in CMakeLists.txt
- configure-time tests on Windows as well as Linux, so that a lot of
ad-hoc #ifdefs second-guessing a particular feature's presence from
the compiler version can now be replaced by tests of the feature
itself
Also some longer-term software-engineering advantages:
- other people have actually heard of CMake, so they'll be able to
produce patches to the new build setup more easily
- unlike the old mkfiles.pl, CMake is not my personal problem to
maintain
- most importantly, mkfiles.pl was just a horrible pile of
unmaintainable cruft, which even I found it painful to make changes
to or to use, and desperately needed throwing in the bin. I've
already thrown away all the variants of it I had in other projects
of mine, and was only delaying this one so we could make the 0.75
release branch first.
This change comes with a noticeable build-level restructuring. The
previous Recipe worked by compiling every object file exactly once,
and then making each executable by linking a precisely specified
subset of the same object files. But in CMake, that's not the natural
way to work - if you write the obvious command that puts the same
source file into two executable targets, CMake generates a makefile
that compiles it once per target. That can be an advantage, because it
gives you the freedom to compile it differently in each case (e.g.
with a #define telling it which program it's part of). But in a
project that has many executable targets and had carefully contrived
to _never_ need to build any module more than once, all it does is
bloat the build time pointlessly!
To avoid slowing down the build by a large factor, I've put most of
the modules of the code base into a collection of static libraries
organised vaguely thematically (SSH, other backends, crypto, network,
...). That means all those modules can still be compiled just once
each, because once each library is built it's reused unchanged for all
the executable targets.
One upside of this library-based structure is that now I don't have to
manually specify exactly which objects go into which programs any more
- it's enough to specify which libraries are needed, and the linker
will figure out the fine detail automatically. So there's less
maintenance to do in CMakeLists.txt when the source code changes.
But that reorganisation also adds fragility, because of the trad Unix
linker semantics of walking along the library list once each, so that
cyclic references between your libraries will provoke link errors. The
current setup builds successfully, but I suspect it only just manages
it.
(In particular, I've found that MinGW is the most finicky on this
score of the Windows compilers I've tried building with. So I've
included a MinGW test build in the new-look Buildscr, because
otherwise I think there'd be a significant risk of introducing
MinGW-only build failures due to library search order, which wasn't a
risk in the previous library-free build organisation.)
In the longer term I hope to be able to reduce the risk of that, via
gradual reorganisation (in particular, breaking up too-monolithic
modules, to reduce the risk of knock-on references when you included a
module for function A and it also contains function B with an
unsatisfied dependency you didn't really need). Ideally I want to
reach a state in which the libraries all have sensibly described
purposes, a clearly documented (partial) order in which they're
permitted to depend on each other, and a specification of what stubs
you have to put where if you're leaving one of them out (e.g.
nocrypto) and what callbacks you have to define in your non-library
objects to satisfy dependencies from things low in the stack (e.g.
out_of_memory()).
One thing that's gone completely missing in this migration,
unfortunately, is the unfinished MacOS port linked against Quartz GTK.
That's because it turned out that I can't currently build it myself,
on my own Mac: my previous installation of GTK had bit-rotted as a
side effect of an Xcode upgrade, and I haven't yet been able to
persuade jhbuild to make me a new one. So I can't even build the MacOS
port with the _old_ makefiles, and hence, I have no way of checking
that the new ones also work. I hope to bring that port back to life at
some point, but I don't want it to block the rest of this change.
2021-04-10 14:21:11 +00:00
|
|
|
#if HAVE_UPDWTMPX
|
2005-04-25 23:28:25 +00:00
|
|
|
updwtmpx(WTMPX_FILE, &utmp_entry);
|
Replace mkfiles.pl with a CMake build system.
This brings various concrete advantages over the previous system:
- consistent support for out-of-tree builds on all platforms
- more thorough support for Visual Studio IDE project files
- support for Ninja-based builds, which is particularly useful on
Windows where the alternative nmake has no parallel option
- a really simple set of build instructions that work the same way on
all the major platforms (look how much shorter README is!)
- better decoupling of the project configuration from the toolchain
configuration, so that my Windows cross-building doesn't need
(much) special treatment in CMakeLists.txt
- configure-time tests on Windows as well as Linux, so that a lot of
ad-hoc #ifdefs second-guessing a particular feature's presence from
the compiler version can now be replaced by tests of the feature
itself
Also some longer-term software-engineering advantages:
- other people have actually heard of CMake, so they'll be able to
produce patches to the new build setup more easily
- unlike the old mkfiles.pl, CMake is not my personal problem to
maintain
- most importantly, mkfiles.pl was just a horrible pile of
unmaintainable cruft, which even I found it painful to make changes
to or to use, and desperately needed throwing in the bin. I've
already thrown away all the variants of it I had in other projects
of mine, and was only delaying this one so we could make the 0.75
release branch first.
This change comes with a noticeable build-level restructuring. The
previous Recipe worked by compiling every object file exactly once,
and then making each executable by linking a precisely specified
subset of the same object files. But in CMake, that's not the natural
way to work - if you write the obvious command that puts the same
source file into two executable targets, CMake generates a makefile
that compiles it once per target. That can be an advantage, because it
gives you the freedom to compile it differently in each case (e.g.
with a #define telling it which program it's part of). But in a
project that has many executable targets and had carefully contrived
to _never_ need to build any module more than once, all it does is
bloat the build time pointlessly!
To avoid slowing down the build by a large factor, I've put most of
the modules of the code base into a collection of static libraries
organised vaguely thematically (SSH, other backends, crypto, network,
...). That means all those modules can still be compiled just once
each, because once each library is built it's reused unchanged for all
the executable targets.
One upside of this library-based structure is that now I don't have to
manually specify exactly which objects go into which programs any more
- it's enough to specify which libraries are needed, and the linker
will figure out the fine detail automatically. So there's less
maintenance to do in CMakeLists.txt when the source code changes.
But that reorganisation also adds fragility, because of the trad Unix
linker semantics of walking along the library list once each, so that
cyclic references between your libraries will provoke link errors. The
current setup builds successfully, but I suspect it only just manages
it.
(In particular, I've found that MinGW is the most finicky on this
score of the Windows compilers I've tried building with. So I've
included a MinGW test build in the new-look Buildscr, because
otherwise I think there'd be a significant risk of introducing
MinGW-only build failures due to library search order, which wasn't a
risk in the previous library-free build organisation.)
In the longer term I hope to be able to reduce the risk of that, via
gradual reorganisation (in particular, breaking up too-monolithic
modules, to reduce the risk of knock-on references when you included a
module for function A and it also contains function B with an
unsatisfied dependency you didn't really need). Ideally I want to
reach a state in which the libraries all have sensibly described
purposes, a clearly documented (partial) order in which they're
permitted to depend on each other, and a specification of what stubs
you have to put where if you're leaving one of them out (e.g.
nocrypto) and what callbacks you have to define in your non-library
objects to satisfy dependencies from things low in the stack (e.g.
out_of_memory()).
One thing that's gone completely missing in this migration,
unfortunately, is the unfinished MacOS port linked against Quartz GTK.
That's because it turned out that I can't currently build it myself,
on my own Mac: my previous installation of GTK had bit-rotted as a
side effect of an Xcode upgrade, and I haven't yet been able to
persuade jhbuild to make me a new one. So I can't even build the MacOS
port with the _old_ makefiles, and hence, I have no way of checking
that the new ones also work. I hope to bring that port back to life at
some point, but I don't want it to block the rest of this change.
2021-04-10 14:21:11 +00:00
|
|
|
#endif
|
2002-10-15 12:29:52 +00:00
|
|
|
|
|
|
|
|
memset(utmp_entry.ut_line, 0, lenof(utmp_entry.ut_line));
|
2005-04-25 23:28:25 +00:00
|
|
|
utmp_entry.ut_tv.tv_sec = 0;
|
|
|
|
|
utmp_entry.ut_tv.tv_usec = 0;
|
2002-10-15 12:29:52 +00:00
|
|
|
|
2005-04-25 23:28:25 +00:00
|
|
|
setutxent();
|
|
|
|
|
pututxline(&utmp_entry);
|
|
|
|
|
endutxent();
|
2002-10-15 12:29:52 +00:00
|
|
|
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
pty_stamped_utmp = false; /* ensure we never double-cleanup */
|
2002-10-15 12:29:52 +00:00
|
|
|
}
|
2004-11-24 11:36:08 +00:00
|
|
|
#endif
|
2002-10-15 12:29:52 +00:00
|
|
|
|
2002-10-14 09:18:34 +00:00
|
|
|
static void sigchld_handler(int signum)
|
|
|
|
|
{
|
2009-08-07 00:19:04 +00:00
|
|
|
if (write(pty_signal_pipe[1], "x", 1) <= 0)
|
2019-09-08 19:29:00 +00:00
|
|
|
/* not much we can do about it */;
|
2002-10-14 09:18:34 +00:00
|
|
|
}
|
2017-11-25 21:49:31 +00:00
|
|
|
|
|
|
|
|
static void pty_setup_sigchld_handler(void)
|
|
|
|
|
{
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
static bool setup = false;
|
2017-11-25 21:49:31 +00:00
|
|
|
if (!setup) {
|
|
|
|
|
putty_signal(SIGCHLD, sigchld_handler);
|
2018-10-29 19:50:29 +00:00
|
|
|
setup = true;
|
2017-11-25 21:49:31 +00:00
|
|
|
}
|
|
|
|
|
}
|
2002-10-14 09:18:34 +00:00
|
|
|
|
2004-11-24 11:36:08 +00:00
|
|
|
#ifndef OMIT_UTMP
|
2002-10-15 12:29:52 +00:00
|
|
|
static void fatal_sig_handler(int signum)
|
|
|
|
|
{
|
2002-11-02 14:35:57 +00:00
|
|
|
putty_signal(signum, SIG_DFL);
|
2002-10-15 12:29:52 +00:00
|
|
|
cleanup_utmp();
|
|
|
|
|
raise(signum);
|
|
|
|
|
}
|
2004-11-24 11:36:08 +00:00
|
|
|
#endif
|
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)
|
2005-02-05 15:33:36 +00:00
|
|
|
{
|
2006-11-23 14:32:11 +00:00
|
|
|
if (pty->slave_fd < 0) {
|
2019-09-08 19:29:00 +00:00
|
|
|
pty->slave_fd = open(pty->name, O_RDWR);
|
2006-12-09 15:44:31 +00:00
|
|
|
cloexec(pty->slave_fd);
|
2006-11-23 14:32:11 +00:00
|
|
|
}
|
2005-02-05 15:33:36 +00:00
|
|
|
|
2005-02-06 15:14:34 +00:00
|
|
|
return pty->slave_fd;
|
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)
|
2002-10-09 18:09:42 +00:00
|
|
|
{
|
2002-10-15 10:49:38 +00:00
|
|
|
#ifdef BSD_PTYS
|
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++)
|
2019-09-08 19:29:00 +00:00
|
|
|
for (p2 = chars2; *p2; p2++) {
|
|
|
|
|
sprintf(master_name, "/dev/pty%c%c", *p1, *p2);
|
|
|
|
|
pty->master_fd = open(master_name, O_RDWR);
|
|
|
|
|
if (pty->master_fd >= 0) {
|
|
|
|
|
if (geteuid() == 0 ||
|
|
|
|
|
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.
|
|
|
|
|
*/
|
|
|
|
|
strcpy(pty->name, master_name);
|
|
|
|
|
pty->name[5] = 't'; /* /dev/ptyXX -> /dev/ttyXX */
|
2005-02-05 15:33:36 +00:00
|
|
|
|
2006-12-09 15:44:31 +00:00
|
|
|
cloexec(pty->master_fd);
|
2006-11-23 14:32:11 +00:00
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
if (pty_open_slave(pty) >= 0 &&
|
|
|
|
|
access(pty->name, R_OK | W_OK) == 0)
|
|
|
|
|
goto got_one;
|
|
|
|
|
if (pty->slave_fd > 0)
|
|
|
|
|
close(pty->slave_fd);
|
|
|
|
|
pty->slave_fd = -1;
|
|
|
|
|
}
|
|
|
|
|
close(pty->master_fd);
|
|
|
|
|
}
|
|
|
|
|
}
|
2002-10-15 10:49:38 +00:00
|
|
|
|
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);
|
2002-10-15 10:49:38 +00:00
|
|
|
|
2022-08-03 19:48:46 +00:00
|
|
|
got_one:
|
2002-10-16 12:17:51 +00:00
|
|
|
|
|
|
|
|
/* We need to chown/chmod the /dev/ttyXX device. */
|
|
|
|
|
gp = getgrnam("tty");
|
2005-02-06 15:14:34 +00:00
|
|
|
chown(pty->name, getuid(), gp ? gp->gr_gid : -1);
|
|
|
|
|
chmod(pty->name, 0600);
|
2002-10-15 10:49:38 +00:00
|
|
|
#else
|
2012-12-18 09:02:38 +00:00
|
|
|
|
|
|
|
|
const int flags = O_RDWR
|
|
|
|
|
#ifdef O_NOCTTY
|
|
|
|
|
| O_NOCTTY
|
|
|
|
|
#endif
|
|
|
|
|
;
|
|
|
|
|
|
Replace mkfiles.pl with a CMake build system.
This brings various concrete advantages over the previous system:
- consistent support for out-of-tree builds on all platforms
- more thorough support for Visual Studio IDE project files
- support for Ninja-based builds, which is particularly useful on
Windows where the alternative nmake has no parallel option
- a really simple set of build instructions that work the same way on
all the major platforms (look how much shorter README is!)
- better decoupling of the project configuration from the toolchain
configuration, so that my Windows cross-building doesn't need
(much) special treatment in CMakeLists.txt
- configure-time tests on Windows as well as Linux, so that a lot of
ad-hoc #ifdefs second-guessing a particular feature's presence from
the compiler version can now be replaced by tests of the feature
itself
Also some longer-term software-engineering advantages:
- other people have actually heard of CMake, so they'll be able to
produce patches to the new build setup more easily
- unlike the old mkfiles.pl, CMake is not my personal problem to
maintain
- most importantly, mkfiles.pl was just a horrible pile of
unmaintainable cruft, which even I found it painful to make changes
to or to use, and desperately needed throwing in the bin. I've
already thrown away all the variants of it I had in other projects
of mine, and was only delaying this one so we could make the 0.75
release branch first.
This change comes with a noticeable build-level restructuring. The
previous Recipe worked by compiling every object file exactly once,
and then making each executable by linking a precisely specified
subset of the same object files. But in CMake, that's not the natural
way to work - if you write the obvious command that puts the same
source file into two executable targets, CMake generates a makefile
that compiles it once per target. That can be an advantage, because it
gives you the freedom to compile it differently in each case (e.g.
with a #define telling it which program it's part of). But in a
project that has many executable targets and had carefully contrived
to _never_ need to build any module more than once, all it does is
bloat the build time pointlessly!
To avoid slowing down the build by a large factor, I've put most of
the modules of the code base into a collection of static libraries
organised vaguely thematically (SSH, other backends, crypto, network,
...). That means all those modules can still be compiled just once
each, because once each library is built it's reused unchanged for all
the executable targets.
One upside of this library-based structure is that now I don't have to
manually specify exactly which objects go into which programs any more
- it's enough to specify which libraries are needed, and the linker
will figure out the fine detail automatically. So there's less
maintenance to do in CMakeLists.txt when the source code changes.
But that reorganisation also adds fragility, because of the trad Unix
linker semantics of walking along the library list once each, so that
cyclic references between your libraries will provoke link errors. The
current setup builds successfully, but I suspect it only just manages
it.
(In particular, I've found that MinGW is the most finicky on this
score of the Windows compilers I've tried building with. So I've
included a MinGW test build in the new-look Buildscr, because
otherwise I think there'd be a significant risk of introducing
MinGW-only build failures due to library search order, which wasn't a
risk in the previous library-free build organisation.)
In the longer term I hope to be able to reduce the risk of that, via
gradual reorganisation (in particular, breaking up too-monolithic
modules, to reduce the risk of knock-on references when you included a
module for function A and it also contains function B with an
unsatisfied dependency you didn't really need). Ideally I want to
reach a state in which the libraries all have sensibly described
purposes, a clearly documented (partial) order in which they're
permitted to depend on each other, and a specification of what stubs
you have to put where if you're leaving one of them out (e.g.
nocrypto) and what callbacks you have to define in your non-library
objects to satisfy dependencies from things low in the stack (e.g.
out_of_memory()).
One thing that's gone completely missing in this migration,
unfortunately, is the unfinished MacOS port linked against Quartz GTK.
That's because it turned out that I can't currently build it myself,
on my own Mac: my previous installation of GTK had bit-rotted as a
side effect of an Xcode upgrade, and I haven't yet been able to
persuade jhbuild to make me a new one. So I can't even build the MacOS
port with the _old_ makefiles, and hence, I have no way of checking
that the new ones also work. I hope to bring that port back to life at
some point, but I don't want it to block the rest of this change.
2021-04-10 14:21:11 +00:00
|
|
|
#if HAVE_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
|
2012-12-18 09:02:38 +00:00
|
|
|
pty->master_fd = posix_openpt(flags);
|
2015-08-31 12:00:19 +00:00
|
|
|
#endif
|
2012-12-18 09:02:38 +00:00
|
|
|
|
|
|
|
|
if (pty->master_fd < 0) {
|
2019-09-08 19:29:00 +00:00
|
|
|
perror("posix_openpt");
|
|
|
|
|
exit(1);
|
2012-12-18 09:02:38 +00:00
|
|
|
}
|
|
|
|
|
#else
|
2012-12-18 09:02:38 +00:00
|
|
|
pty->master_fd = open("/dev/ptmx", flags);
|
2002-10-10 12:40:05 +00:00
|
|
|
|
2005-02-06 15:14:34 +00:00
|
|
|
if (pty->master_fd < 0) {
|
2019-09-08 19:29:00 +00:00
|
|
|
perror("/dev/ptmx: open");
|
|
|
|
|
exit(1);
|
2002-10-10 12:40:05 +00:00
|
|
|
}
|
2012-12-18 09:02:38 +00:00
|
|
|
#endif
|
2002-10-10 12:40:05 +00:00
|
|
|
|
2005-02-06 15:14:34 +00:00
|
|
|
if (grantpt(pty->master_fd) < 0) {
|
2019-09-08 19:29:00 +00:00
|
|
|
perror("grantpt");
|
|
|
|
|
exit(1);
|
2002-10-10 12:40:05 +00:00
|
|
|
}
|
2019-09-08 19:29:00 +00:00
|
|
|
|
2005-02-06 15:14:34 +00:00
|
|
|
if (unlockpt(pty->master_fd) < 0) {
|
2019-09-08 19:29:00 +00:00
|
|
|
perror("unlockpt");
|
|
|
|
|
exit(1);
|
2002-10-10 12:40:05 +00:00
|
|
|
}
|
|
|
|
|
|
2006-12-09 15:44:31 +00:00
|
|
|
cloexec(pty->master_fd);
|
2006-11-23 14:32:11 +00:00
|
|
|
|
2005-02-06 15:14:34 +00:00
|
|
|
pty->name[FILENAME_MAX-1] = '\0';
|
|
|
|
|
strncpy(pty->name, ptsname(pty->master_fd), FILENAME_MAX-1);
|
2002-10-15 10:49:38 +00:00
|
|
|
#endif
|
2005-02-06 15:14:34 +00:00
|
|
|
|
2015-08-31 12:00:19 +00:00
|
|
|
#ifndef SET_NONBLOCK_VIA_OPENPT
|
2013-07-19 18:10:02 +00:00
|
|
|
nonblock(pty->master_fd);
|
2015-08-31 12:00:19 +00:00
|
|
|
#endif
|
2002-10-16 12:17:51 +00:00
|
|
|
}
|
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)
|
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);
|
2021-10-30 13:51:24 +00:00
|
|
|
memset(pty, 0, sizeof(Pty));
|
2015-08-31 15:11:37 +00:00
|
|
|
pty->conf = NULL;
|
2019-02-13 19:35:34 +00:00
|
|
|
pty->pending_eof = false;
|
2015-08-31 15:11:37 +00:00
|
|
|
bufchain_init(&pty->output_data);
|
|
|
|
|
return pty;
|
|
|
|
|
}
|
|
|
|
|
|
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)
|
|
|
|
|
{
|
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;
|
2005-02-06 15:14:34 +00:00
|
|
|
|
2004-11-24 11:36:08 +00:00
|
|
|
#ifndef OMIT_UTMP
|
2002-10-16 12:17:51 +00:00
|
|
|
pid_t pid;
|
|
|
|
|
int pipefd[2];
|
2004-11-24 11:36:08 +00:00
|
|
|
#endif
|
2002-10-16 12:17:51 +00:00
|
|
|
|
2015-08-31 15:11:37 +00:00
|
|
|
pty = single_pty = new_pty_struct();
|
2005-02-06 15:14:34 +00:00
|
|
|
|
2002-11-02 14:35:57 +00:00
|
|
|
/* set the child signal handler straight away; it needs to be set
|
|
|
|
|
* before we ever fork. */
|
2017-11-25 21:49:31 +00:00
|
|
|
pty_setup_sigchld_handler();
|
2005-02-06 15:14:34 +00:00
|
|
|
pty->master_fd = pty->slave_fd = -1;
|
|
|
|
|
#ifndef OMIT_UTMP
|
2018-10-29 19:50:29 +00:00
|
|
|
pty_stamped_utmp = false;
|
2005-02-06 15:14:34 +00:00
|
|
|
#endif
|
2002-10-16 12:17:51 +00:00
|
|
|
|
|
|
|
|
if (geteuid() != getuid() || getegid() != getgid()) {
|
2019-09-08 19:29:00 +00:00
|
|
|
pty_open_master(pty);
|
2002-10-15 18:36:18 +00:00
|
|
|
|
2002-10-16 12:17:51 +00:00
|
|
|
#ifndef OMIT_UTMP
|
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.
|
|
|
|
|
*/
|
2002-10-16 12:17:51 +00:00
|
|
|
|
2011-09-19 16:38:23 +00:00
|
|
|
dlen = 0;
|
|
|
|
|
while (1) {
|
2019-09-08 19:29:00 +00:00
|
|
|
|
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);
|
2002-10-15 12:29:52 +00:00
|
|
|
#ifdef SIGBUS
|
2011-09-19 16:38:23 +00:00
|
|
|
putty_signal(SIGBUS, fatal_sig_handler);
|
2002-10-15 12:29:52 +00:00
|
|
|
#endif
|
|
|
|
|
#ifdef SIGPOLL
|
2011-09-19 16:38:23 +00:00
|
|
|
putty_signal(SIGPOLL, fatal_sig_handler);
|
2002-10-15 12:29:52 +00:00
|
|
|
#endif
|
|
|
|
|
#ifdef SIGPROF
|
2011-09-19 16:38:23 +00:00
|
|
|
putty_signal(SIGPROF, fatal_sig_handler);
|
2002-10-15 12:29:52 +00:00
|
|
|
#endif
|
|
|
|
|
#ifdef SIGSYS
|
2011-09-19 16:38:23 +00:00
|
|
|
putty_signal(SIGSYS, fatal_sig_handler);
|
2002-10-15 12:29:52 +00:00
|
|
|
#endif
|
|
|
|
|
#ifdef SIGTRAP
|
2011-09-19 16:38:23 +00:00
|
|
|
putty_signal(SIGTRAP, fatal_sig_handler);
|
2002-10-15 12:29:52 +00:00
|
|
|
#endif
|
|
|
|
|
#ifdef SIGVTALRM
|
2011-09-19 16:38:23 +00:00
|
|
|
putty_signal(SIGVTALRM, fatal_sig_handler);
|
2002-10-15 12:29:52 +00:00
|
|
|
#endif
|
|
|
|
|
#ifdef SIGXCPU
|
2011-09-19 16:38:23 +00:00
|
|
|
putty_signal(SIGXCPU, fatal_sig_handler);
|
2002-10-15 12:29:52 +00:00
|
|
|
#endif
|
|
|
|
|
#ifdef SIGXFSZ
|
2011-09-19 16:38:23 +00:00
|
|
|
putty_signal(SIGXFSZ, fatal_sig_handler);
|
2002-10-15 12:29:52 +00:00
|
|
|
#endif
|
|
|
|
|
#ifdef SIGIO
|
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];
|
|
|
|
|
}
|
2002-10-16 12:17:51 +00:00
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Drop privs. */
|
|
|
|
|
{
|
Replace mkfiles.pl with a CMake build system.
This brings various concrete advantages over the previous system:
- consistent support for out-of-tree builds on all platforms
- more thorough support for Visual Studio IDE project files
- support for Ninja-based builds, which is particularly useful on
Windows where the alternative nmake has no parallel option
- a really simple set of build instructions that work the same way on
all the major platforms (look how much shorter README is!)
- better decoupling of the project configuration from the toolchain
configuration, so that my Windows cross-building doesn't need
(much) special treatment in CMakeLists.txt
- configure-time tests on Windows as well as Linux, so that a lot of
ad-hoc #ifdefs second-guessing a particular feature's presence from
the compiler version can now be replaced by tests of the feature
itself
Also some longer-term software-engineering advantages:
- other people have actually heard of CMake, so they'll be able to
produce patches to the new build setup more easily
- unlike the old mkfiles.pl, CMake is not my personal problem to
maintain
- most importantly, mkfiles.pl was just a horrible pile of
unmaintainable cruft, which even I found it painful to make changes
to or to use, and desperately needed throwing in the bin. I've
already thrown away all the variants of it I had in other projects
of mine, and was only delaying this one so we could make the 0.75
release branch first.
This change comes with a noticeable build-level restructuring. The
previous Recipe worked by compiling every object file exactly once,
and then making each executable by linking a precisely specified
subset of the same object files. But in CMake, that's not the natural
way to work - if you write the obvious command that puts the same
source file into two executable targets, CMake generates a makefile
that compiles it once per target. That can be an advantage, because it
gives you the freedom to compile it differently in each case (e.g.
with a #define telling it which program it's part of). But in a
project that has many executable targets and had carefully contrived
to _never_ need to build any module more than once, all it does is
bloat the build time pointlessly!
To avoid slowing down the build by a large factor, I've put most of
the modules of the code base into a collection of static libraries
organised vaguely thematically (SSH, other backends, crypto, network,
...). That means all those modules can still be compiled just once
each, because once each library is built it's reused unchanged for all
the executable targets.
One upside of this library-based structure is that now I don't have to
manually specify exactly which objects go into which programs any more
- it's enough to specify which libraries are needed, and the linker
will figure out the fine detail automatically. So there's less
maintenance to do in CMakeLists.txt when the source code changes.
But that reorganisation also adds fragility, because of the trad Unix
linker semantics of walking along the library list once each, so that
cyclic references between your libraries will provoke link errors. The
current setup builds successfully, but I suspect it only just manages
it.
(In particular, I've found that MinGW is the most finicky on this
score of the Windows compilers I've tried building with. So I've
included a MinGW test build in the new-look Buildscr, because
otherwise I think there'd be a significant risk of introducing
MinGW-only build failures due to library search order, which wasn't a
risk in the previous library-free build organisation.)
In the longer term I hope to be able to reduce the risk of that, via
gradual reorganisation (in particular, breaking up too-monolithic
modules, to reduce the risk of knock-on references when you included a
module for function A and it also contains function B with an
unsatisfied dependency you didn't really need). Ideally I want to
reach a state in which the libraries all have sensibly described
purposes, a clearly documented (partial) order in which they're
permitted to depend on each other, and a specification of what stubs
you have to put where if you're leaving one of them out (e.g.
nocrypto) and what callbacks you have to define in your non-library
objects to satisfy dependencies from things low in the stack (e.g.
out_of_memory()).
One thing that's gone completely missing in this migration,
unfortunately, is the unfinished MacOS port linked against Quartz GTK.
That's because it turned out that I can't currently build it myself,
on my own Mac: my previous installation of GTK had bit-rotted as a
side effect of an Xcode upgrade, and I haven't yet been able to
persuade jhbuild to make me a new one. So I can't even build the MacOS
port with the _old_ makefiles, and hence, I have no way of checking
that the new ones also work. I hope to bring that port back to life at
some point, but I don't want it to block the rest of this change.
2021-04-10 14:21:11 +00:00
|
|
|
#if HAVE_SETRESUID && HAVE_SETRESGID
|
2019-09-08 19:29:00 +00:00
|
|
|
int gid = getgid(), uid = getuid();
|
|
|
|
|
int setresgid(gid_t, gid_t, gid_t);
|
|
|
|
|
int setresuid(uid_t, uid_t, uid_t);
|
|
|
|
|
if (setresgid(gid, gid, gid) < 0) {
|
2013-02-23 21:00:29 +00:00
|
|
|
perror("setresgid");
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
2019-09-08 19:29:00 +00:00
|
|
|
if (setresuid(uid, uid, uid) < 0) {
|
2013-02-23 21:00:29 +00:00
|
|
|
perror("setresuid");
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
2002-10-16 12:17:51 +00:00
|
|
|
#else
|
2019-09-08 19:29:00 +00:00
|
|
|
if (setgid(getgid()) < 0) {
|
2013-02-23 21:00:29 +00:00
|
|
|
perror("setgid");
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
2019-09-08 19:29:00 +00:00
|
|
|
if (setuid(getuid()) < 0) {
|
2013-02-23 21:00:29 +00:00
|
|
|
perror("setuid");
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
2002-10-16 12:17:51 +00:00
|
|
|
#endif
|
|
|
|
|
}
|
2015-08-31 11:51:25 +00:00
|
|
|
|
|
|
|
|
#endif /* NO_PTY_PRE_INIT */
|
|
|
|
|
|
2002-10-16 12:17:51 +00:00
|
|
|
}
|
|
|
|
|
|
2018-10-13 09:36:18 +00:00
|
|
|
static void pty_try_wait(void);
|
2021-12-19 11:15:50 +00:00
|
|
|
static void pty_uxsel_setup(Pty *pty);
|
2018-10-13 09:36:18 +00:00
|
|
|
|
2018-10-18 19:31:13 +00:00
|
|
|
static void pty_real_select_result(Pty *pty, int fd, int event, int status)
|
2003-03-29 18:30:14 +00:00
|
|
|
{
|
|
|
|
|
char buf[4096];
|
|
|
|
|
int ret;
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
bool finished = false;
|
2003-03-29 18:30:14 +00:00
|
|
|
|
2005-02-06 15:14:34 +00:00
|
|
|
if (event < 0) {
|
2019-09-08 19:29:00 +00:00
|
|
|
/*
|
|
|
|
|
* We've been called because our child process did
|
|
|
|
|
* something. `status' tells us what.
|
|
|
|
|
*/
|
|
|
|
|
if ((WIFEXITED(status) || WIFSIGNALED(status))) {
|
|
|
|
|
/*
|
|
|
|
|
* The primary child process died.
|
2018-10-18 19:31:13 +00:00
|
|
|
*/
|
2018-10-29 19:50:29 +00:00
|
|
|
pty->child_dead = true;
|
2018-10-18 19:31:13 +00:00
|
|
|
del234(ptys_by_pid, pty);
|
|
|
|
|
pty->exit_code = status;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If this is an ordinary pty session, this is also the
|
2019-09-08 19:29:00 +00:00
|
|
|
* moment to terminate the whole backend.
|
2018-10-18 19:31:13 +00:00
|
|
|
*
|
|
|
|
|
* We _could_ instead keep the terminal open for remaining
|
2019-09-08 19:29:00 +00:00
|
|
|
* 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.
|
|
|
|
|
*/
|
2018-10-18 19:31:13 +00:00
|
|
|
if (pty->master_fd >= 0)
|
2018-10-29 19:50:29 +00:00
|
|
|
finished = true;
|
2019-09-08 19:29:00 +00:00
|
|
|
}
|
2005-02-06 15:14:34 +00:00
|
|
|
} else {
|
2019-09-08 19:29:00 +00:00
|
|
|
if (event == SELECT_R) {
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
bool is_stdout = (fd == pty->master_o);
|
2003-03-29 18:30:14 +00:00
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
ret = read(fd, buf, sizeof(buf));
|
2003-03-29 18:30:14 +00:00
|
|
|
|
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;
|
|
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
if (ret == 0) {
|
2018-10-18 19:31:13 +00:00
|
|
|
/*
|
|
|
|
|
* 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!
|
|
|
|
|
*/
|
2018-10-29 19:50:29 +00:00
|
|
|
finished = true;
|
2018-10-18 19:31:13 +00:00
|
|
|
pty_try_wait(); /* one last effort to collect exit code */
|
|
|
|
|
if (!pty->child_dead)
|
|
|
|
|
pty->exit_code = 0;
|
|
|
|
|
}
|
2019-09-08 19:29:00 +00:00
|
|
|
} else if (ret < 0) {
|
|
|
|
|
perror("read pty master");
|
|
|
|
|
exit(1);
|
|
|
|
|
} else if (ret > 0) {
|
2021-12-19 11:15:50 +00:00
|
|
|
pty->output_backlog = seat_output(
|
|
|
|
|
pty->seat, !is_stdout, buf, ret);
|
|
|
|
|
pty_uxsel_setup(pty);
|
2019-09-08 19:29:00 +00:00
|
|
|
}
|
|
|
|
|
} else if (event == SELECT_W) {
|
2006-02-23 13:38:44 +00:00
|
|
|
/*
|
|
|
|
|
* Attempt to send data down the pty.
|
|
|
|
|
*/
|
|
|
|
|
pty_try_write(pty);
|
|
|
|
|
}
|
2003-03-29 18:30:14 +00:00
|
|
|
}
|
|
|
|
|
|
2005-02-06 15:14:34 +00:00
|
|
|
if (finished && !pty->finished) {
|
2019-09-08 19:29:00 +00:00
|
|
|
int close_on_exit;
|
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
|
|
|
|
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);
|
2003-03-29 18:30:14 +00:00
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
pty->finished = true;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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.
|
|
|
|
|
*/
|
|
|
|
|
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)) {
|
|
|
|
|
char *message;
|
2018-12-08 21:03:51 +00:00
|
|
|
if (WIFEXITED(pty->exit_code)) {
|
2019-09-08 19:29:00 +00:00
|
|
|
message = dupprintf(
|
2018-12-08 21:03:51 +00:00
|
|
|
"\r\n[pterm: process terminated with exit code %d]\r\n",
|
|
|
|
|
WEXITSTATUS(pty->exit_code));
|
|
|
|
|
} else if (WIFSIGNALED(pty->exit_code)) {
|
Replace mkfiles.pl with a CMake build system.
This brings various concrete advantages over the previous system:
- consistent support for out-of-tree builds on all platforms
- more thorough support for Visual Studio IDE project files
- support for Ninja-based builds, which is particularly useful on
Windows where the alternative nmake has no parallel option
- a really simple set of build instructions that work the same way on
all the major platforms (look how much shorter README is!)
- better decoupling of the project configuration from the toolchain
configuration, so that my Windows cross-building doesn't need
(much) special treatment in CMakeLists.txt
- configure-time tests on Windows as well as Linux, so that a lot of
ad-hoc #ifdefs second-guessing a particular feature's presence from
the compiler version can now be replaced by tests of the feature
itself
Also some longer-term software-engineering advantages:
- other people have actually heard of CMake, so they'll be able to
produce patches to the new build setup more easily
- unlike the old mkfiles.pl, CMake is not my personal problem to
maintain
- most importantly, mkfiles.pl was just a horrible pile of
unmaintainable cruft, which even I found it painful to make changes
to or to use, and desperately needed throwing in the bin. I've
already thrown away all the variants of it I had in other projects
of mine, and was only delaying this one so we could make the 0.75
release branch first.
This change comes with a noticeable build-level restructuring. The
previous Recipe worked by compiling every object file exactly once,
and then making each executable by linking a precisely specified
subset of the same object files. But in CMake, that's not the natural
way to work - if you write the obvious command that puts the same
source file into two executable targets, CMake generates a makefile
that compiles it once per target. That can be an advantage, because it
gives you the freedom to compile it differently in each case (e.g.
with a #define telling it which program it's part of). But in a
project that has many executable targets and had carefully contrived
to _never_ need to build any module more than once, all it does is
bloat the build time pointlessly!
To avoid slowing down the build by a large factor, I've put most of
the modules of the code base into a collection of static libraries
organised vaguely thematically (SSH, other backends, crypto, network,
...). That means all those modules can still be compiled just once
each, because once each library is built it's reused unchanged for all
the executable targets.
One upside of this library-based structure is that now I don't have to
manually specify exactly which objects go into which programs any more
- it's enough to specify which libraries are needed, and the linker
will figure out the fine detail automatically. So there's less
maintenance to do in CMakeLists.txt when the source code changes.
But that reorganisation also adds fragility, because of the trad Unix
linker semantics of walking along the library list once each, so that
cyclic references between your libraries will provoke link errors. The
current setup builds successfully, but I suspect it only just manages
it.
(In particular, I've found that MinGW is the most finicky on this
score of the Windows compilers I've tried building with. So I've
included a MinGW test build in the new-look Buildscr, because
otherwise I think there'd be a significant risk of introducing
MinGW-only build failures due to library search order, which wasn't a
risk in the previous library-free build organisation.)
In the longer term I hope to be able to reduce the risk of that, via
gradual reorganisation (in particular, breaking up too-monolithic
modules, to reduce the risk of knock-on references when you included a
module for function A and it also contains function B with an
unsatisfied dependency you didn't really need). Ideally I want to
reach a state in which the libraries all have sensibly described
purposes, a clearly documented (partial) order in which they're
permitted to depend on each other, and a specification of what stubs
you have to put where if you're leaving one of them out (e.g.
nocrypto) and what callbacks you have to define in your non-library
objects to satisfy dependencies from things low in the stack (e.g.
out_of_memory()).
One thing that's gone completely missing in this migration,
unfortunately, is the unfinished MacOS port linked against Quartz GTK.
That's because it turned out that I can't currently build it myself,
on my own Mac: my previous installation of GTK had bit-rotted as a
side effect of an Xcode upgrade, and I haven't yet been able to
persuade jhbuild to make me a new one. So I can't even build the MacOS
port with the _old_ makefiles, and hence, I have no way of checking
that the new ones also work. I hope to bring that port back to life at
some point, but I don't want it to block the rest of this change.
2021-04-10 14:21:11 +00:00
|
|
|
#if !HAVE_STRSIGNAL
|
2019-09-08 19:29:00 +00:00
|
|
|
message = dupprintf(
|
2018-12-08 21:03:51 +00:00
|
|
|
"\r\n[pterm: process terminated on signal %d]\r\n",
|
|
|
|
|
WTERMSIG(pty->exit_code));
|
2003-03-29 18:30:14 +00:00
|
|
|
#else
|
2019-09-08 19:29:00 +00:00
|
|
|
message = dupprintf(
|
2018-12-08 21:03:51 +00:00
|
|
|
"\r\n[pterm: process terminated on signal %d (%s)]\r\n",
|
|
|
|
|
WTERMSIG(pty->exit_code),
|
|
|
|
|
strsignal(WTERMSIG(pty->exit_code)));
|
2003-03-29 18:30:14 +00:00
|
|
|
#endif
|
2018-12-08 21:03:51 +00:00
|
|
|
} else {
|
|
|
|
|
/* _Shouldn't_ happen, but if it does, a vague message
|
|
|
|
|
* is better than no message at all */
|
|
|
|
|
message = dupprintf("\r\n[pterm: process terminated]\r\n");
|
|
|
|
|
}
|
2019-09-08 19:29:00 +00:00
|
|
|
seat_stdout_pl(pty->seat, ptrlen_from_asciz(message));
|
2018-12-08 21:03:51 +00:00
|
|
|
sfree(message);
|
2019-09-08 19:29:00 +00:00
|
|
|
}
|
2004-11-27 13:20:21 +00:00
|
|
|
|
2018-10-13 09:15:47 +00:00
|
|
|
seat_eof(pty->seat);
|
2019-09-08 19:29:00 +00:00
|
|
|
seat_notify_remote_exit(pty->seat);
|
2003-03-29 18:30:14 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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)
|
2018-10-18 19:31:13 +00:00
|
|
|
pty_real_select_result(pty, -1, -1, status);
|
2018-10-13 09:36:18 +00:00
|
|
|
} while (pid > 0);
|
|
|
|
|
}
|
|
|
|
|
|
2016-05-30 21:52:30 +00:00
|
|
|
void pty_select_result(int fd, int event)
|
2003-03-29 18:30:14 +00:00
|
|
|
{
|
2005-02-06 15:14:34 +00:00
|
|
|
if (fd == pty_signal_pipe[0]) {
|
2019-09-08 19:29:00 +00:00
|
|
|
char c[1];
|
2005-02-06 15:14:34 +00:00
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
if (read(pty_signal_pipe[0], c, 1) <= 0)
|
|
|
|
|
/* ignore error */;
|
|
|
|
|
/* ignore its value; it'll be `x' */
|
2005-02-06 15:14:34 +00:00
|
|
|
|
2018-10-13 09:36:18 +00:00
|
|
|
pty_try_wait();
|
2005-02-06 15:14:34 +00:00
|
|
|
} else {
|
2018-10-18 19:31:13 +00:00
|
|
|
PtyFd *ptyfd = find234(ptyfds, &fd, ptyfd_find);
|
2005-02-06 15:14:34 +00:00
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
if (ptyfd)
|
|
|
|
|
pty_real_select_result(ptyfd->pty, fd, event, 0);
|
2005-02-06 15:14:34 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-18 19:31:13 +00:00
|
|
|
static void pty_uxsel_setup_fd(Pty *pty, int fd)
|
2005-02-06 15:14:34 +00:00
|
|
|
{
|
2018-10-18 19:31:13 +00:00
|
|
|
int rwx = 0;
|
|
|
|
|
|
|
|
|
|
if (fd < 0)
|
|
|
|
|
return;
|
|
|
|
|
|
2021-12-19 11:15:50 +00:00
|
|
|
/* read from standard output and standard error pipes, assuming
|
|
|
|
|
* we're not too backlogged */
|
|
|
|
|
if ((pty->master_o == fd || pty->master_e == fd) &&
|
|
|
|
|
pty->output_backlog < PTY_MAX_BACKLOG)
|
2019-02-07 18:13:56 +00:00
|
|
|
rwx |= SELECT_R;
|
2018-10-18 19:31:13 +00:00
|
|
|
/* write to standard input pipe if we have any data */
|
|
|
|
|
if (pty->master_i == fd && bufchain_size(&pty->output_data))
|
2019-02-07 18:13:56 +00:00
|
|
|
rwx |= SELECT_W;
|
2006-02-23 13:38:44 +00:00
|
|
|
|
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).
|
2019-02-07 18:13:56 +00:00
|
|
|
* So we can't just call uxsel_set(master_o, SELECT_R) and then
|
|
|
|
|
* uxsel_set(master_i, SELECT_W), without the latter potentially
|
|
|
|
|
* undoing the work of the former if master_o == master_i.
|
2018-10-18 19:31:13 +00:00
|
|
|
*
|
|
|
|
|
* 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);
|
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.
|
|
|
|
|
*/
|
2019-02-07 18:13:56 +00:00
|
|
|
uxsel_set(pty_signal_pipe[0], SELECT_R, pty_select_result);
|
2003-03-29 18:30:14 +00:00
|
|
|
}
|
|
|
|
|
|
2018-10-18 19:37:33 +00:00
|
|
|
static void copy_ttymodes_into_termios(
|
|
|
|
|
struct termios *attrs, struct ssh_ttymodes modes)
|
|
|
|
|
{
|
2019-01-18 19:14:27 +00:00
|
|
|
#define TTYMODE_CHAR(name, ssh_opcode, cc_index) { \
|
|
|
|
|
if (modes.have_mode[ssh_opcode]) { \
|
|
|
|
|
unsigned value = modes.mode_val[ssh_opcode]; \
|
|
|
|
|
/* normalise wire value of 255 to local _POSIX_VDISABLE */ \
|
|
|
|
|
attrs->c_cc[cc_index] = (value == 255 ? \
|
|
|
|
|
_POSIX_VDISABLE : value); \
|
|
|
|
|
} \
|
2018-10-18 19:37:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#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 */
|
2021-04-22 16:58:40 +00:00
|
|
|
#include "ssh/ttymode-list.h"
|
2018-10-18 19:37:33 +00:00
|
|
|
|
|
|
|
|
#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]);
|
|
|
|
|
}
|
|
|
|
|
|
2002-10-16 12:17:51 +00:00
|
|
|
/*
|
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.
|
2002-10-16 12:17:51 +00:00
|
|
|
*/
|
2018-10-13 07:32:40 +00:00
|
|
|
Backend *pty_backend_create(
|
2018-10-18 19:31:13 +00:00
|
|
|
Seat *seat, LogContext *logctx, Conf *conf, char **argv, const char *cmd,
|
2019-03-31 21:12:42 +00:00
|
|
|
struct ssh_ttymodes ttymodes, bool pipes_instead, const char *dir,
|
2019-03-31 21:09:54 +00:00
|
|
|
const char *const *env_vars_to_unset)
|
2002-10-16 12:17:51 +00:00
|
|
|
{
|
|
|
|
|
int slavefd;
|
|
|
|
|
pid_t pid, pgrp;
|
2019-09-08 19:29:00 +00:00
|
|
|
#ifndef NOT_X_WINDOWS /* for Mac OS X native compilation */
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
bool got_windowid;
|
2003-03-06 12:57:37 +00:00
|
|
|
long windowid;
|
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;
|
2018-10-18 19:31:13 +00:00
|
|
|
int i;
|
2002-10-16 12:17:51 +00:00
|
|
|
|
2019-03-10 14:42:11 +00:00
|
|
|
/* No local authentication phase in this protocol */
|
|
|
|
|
seat_set_trust_status(seat, false);
|
|
|
|
|
|
2005-02-06 15:14:34 +00:00
|
|
|
if (single_pty) {
|
2019-09-08 19:29:00 +00:00
|
|
|
pty = single_pty;
|
2013-07-11 17:24:23 +00:00
|
|
|
assert(pty->conf == NULL);
|
2005-02-06 15:14:34 +00:00
|
|
|
} else {
|
2019-09-08 19:29:00 +00:00
|
|
|
pty = new_pty_struct();
|
|
|
|
|
pty->master_fd = pty->slave_fd = -1;
|
2005-02-06 15:14:34 +00:00
|
|
|
#ifndef OMIT_UTMP
|
2019-09-08 19:29:00 +00:00
|
|
|
pty_stamped_utmp = false;
|
2005-02-06 15:14:34 +00:00
|
|
|
#endif
|
|
|
|
|
}
|
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;
|
|
|
|
|
}
|
2005-02-06 15:14:34 +00:00
|
|
|
|
2020-05-02 15:11:19 +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]);
|
|
|
|
|
}
|
|
|
|
|
|
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;
|
2018-09-11 15:23:38 +00:00
|
|
|
pty->backend.vt = &pty_backend;
|
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);
|
2002-10-23 12:41:35 +00:00
|
|
|
|
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);
|
2018-10-21 11:57:16 +00:00
|
|
|
#ifndef OMIT_UTMP
|
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;
|
|
|
|
|
}
|
2018-10-21 11:57:16 +00:00
|
|
|
#endif
|
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);
|
2002-10-16 12:17:51 +00:00
|
|
|
|
2004-11-24 11:36:08 +00:00
|
|
|
#ifndef OMIT_UTMP
|
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 */
|
2018-10-29 19:57:31 +00:00
|
|
|
if (!conf_get_bool(conf, CONF_stamp_utmp)) {
|
2018-10-18 19:31:13 +00:00
|
|
|
/* 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;
|
2012-12-18 09:19:04 +00:00
|
|
|
}
|
|
|
|
|
}
|
2018-10-18 19:31:13 +00:00
|
|
|
}
|
2004-11-24 11:36:08 +00:00
|
|
|
#endif
|
2002-10-15 12:29:52 +00:00
|
|
|
|
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]);
|
|
|
|
|
}
|
|
|
|
|
|
2019-09-08 19:29:00 +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);
|
2005-02-06 13:33:41 +00:00
|
|
|
#endif
|
2003-03-06 12:57:37 +00:00
|
|
|
|
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();
|
|
|
|
|
|
2002-10-10 12:40:05 +00:00
|
|
|
/*
|
|
|
|
|
* Fork and execute the command.
|
|
|
|
|
*/
|
|
|
|
|
pid = fork();
|
|
|
|
|
if (pid < 0) {
|
2019-09-08 19:29:00 +00:00
|
|
|
perror("fork");
|
|
|
|
|
exit(1);
|
2002-10-10 12:40:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (pid == 0) {
|
2015-09-01 17:45:51 +00:00
|
|
|
struct termios attrs;
|
|
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
/*
|
|
|
|
|
* We are the child.
|
|
|
|
|
*/
|
2002-10-14 08:56:55 +00:00
|
|
|
|
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)) {
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
bool unset = (e[plen] == 'u');
|
2016-03-23 22:13:30 +00:00
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-18 19:31:13 +00:00
|
|
|
pgrp = getpid();
|
2002-10-14 08:56:55 +00:00
|
|
|
|
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();
|
2005-09-13 19:57:37 +00:00
|
|
|
#ifdef TIOCSCTTY
|
2018-10-18 19:31:13 +00:00
|
|
|
ioctl(0, TIOCSCTTY, 1);
|
2005-09-13 19:57:37 +00:00
|
|
|
#endif
|
2018-10-18 19:31:13 +00:00
|
|
|
tcsetpgrp(0, pgrp);
|
2015-09-01 17:45:51 +00:00
|
|
|
|
|
|
|
|
/*
|
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.
|
2015-09-01 17:45:51 +00:00
|
|
|
*/
|
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.
|
|
|
|
|
*/
|
2018-10-29 19:57:31 +00:00
|
|
|
attrs.c_cc[VERASE] = conf_get_bool(conf, CONF_bksp_is_delete)
|
2018-10-18 19:31:13 +00:00
|
|
|
? '\177' : '\010';
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Set the IUTF8 bit iff the character set is UTF-8.
|
|
|
|
|
*/
|
2015-09-01 17:45:51 +00:00
|
|
|
#ifdef IUTF8
|
2018-10-18 19:31:13 +00:00
|
|
|
if (seat_is_utf8(seat))
|
|
|
|
|
attrs.c_iflag |= IUTF8;
|
|
|
|
|
else
|
|
|
|
|
attrs.c_iflag &= ~IUTF8;
|
2015-09-01 17:45:51 +00:00
|
|
|
#endif
|
|
|
|
|
|
2018-10-18 19:31:13 +00:00
|
|
|
copy_ttymodes_into_termios(&attrs, ttymodes);
|
2018-10-18 19:37:33 +00:00
|
|
|
|
2018-10-18 19:31:13 +00:00
|
|
|
tcsetattr(0, TCSANOW, &attrs);
|
|
|
|
|
}
|
2015-09-01 17:45:51 +00:00
|
|
|
}
|
|
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
setpgid(pgrp, pgrp);
|
2018-10-18 19:31:13 +00:00
|
|
|
if (!pipes_instead) {
|
2013-07-19 17:44:22 +00:00
|
|
|
int ptyfd = open(pty->name, O_WRONLY, 0);
|
|
|
|
|
if (ptyfd >= 0)
|
|
|
|
|
close(ptyfd);
|
|
|
|
|
}
|
2019-09-08 19:29:00 +00:00
|
|
|
setpgid(pgrp, pgrp);
|
2019-03-31 21:09:54 +00:00
|
|
|
|
|
|
|
|
if (env_vars_to_unset)
|
|
|
|
|
for (const char *const *p = env_vars_to_unset; *p; p++)
|
|
|
|
|
unsetenv(*p);
|
|
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
if (!pipes_instead) {
|
|
|
|
|
char *term_env_var = dupprintf("TERM=%s",
|
|
|
|
|
conf_get_str(conf, CONF_termtype));
|
|
|
|
|
putenv(term_env_var);
|
|
|
|
|
/* We mustn't free term_env_var, as putenv links it into the
|
|
|
|
|
* environment in place.
|
|
|
|
|
*/
|
|
|
|
|
}
|
|
|
|
|
#ifndef NOT_X_WINDOWS /* for Mac OS X native compilation */
|
|
|
|
|
if (got_windowid) {
|
|
|
|
|
char *windowid_env_var = dupprintf("WINDOWID=%ld", windowid);
|
|
|
|
|
putenv(windowid_env_var);
|
|
|
|
|
/* We mustn't free windowid_env_var, as putenv links it into the
|
|
|
|
|
* environment in place.
|
|
|
|
|
*/
|
|
|
|
|
}
|
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);
|
2019-03-31 21:14:03 +00:00
|
|
|
if (x_display) {
|
|
|
|
|
char *x_display_env_var = dupprintf("DISPLAY=%s", x_display);
|
|
|
|
|
putenv(x_display_env_var);
|
|
|
|
|
/* As above, we don't free this. */
|
|
|
|
|
}
|
2015-08-22 14:05:12 +00:00
|
|
|
}
|
2005-02-06 13:33:41 +00:00
|
|
|
#endif
|
2019-09-08 19:29:00 +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)) {
|
Make dupcat() into a variadic macro.
Up until now, it's been a variadic _function_, whose argument list
consists of 'const char *' ASCIZ strings to concatenate, terminated by
one containing a null pointer. Now, that function is dupcat_fn(), and
it's wrapped by a C99 variadic _macro_ called dupcat(), which
automatically suffixes the null-pointer terminating argument.
This has three benefits. Firstly, it's just less effort at every call
site. Secondly, it protects against the risk of accidentally leaving
off the NULL, causing arbitrary words of stack memory to be
dereferenced as char pointers. And thirdly, it protects against the
more subtle risk of writing a bare 'NULL' as the terminating argument,
instead of casting it explicitly to a pointer. That last one is
necessary because C permits the macro NULL to expand to an integer
constant such as 0, so NULL by itself may not have pointer type, and
worse, it may not be marshalled in a variadic argument list in the
same way as a pointer. (For example, on a 64-bit machine it might only
occupy 32 bits. And yet, on another 64-bit platform, it might work
just fine, so that you don't notice the mistake!)
I was inspired to do this by happening to notice one of those bare
NULL terminators, and thinking I'd better check if there were any
more. Turned out there were quite a few. Now there are none.
2019-10-14 18:42:37 +00:00
|
|
|
char *varval = dupcat(key, "=", val);
|
2019-09-08 19:29:00 +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.
|
|
|
|
|
*/
|
|
|
|
|
}
|
|
|
|
|
}
|
2004-10-16 10:56:54 +00:00
|
|
|
|
2019-04-01 19:04:48 +00:00
|
|
|
if (dir) {
|
|
|
|
|
if (chdir(dir) < 0) {
|
|
|
|
|
/* Ignore the error - nothing we can sensibly do about it,
|
|
|
|
|
* and our existing cwd is as good a fallback as any. */
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-03-31 21:12:42 +00:00
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
/*
|
|
|
|
|
* SIGINT, SIGQUIT and SIGPIPE may have been set to ignored by
|
|
|
|
|
* our parent, particularly by things like sh -c 'pterm &' and
|
|
|
|
|
* some window or session managers. SIGPIPE was also
|
|
|
|
|
* (potentially) blocked by us during startup. Reverse all
|
|
|
|
|
* this for our child process.
|
|
|
|
|
*/
|
|
|
|
|
putty_signal(SIGINT, SIG_DFL);
|
|
|
|
|
putty_signal(SIGQUIT, SIG_DFL);
|
|
|
|
|
putty_signal(SIGPIPE, SIG_DFL);
|
|
|
|
|
block_signal(SIGPIPE, false);
|
|
|
|
|
if (argv || cmd) {
|
2012-07-11 18:12:17 +00:00
|
|
|
/*
|
2018-10-18 19:31:13 +00:00
|
|
|
* If we were given a separated argument list, try to exec
|
|
|
|
|
* it.
|
2012-07-11 18:12:17 +00:00
|
|
|
*/
|
2018-10-18 19:31:13 +00:00
|
|
|
if (argv) {
|
|
|
|
|
execvp(argv[0], argv);
|
|
|
|
|
}
|
2012-07-11 18:12:17 +00:00
|
|
|
/*
|
2018-10-18 19:31:13 +00:00
|
|
|
* Otherwise, if we were given a single command string,
|
|
|
|
|
* try passing that to $SHELL -c.
|
2012-07-11 18:12:17 +00:00
|
|
|
*
|
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.
|
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
|
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.
|
2012-07-11 18:12:17 +00:00
|
|
|
*/
|
2018-10-18 19:31:13 +00:00
|
|
|
if (cmd) {
|
2012-07-11 18:12:17 +00:00
|
|
|
char *shell = getenv("SHELL");
|
|
|
|
|
if (shell)
|
2018-10-18 19:31:13 +00:00
|
|
|
execl(shell, shell, "-c", cmd, (void *)NULL);
|
2012-07-11 18:12:17 +00:00
|
|
|
}
|
|
|
|
|
} else {
|
2020-03-21 14:45:03 +00:00
|
|
|
const char *shell = getenv("SHELL");
|
|
|
|
|
if (!shell)
|
|
|
|
|
shell = "/bin/sh";
|
2019-09-08 19:29:00 +00:00
|
|
|
char *shellname;
|
|
|
|
|
if (conf_get_bool(conf, CONF_login_shell)) {
|
2020-03-21 14:45:03 +00:00
|
|
|
const char *p = strrchr(shell, '/');
|
2019-09-08 19:29:00 +00:00
|
|
|
p = p ? p+1 : shell;
|
2022-09-13 14:00:26 +00:00
|
|
|
shellname = dupprintf("-%s", p);
|
2019-09-08 19:29:00 +00:00
|
|
|
} else
|
2020-03-21 14:45:03 +00:00
|
|
|
shellname = (char *)shell;
|
|
|
|
|
execl(shell, shellname, (void *)NULL);
|
2019-09-08 19:29:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If we're here, exec has gone badly foom.
|
|
|
|
|
*/
|
|
|
|
|
perror("exec");
|
|
|
|
|
_exit(127);
|
2002-10-10 12:40:05 +00:00
|
|
|
} else {
|
2019-09-08 19:29:00 +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);
|
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;
|
|
|
|
|
}
|
2019-09-08 19:29:00 +00:00
|
|
|
add234(ptys_by_pid, pty);
|
2005-02-05 15:33:36 +00:00
|
|
|
}
|
2002-10-10 12:40:05 +00:00
|
|
|
|
2005-02-06 15:14:34 +00:00
|
|
|
pty_uxsel_setup(pty);
|
|
|
|
|
|
2018-10-13 07:32:40 +00:00
|
|
|
return &pty->backend;
|
|
|
|
|
}
|
2006-05-12 11:02:28 +00:00
|
|
|
|
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.
|
|
|
|
|
*/
|
2020-04-18 12:28:33 +00:00
|
|
|
static char *pty_init(const BackendVtable *vt, Seat *seat,
|
|
|
|
|
Backend **backend_handle, LogContext *logctx,
|
|
|
|
|
Conf *conf, const char *host, int port,
|
|
|
|
|
char **realhost, bool nodelay, bool keepalive)
|
2018-10-13 07:32:40 +00:00
|
|
|
{
|
2018-10-18 19:31:13 +00:00
|
|
|
const char *cmd = NULL;
|
2018-10-18 19:37:33 +00:00
|
|
|
struct ssh_ttymodes modes;
|
2018-10-18 19:31:13 +00:00
|
|
|
|
2018-10-18 19:37:33 +00:00
|
|
|
memset(&modes, 0, sizeof(modes));
|
2018-10-18 19:31:13 +00:00
|
|
|
|
|
|
|
|
if (pty_argv && pty_argv[0] && !pty_argv[1])
|
|
|
|
|
cmd = pty_argv[0];
|
|
|
|
|
|
2020-02-16 11:43:20 +00:00
|
|
|
assert(vt == &pty_backend);
|
|
|
|
|
*backend_handle = pty_backend_create(
|
2019-03-31 21:12:42 +00:00
|
|
|
seat, logctx, conf, pty_argv, cmd, modes, false, NULL, NULL);
|
2018-10-13 07:32:40 +00:00
|
|
|
*realhost = dupstr("");
|
2002-10-09 18:09:42 +00:00
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2018-09-11 15:23:38 +00:00
|
|
|
static void pty_reconfig(Backend *be, Conf *conf)
|
2003-01-12 14:48:29 +00:00
|
|
|
{
|
2018-10-05 22:49:08 +00:00
|
|
|
Pty *pty = container_of(be, Pty, backend);
|
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);
|
2003-01-12 14:48:29 +00:00
|
|
|
}
|
|
|
|
|
|
2003-01-20 20:10:07 +00:00
|
|
|
/*
|
2003-04-12 08:27:03 +00:00
|
|
|
* Stub routine (never called in pterm).
|
2003-01-20 20:10:07 +00:00
|
|
|
*/
|
2018-09-11 15:23:38 +00:00
|
|
|
static void pty_free(Backend *be)
|
2003-01-20 20:10:07 +00:00
|
|
|
{
|
2018-10-05 22:49:08 +00:00
|
|
|
Pty *pty = container_of(be, Pty, backend);
|
2018-10-18 19:31:13 +00:00
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
pty_close(pty);
|
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);
|
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]);
|
2005-02-06 15:14:34 +00:00
|
|
|
|
2015-08-31 15:11:37 +00:00
|
|
|
bufchain_clear(&pty->output_data);
|
|
|
|
|
|
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);
|
|
|
|
|
}
|
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)
|
2006-02-23 13:38:44 +00:00
|
|
|
{
|
2019-02-06 20:42:44 +00:00
|
|
|
ssize_t ret;
|
2006-02-23 13:38:44 +00:00
|
|
|
|
2018-10-18 19:31:13 +00:00
|
|
|
assert(pty->master_i >= 0);
|
2006-02-23 13:38:44 +00:00
|
|
|
|
|
|
|
|
while (bufchain_size(&pty->output_data) > 0) {
|
2019-02-06 20:46:45 +00:00
|
|
|
ptrlen data = bufchain_prefix(&pty->output_data);
|
2019-09-08 19:29:00 +00:00
|
|
|
ret = write(pty->master_i, data.ptr, data.len);
|
2006-02-23 13:38:44 +00:00
|
|
|
|
|
|
|
|
if (ret < 0 && (errno == EWOULDBLOCK)) {
|
|
|
|
|
/*
|
|
|
|
|
* We've sent all we can for the moment.
|
|
|
|
|
*/
|
|
|
|
|
break;
|
|
|
|
|
}
|
2019-09-08 19:29:00 +00:00
|
|
|
if (ret < 0) {
|
|
|
|
|
perror("write pty master");
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
bufchain_consume(&pty->output_data, ret);
|
2006-02-23 13:38:44 +00:00
|
|
|
}
|
|
|
|
|
|
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;
|
2018-10-29 19:50:29 +00:00
|
|
|
pty->pending_eof = false;
|
2018-10-18 17:04:31 +00:00
|
|
|
}
|
|
|
|
|
|
2006-02-23 13:38:44 +00:00
|
|
|
pty_uxsel_setup(pty);
|
|
|
|
|
}
|
|
|
|
|
|
2002-10-09 18:09:42 +00:00
|
|
|
/*
|
|
|
|
|
* Called to send data down the pty.
|
|
|
|
|
*/
|
2021-09-12 08:52:46 +00:00
|
|
|
static void pty_send(Backend *be, const char *buf, size_t len)
|
2002-10-09 18:09:42 +00:00
|
|
|
{
|
2018-10-05 22:49:08 +00:00
|
|
|
Pty *pty = container_of(be, Pty, backend);
|
2005-02-06 15:14:34 +00:00
|
|
|
|
2018-10-18 17:04:31 +00:00
|
|
|
if (pty->master_i < 0 || pty->pending_eof)
|
2021-09-12 08:52:46 +00:00
|
|
|
return; /* ignore all writes if fd closed */
|
2002-10-23 14:21:12 +00:00
|
|
|
|
2006-02-23 13:38:44 +00:00
|
|
|
bufchain_add(&pty->output_data, buf, len);
|
|
|
|
|
pty_try_write(pty);
|
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)
|
2002-10-23 14:21:12 +00:00
|
|
|
{
|
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);
|
|
|
|
|
|
2005-02-06 15:14:34 +00:00
|
|
|
if (pty->master_fd >= 0) {
|
2019-09-08 19:29:00 +00:00
|
|
|
close(pty->master_fd);
|
|
|
|
|
pty->master_fd = -1;
|
2002-10-23 14:21:12 +00:00
|
|
|
}
|
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;
|
2004-11-24 11:36:08 +00:00
|
|
|
#ifndef OMIT_UTMP
|
2003-05-11 12:28:53 +00:00
|
|
|
if (pty_utmp_helper_pipe >= 0) {
|
2019-09-08 19:29:00 +00:00
|
|
|
close(pty_utmp_helper_pipe); /* this causes utmp to be cleaned up */
|
|
|
|
|
pty_utmp_helper_pipe = -1;
|
2003-05-11 12:28:53 +00:00
|
|
|
}
|
2004-11-24 11:36:08 +00:00
|
|
|
#endif
|
2002-10-23 14:21:12 +00:00
|
|
|
}
|
|
|
|
|
|
2002-10-09 18:09:42 +00:00
|
|
|
/*
|
|
|
|
|
* Called to query the current socket sendability status.
|
|
|
|
|
*/
|
2019-02-06 20:42:44 +00:00
|
|
|
static size_t pty_sendbuffer(Backend *be)
|
2002-10-09 18:09:42 +00:00
|
|
|
{
|
2021-09-12 08:52:46 +00:00
|
|
|
Pty *pty = container_of(be, Pty, backend);
|
|
|
|
|
return bufchain_size(&pty->output_data);
|
2002-10-09 18:09:42 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Called to set the size of the window
|
|
|
|
|
*/
|
2018-09-11 15:23:38 +00:00
|
|
|
static void pty_size(Backend *be, int width, int height)
|
2002-10-09 18:09:42 +00:00
|
|
|
{
|
2018-10-05 22:49:08 +00:00
|
|
|
Pty *pty = container_of(be, Pty, backend);
|
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;
|
2002-10-13 12:44:01 +00:00
|
|
|
|
2005-02-06 15:14:34 +00:00
|
|
|
pty->term_width = width;
|
|
|
|
|
pty->term_height = height;
|
2002-10-23 12:41:35 +00:00
|
|
|
|
2018-10-18 19:31:13 +00:00
|
|
|
if (pty->master_fd < 0)
|
|
|
|
|
return;
|
|
|
|
|
|
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
|
|
|
|
2005-02-06 15:14:34 +00:00
|
|
|
size.ws_row = (unsigned short)pty->term_height;
|
|
|
|
|
size.ws_col = (unsigned short)pty->term_width;
|
2018-10-13 06:37:24 +00:00
|
|
|
size.ws_xpixel = (unsigned short)xpixel;
|
|
|
|
|
size.ws_ypixel = (unsigned short)ypixel;
|
2005-02-06 15:14:34 +00:00
|
|
|
ioctl(pty->master_fd, TIOCSWINSZ, (void *)&size);
|
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)
|
2002-10-09 18:09:42 +00:00
|
|
|
{
|
2018-10-18 19:37:59 +00:00
|
|
|
Pty *pty = container_of(be, Pty, backend);
|
|
|
|
|
|
|
|
|
|
if (code == SS_BRK) {
|
2018-10-18 19:31:13 +00:00
|
|
|
if (pty->master_fd >= 0)
|
|
|
|
|
tcsendbreak(pty->master_fd, 0);
|
2018-10-18 19:37:59 +00:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-18 17:04:31 +00:00
|
|
|
if (code == SS_EOF) {
|
|
|
|
|
if (pty->master_i >= 0 && pty->master_i != pty->master_fd) {
|
2018-10-29 19:50:29 +00:00
|
|
|
pty->pending_eof = true;
|
2018-10-18 17:04:31 +00:00
|
|
|
pty_try_write(pty);
|
|
|
|
|
}
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
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
|
2021-04-22 16:58:40 +00:00
|
|
|
#include "ssh/signal-list.h"
|
2018-10-18 19:37:59 +00:00
|
|
|
#undef SIGNAL_SUB
|
|
|
|
|
#undef SIGNAL_MAIN
|
|
|
|
|
#undef SIGNALS_LOCAL_ONLY
|
|
|
|
|
|
|
|
|
|
if (sig != -1) {
|
|
|
|
|
if (!pty->child_dead)
|
|
|
|
|
kill(pty->child_pid, sig);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2002-10-09 18:09:42 +00:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
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)
|
2003-04-04 20:21:05 +00:00
|
|
|
{
|
2018-10-05 22:49:08 +00:00
|
|
|
/* Pty *pty = container_of(be, Pty, backend); */
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
static bool pty_connected(Backend *be)
|
2002-10-09 18:09:42 +00:00
|
|
|
{
|
2018-10-05 22:49:08 +00:00
|
|
|
/* Pty *pty = container_of(be, Pty, backend); */
|
2018-10-29 19:50:29 +00:00
|
|
|
return true;
|
2002-10-09 18:09:42 +00:00
|
|
|
}
|
|
|
|
|
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
static bool pty_sendok(Backend *be)
|
2002-10-09 18:09:42 +00:00
|
|
|
{
|
2018-10-05 22:49:08 +00:00
|
|
|
/* Pty *pty = container_of(be, Pty, backend); */
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
return true;
|
2002-10-09 18:09:42 +00:00
|
|
|
}
|
|
|
|
|
|
2019-02-06 20:42:44 +00:00
|
|
|
static void pty_unthrottle(Backend *be, size_t backlog)
|
2002-10-09 18:09:42 +00:00
|
|
|
{
|
2021-12-19 11:15:50 +00:00
|
|
|
Pty *pty = container_of(be, Pty, backend);
|
|
|
|
|
pty->output_backlog = backlog;
|
|
|
|
|
pty_uxsel_setup(pty);
|
2002-10-09 18:09:42 +00:00
|
|
|
}
|
|
|
|
|
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
static bool pty_ldisc(Backend *be, int option)
|
2002-10-09 18:09:42 +00:00
|
|
|
{
|
2018-10-05 22:49:08 +00:00
|
|
|
/* Pty *pty = container_of(be, Pty, backend); */
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
return false; /* neither editing nor echoing */
|
2002-10-09 18:09:42 +00:00
|
|
|
}
|
|
|
|
|
|
2018-09-11 15:23:38 +00:00
|
|
|
static void pty_provide_ldisc(Backend *be, Ldisc *ldisc)
|
2002-10-26 10:16:19 +00:00
|
|
|
{
|
2018-10-05 22:49:08 +00:00
|
|
|
/* Pty *pty = container_of(be, Pty, backend); */
|
2002-10-26 10:16:19 +00:00
|
|
|
/* This is a stub. */
|
|
|
|
|
}
|
|
|
|
|
|
2018-09-11 15:23:38 +00:00
|
|
|
static int pty_exitcode(Backend *be)
|
2002-10-09 18:09:42 +00:00
|
|
|
{
|
2018-10-05 22:49:08 +00:00
|
|
|
Pty *pty = container_of(be, Pty, backend);
|
2005-02-06 15:14:34 +00:00
|
|
|
if (!pty->finished)
|
2019-09-08 19:29:00 +00:00
|
|
|
return -1; /* not dead yet */
|
2018-10-13 07:32:40 +00:00
|
|
|
else if (WIFSIGNALED(pty->exit_code))
|
|
|
|
|
return 128 + WTERMSIG(pty->exit_code);
|
2002-10-23 14:21:12 +00:00
|
|
|
else
|
2018-10-13 07:32:40 +00:00
|
|
|
return WEXITSTATUS(pty->exit_code);
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-30 07:28:38 +00:00
|
|
|
int pty_backend_exit_signum(Backend *be)
|
2018-10-13 07:32:40 +00:00
|
|
|
{
|
|
|
|
|
Pty *pty = container_of(be, Pty, backend);
|
|
|
|
|
|
2019-03-30 07:28:38 +00:00
|
|
|
if (!pty->finished || !WIFSIGNALED(pty->exit_code))
|
2019-09-08 19:29:00 +00:00
|
|
|
return -1;
|
2019-03-30 07:28:38 +00:00
|
|
|
|
|
|
|
|
return WTERMSIG(pty->exit_code);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ptrlen pty_backend_exit_signame(Backend *be, char **aux_msg)
|
|
|
|
|
{
|
2018-10-13 07:32:40 +00:00
|
|
|
*aux_msg = NULL;
|
|
|
|
|
|
2019-03-30 07:28:38 +00:00
|
|
|
int sig = pty_backend_exit_signum(be);
|
|
|
|
|
if (sig < 0)
|
2019-09-08 19:29:00 +00:00
|
|
|
return PTRLEN_LITERAL("");
|
2018-10-13 07:32:40 +00:00
|
|
|
|
2020-01-01 12:58:52 +00:00
|
|
|
#define SIGNAL_SUB(s) { \
|
2018-10-13 07:32:40 +00:00
|
|
|
if (sig == SIG ## s) \
|
|
|
|
|
return PTRLEN_LITERAL(#s); \
|
2020-01-01 12:58:52 +00:00
|
|
|
}
|
|
|
|
|
#define SIGNAL_MAIN(s, desc) SIGNAL_SUB(s)
|
|
|
|
|
#define SIGNALS_LOCAL_ONLY
|
2021-04-22 16:58:40 +00:00
|
|
|
#include "ssh/signal-list.h"
|
2020-01-01 12:58:52 +00:00
|
|
|
#undef SIGNAL_MAIN
|
|
|
|
|
#undef SIGNAL_SUB
|
|
|
|
|
#undef SIGNALS_LOCAL_ONLY
|
2018-10-13 07:32:40 +00:00
|
|
|
|
|
|
|
|
*aux_msg = dupprintf("untranslatable signal number %d: %s",
|
|
|
|
|
sig, strsignal(sig));
|
|
|
|
|
return PTRLEN_LITERAL("HUP"); /* need some kind of default */
|
2002-10-09 18:09:42 +00:00
|
|
|
}
|
|
|
|
|
|
2018-09-11 15:23:38 +00:00
|
|
|
static int pty_cfg_info(Backend *be)
|
2004-12-29 12:32:25 +00:00
|
|
|
{
|
2018-10-05 22:49:08 +00:00
|
|
|
/* Pty *pty = container_of(be, Pty, backend); */
|
2004-12-29 12:32:25 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
Change vtable defs to use C99 designated initialisers.
This is a sweeping change applied across the whole code base by a spot
of Emacs Lisp. Now, everywhere I declare a vtable filled with function
pointers (and the occasional const data member), all the members of
the vtable structure are initialised by name using the '.fieldname =
value' syntax introduced in C99.
We were already using this syntax for a handful of things in the new
key-generation progress report system, so it's not new to the code
base as a whole.
The advantage is that now, when a vtable only declares a subset of the
available fields, I can initialise the rest to NULL or zero just by
leaving them out. This is most dramatic in a couple of the outlying
vtables in things like psocks (which has a ConnectionLayerVtable
containing only one non-NULL method), but less dramatically, it means
that the new 'flags' field in BackendVtable can be completely left out
of every backend definition except for the SUPDUP one which defines it
to a nonzero value. Similarly, the test_for_upstream method only used
by SSH doesn't have to be mentioned in the rest of the backends;
network Plugs for listening sockets don't have to explicitly null out
'receive' and 'sent', and vice versa for 'accepting', and so on.
While I'm at it, I've normalised the declarations so they don't use
the unnecessarily verbose 'struct' keyword. Also a handful of them
weren't const; now they are.
2020-03-10 21:06:29 +00:00
|
|
|
const BackendVtable pty_backend = {
|
|
|
|
|
.init = pty_init,
|
|
|
|
|
.free = pty_free,
|
|
|
|
|
.reconfig = pty_reconfig,
|
|
|
|
|
.send = pty_send,
|
|
|
|
|
.sendbuffer = pty_sendbuffer,
|
|
|
|
|
.size = pty_size,
|
|
|
|
|
.special = pty_special,
|
|
|
|
|
.get_specials = pty_get_specials,
|
|
|
|
|
.connected = pty_connected,
|
|
|
|
|
.exitcode = pty_exitcode,
|
|
|
|
|
.sendok = pty_sendok,
|
|
|
|
|
.ldisc_option_state = pty_ldisc,
|
|
|
|
|
.provide_ldisc = pty_provide_ldisc,
|
|
|
|
|
.unthrottle = pty_unthrottle,
|
|
|
|
|
.cfg_info = pty_cfg_info,
|
|
|
|
|
.id = "pty",
|
2021-10-23 17:26:34 +00:00
|
|
|
.displayname_tc = "pty",
|
|
|
|
|
.displayname_lc = "pty",
|
Change vtable defs to use C99 designated initialisers.
This is a sweeping change applied across the whole code base by a spot
of Emacs Lisp. Now, everywhere I declare a vtable filled with function
pointers (and the occasional const data member), all the members of
the vtable structure are initialised by name using the '.fieldname =
value' syntax introduced in C99.
We were already using this syntax for a handful of things in the new
key-generation progress report system, so it's not new to the code
base as a whole.
The advantage is that now, when a vtable only declares a subset of the
available fields, I can initialise the rest to NULL or zero just by
leaving them out. This is most dramatic in a couple of the outlying
vtables in things like psocks (which has a ConnectionLayerVtable
containing only one non-NULL method), but less dramatically, it means
that the new 'flags' field in BackendVtable can be completely left out
of every backend definition except for the SUPDUP one which defines it
to a nonzero value. Similarly, the test_for_upstream method only used
by SSH doesn't have to be mentioned in the rest of the backends;
network Plugs for listening sockets don't have to explicitly null out
'receive' and 'sent', and vice versa for 'accepting', and so on.
While I'm at it, I've normalised the declarations so they don't use
the unnecessarily verbose 'struct' keyword. Also a handful of them
weren't const; now they are.
2020-03-10 21:06:29 +00:00
|
|
|
.protocol = -1,
|
2002-10-09 18:09:42 +00:00
|
|
|
};
|