nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 09:27:59 +00:00
Code Issues Projects Releases Wiki Activity
0.82
putty-source/ldisc.c

389 lines
12 KiB
C
Raw Permalink Normal View History

Rethink the whole line discipline architecture. Instead of having multiple switchable line disciplines, we now have a single unified one which changes its behaviour based on option settings. Each option setting can be suggested by the back end and/or the terminal handler, and can be forcibly overridden by the configuration. Local echo and local line editing are separate, independently switchable, options. [originally from svn r895]
2001-01-24 14:08:20 +00:00
/*
* ldisc.c: PuTTY line discipline. Sits between the input coming
* from keypresses in the window, and the output channel leading to
* the back end. Implements echo and/or local line editing,
* depending on what's currently configured.
*/
Added local-editing line discipline to make raw backend usable [originally from svn r287]
1999-11-09 12:05:34 +00:00
#include <stdio.h>
Cleanups to remove warnings for GNU/mingw32 compilation [originally from svn r325]
1999-11-22 10:07:24 +00:00
#include <ctype.h>
Clarify when ldisc->term may be NULL. Namely, any ldisc that you send actual data through should have a terminal attached, because the ldisc editing/echoing system is designed entirely for use with a terminal. The only time you can have an ldisc with no terminal is when it's only ever used by the backend to report changes to the front end in edit/echo status, e.g. by Unix Plink. Coverity spotted an oddity in ldisc_send which after a while I decided would never have actually caused a problem, but OTOH I agree that it was confusing, so now hopefully it's less so.
2014-11-22 10:37:14 +00:00
#include <assert.h>
Added local-editing line discipline to make raw backend usable [originally from svn r287]
1999-11-09 12:05:34 +00:00
#include "putty.h"
Major destabilisation, phase 1. In this phase I've moved (I think) all the global and function-static variables out of terminal.c into a dynamically allocated data structure. Note that this does not yet confer the ability to run more than one of them in the same process, because other things (the line discipline, the back end) are still global, and also in particular the address of the dynamically allocated terminal-data structure is held in a global variable `term'. But what I've got here represents a reasonable stopping point at which to check things in. In _theory_ this should all still work happily, on both Unix and Windows. In practice, who knows? [originally from svn r2115]
2002-10-22 16:11:33 +00:00
#include "terminal.h"
Remove ldisc.h. It only had to be a header file because ldisc.c and ldiscucs.c had to share the structure definition. But ldiscucs.c vanished a couple of years ago in commit 71e42b04a57479f, so it's now fine to make the Ldisc structure definition local to ldisc.c itself, the way it should be.
2021-09-13 09:14:33 +00:00
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
typedef enum InputType { NORMAL, DEDICATED, NONINTERACTIVE } InputType;
struct input_chunk {
struct input_chunk *next;
InputType type;
size_t size;
};
Remove ldisc.h. It only had to be a header file because ldisc.c and ldiscucs.c had to share the structure definition. But ldiscucs.c vanished a couple of years ago in commit 71e42b04a57479f, so it's now fine to make the Ldisc structure definition local to ldisc.c itself, the way it should be.
2021-09-13 09:14:33 +00:00
struct Ldisc_tag {
Terminal *term;
Backend *backend;
Seat *seat;
Complete rework of terminal userpass input system. The system for handling seat_get_userpass_input has always been structured differently between GUI PuTTY and CLI tools like Plink. In the CLI tools, password input is read directly from the OS terminal/console device by console_get_userpass_input; this means that you need to ensure the same terminal input data _hasn't_ already been consumed by the main event loop and sent on to the backend. This is achieved by the backend_sendok() method, which tells the event loop when the backend has finished issuing password prompts, and hence, when it's safe to start passing standard input to backend_send(). But in the GUI tools, input generated by the terminal window has always been sent straight to backend_send(), regardless of whether backend_sendok() says it wants it. So the terminal-based implementation of username and password prompts has to work by consuming input data that had _already_ been passed to the backend - hence, any backend that needs to do that must keep its input on a bufchain, and pass that bufchain to seat_get_userpass_input. It's awkward that these two totally different systems coexist in the first place. And now that SSH proxying needs to present interactive prompts of its own, it's clear which one should win: the CLI style is the Right Thing. So this change reworks the GUI side of the mechanism to be more similar: terminal data now goes into a queue in the Ldisc, and is not sent on to the backend until the backend says it's ready for it via backend_sendok(). So terminal-based userpass prompts can now consume data directly from that queue during the connection setup stage. As a result, the 'bufchain *' parameter has vanished from all the userpass_input functions (both the official implementations of the Seat trait method, and term_get_userpass_input() to which some of those implementations delegate). The only function that actually used that bufchain, namely term_get_userpass_input(), now instead reads from the ldisc's input queue via a couple of new Ldisc functions. (Not _trivial_ functions, since input buffered by Ldisc can be a mixture of raw bytes and session specials like SS_EOL! The input queue inside Ldisc is a bufchain containing a fiddly binary encoding that can represent an arbitrary interleaving of those things.) This greatly simplifies the calls to seat_get_userpass_input in backends, which now don't have to mess about with passing their own user_input bufchain around, or toggling their want_user_input flag back and forth to request data to put on to that bufchain. But the flip side is that now there has to be some _other_ method for notifying the terminal when there's more input to be consumed during an interactive prompt, and for notifying the backend when prompt input has finished so that it can proceed to the next stage of the protocol. This is done by a pair of extra callbacks: when more data is put on to Ldisc's input queue, it triggers a call to term_get_userpass_input, and when term_get_userpass_input finishes, it calls a callback function provided in the prompts_t. Therefore, any use of a prompts_t which *might* be asynchronous must fill in the latter callback when setting up the prompts_t. In SSH, the callback is centralised into a common PPL helper function, which reinvokes the same PPL's process_queue coroutine; in rlogin we have to set it up ourselves. I'm sorry for this large and sprawling patch: I tried fairly hard to break it up into individually comprehensible sub-patches, but I just couldn't tease out any part of it that would stand sensibly alone.
2021-09-14 10:57:21 +00:00
/*
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
* When the backend is not reporting true from sendok(), we must
* buffer the input received by ldisc_send(). It's stored in the
* bufchain below, together with a linked list of input_chunk
* blocks storing the extra metadata about special keys and
* interactivity that ldisc_send() receives.
Complete rework of terminal userpass input system. The system for handling seat_get_userpass_input has always been structured differently between GUI PuTTY and CLI tools like Plink. In the CLI tools, password input is read directly from the OS terminal/console device by console_get_userpass_input; this means that you need to ensure the same terminal input data _hasn't_ already been consumed by the main event loop and sent on to the backend. This is achieved by the backend_sendok() method, which tells the event loop when the backend has finished issuing password prompts, and hence, when it's safe to start passing standard input to backend_send(). But in the GUI tools, input generated by the terminal window has always been sent straight to backend_send(), regardless of whether backend_sendok() says it wants it. So the terminal-based implementation of username and password prompts has to work by consuming input data that had _already_ been passed to the backend - hence, any backend that needs to do that must keep its input on a bufchain, and pass that bufchain to seat_get_userpass_input. It's awkward that these two totally different systems coexist in the first place. And now that SSH proxying needs to present interactive prompts of its own, it's clear which one should win: the CLI style is the Right Thing. So this change reworks the GUI side of the mechanism to be more similar: terminal data now goes into a queue in the Ldisc, and is not sent on to the backend until the backend says it's ready for it via backend_sendok(). So terminal-based userpass prompts can now consume data directly from that queue during the connection setup stage. As a result, the 'bufchain *' parameter has vanished from all the userpass_input functions (both the official implementations of the Seat trait method, and term_get_userpass_input() to which some of those implementations delegate). The only function that actually used that bufchain, namely term_get_userpass_input(), now instead reads from the ldisc's input queue via a couple of new Ldisc functions. (Not _trivial_ functions, since input buffered by Ldisc can be a mixture of raw bytes and session specials like SS_EOL! The input queue inside Ldisc is a bufchain containing a fiddly binary encoding that can represent an arbitrary interleaving of those things.) This greatly simplifies the calls to seat_get_userpass_input in backends, which now don't have to mess about with passing their own user_input bufchain around, or toggling their want_user_input flag back and forth to request data to put on to that bufchain. But the flip side is that now there has to be some _other_ method for notifying the terminal when there's more input to be consumed during an interactive prompt, and for notifying the backend when prompt input has finished so that it can proceed to the next stage of the protocol. This is done by a pair of extra callbacks: when more data is put on to Ldisc's input queue, it triggers a call to term_get_userpass_input, and when term_get_userpass_input finishes, it calls a callback function provided in the prompts_t. Therefore, any use of a prompts_t which *might* be asynchronous must fill in the latter callback when setting up the prompts_t. In SSH, the callback is centralised into a common PPL helper function, which reinvokes the same PPL's process_queue coroutine; in rlogin we have to set it up ourselves. I'm sorry for this large and sprawling patch: I tried fairly hard to break it up into individually comprehensible sub-patches, but I just couldn't tease out any part of it that would stand sensibly alone.
2021-09-14 10:57:21 +00:00
*
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
* All input is added to this buffer initially, but we then
* process as much of it as possible immediately and hand it off
* to the backend or a TermLineEditor. Anything left stays in this
* buffer until ldisc_check_sendok() is next called, triggering a
* run of the callback that tries again to process the queue.
Complete rework of terminal userpass input system. The system for handling seat_get_userpass_input has always been structured differently between GUI PuTTY and CLI tools like Plink. In the CLI tools, password input is read directly from the OS terminal/console device by console_get_userpass_input; this means that you need to ensure the same terminal input data _hasn't_ already been consumed by the main event loop and sent on to the backend. This is achieved by the backend_sendok() method, which tells the event loop when the backend has finished issuing password prompts, and hence, when it's safe to start passing standard input to backend_send(). But in the GUI tools, input generated by the terminal window has always been sent straight to backend_send(), regardless of whether backend_sendok() says it wants it. So the terminal-based implementation of username and password prompts has to work by consuming input data that had _already_ been passed to the backend - hence, any backend that needs to do that must keep its input on a bufchain, and pass that bufchain to seat_get_userpass_input. It's awkward that these two totally different systems coexist in the first place. And now that SSH proxying needs to present interactive prompts of its own, it's clear which one should win: the CLI style is the Right Thing. So this change reworks the GUI side of the mechanism to be more similar: terminal data now goes into a queue in the Ldisc, and is not sent on to the backend until the backend says it's ready for it via backend_sendok(). So terminal-based userpass prompts can now consume data directly from that queue during the connection setup stage. As a result, the 'bufchain *' parameter has vanished from all the userpass_input functions (both the official implementations of the Seat trait method, and term_get_userpass_input() to which some of those implementations delegate). The only function that actually used that bufchain, namely term_get_userpass_input(), now instead reads from the ldisc's input queue via a couple of new Ldisc functions. (Not _trivial_ functions, since input buffered by Ldisc can be a mixture of raw bytes and session specials like SS_EOL! The input queue inside Ldisc is a bufchain containing a fiddly binary encoding that can represent an arbitrary interleaving of those things.) This greatly simplifies the calls to seat_get_userpass_input in backends, which now don't have to mess about with passing their own user_input bufchain around, or toggling their want_user_input flag back and forth to request data to put on to that bufchain. But the flip side is that now there has to be some _other_ method for notifying the terminal when there's more input to be consumed during an interactive prompt, and for notifying the backend when prompt input has finished so that it can proceed to the next stage of the protocol. This is done by a pair of extra callbacks: when more data is put on to Ldisc's input queue, it triggers a call to term_get_userpass_input, and when term_get_userpass_input finishes, it calls a callback function provided in the prompts_t. Therefore, any use of a prompts_t which *might* be asynchronous must fill in the latter callback when setting up the prompts_t. In SSH, the callback is centralised into a common PPL helper function, which reinvokes the same PPL's process_queue coroutine; in rlogin we have to set it up ourselves. I'm sorry for this large and sprawling patch: I tried fairly hard to break it up into individually comprehensible sub-patches, but I just couldn't tease out any part of it that would stand sensibly alone.
2021-09-14 10:57:21 +00:00
*/
bufchain input_queue;
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
struct input_chunk *inchunk_head, *inchunk_tail;
Complete rework of terminal userpass input system. The system for handling seat_get_userpass_input has always been structured differently between GUI PuTTY and CLI tools like Plink. In the CLI tools, password input is read directly from the OS terminal/console device by console_get_userpass_input; this means that you need to ensure the same terminal input data _hasn't_ already been consumed by the main event loop and sent on to the backend. This is achieved by the backend_sendok() method, which tells the event loop when the backend has finished issuing password prompts, and hence, when it's safe to start passing standard input to backend_send(). But in the GUI tools, input generated by the terminal window has always been sent straight to backend_send(), regardless of whether backend_sendok() says it wants it. So the terminal-based implementation of username and password prompts has to work by consuming input data that had _already_ been passed to the backend - hence, any backend that needs to do that must keep its input on a bufchain, and pass that bufchain to seat_get_userpass_input. It's awkward that these two totally different systems coexist in the first place. And now that SSH proxying needs to present interactive prompts of its own, it's clear which one should win: the CLI style is the Right Thing. So this change reworks the GUI side of the mechanism to be more similar: terminal data now goes into a queue in the Ldisc, and is not sent on to the backend until the backend says it's ready for it via backend_sendok(). So terminal-based userpass prompts can now consume data directly from that queue during the connection setup stage. As a result, the 'bufchain *' parameter has vanished from all the userpass_input functions (both the official implementations of the Seat trait method, and term_get_userpass_input() to which some of those implementations delegate). The only function that actually used that bufchain, namely term_get_userpass_input(), now instead reads from the ldisc's input queue via a couple of new Ldisc functions. (Not _trivial_ functions, since input buffered by Ldisc can be a mixture of raw bytes and session specials like SS_EOL! The input queue inside Ldisc is a bufchain containing a fiddly binary encoding that can represent an arbitrary interleaving of those things.) This greatly simplifies the calls to seat_get_userpass_input in backends, which now don't have to mess about with passing their own user_input bufchain around, or toggling their want_user_input flag back and forth to request data to put on to that bufchain. But the flip side is that now there has to be some _other_ method for notifying the terminal when there's more input to be consumed during an interactive prompt, and for notifying the backend when prompt input has finished so that it can proceed to the next stage of the protocol. This is done by a pair of extra callbacks: when more data is put on to Ldisc's input queue, it triggers a call to term_get_userpass_input, and when term_get_userpass_input finishes, it calls a callback function provided in the prompts_t. Therefore, any use of a prompts_t which *might* be asynchronous must fill in the latter callback when setting up the prompts_t. In SSH, the callback is centralised into a common PPL helper function, which reinvokes the same PPL's process_queue coroutine; in rlogin we have to set it up ourselves. I'm sorry for this large and sprawling patch: I tried fairly hard to break it up into individually comprehensible sub-patches, but I just couldn't tease out any part of it that would stand sensibly alone.
2021-09-14 10:57:21 +00:00
IdempotentCallback input_queue_callback;
Remove ldisc.h. It only had to be a header file because ldisc.c and ldiscucs.c had to share the structure definition. But ldiscucs.c vanished a couple of years ago in commit 71e42b04a57479f, so it's now fine to make the Ldisc structure definition local to ldisc.c itself, the way it should be.
2021-09-13 09:14:33 +00:00
/*
* Values cached out of conf.
*/
bool telnet_keyboard, telnet_newline;
int protocol, localecho, localedit;
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
TermLineEditor *le;
TermLineEditorCallbackReceiver le_rcv;
/* We get one of these communicated to us by
* term_get_userpass_input while it's reading a prompt, so that we
* can push data straight into it */
TermLineEditor *userpass_le;
Remove ldisc.h. It only had to be a header file because ldisc.c and ldiscucs.c had to share the structure definition. But ldiscucs.c vanished a couple of years ago in commit 71e42b04a57479f, so it's now fine to make the Ldisc structure definition local to ldisc.c itself, the way it should be.
2021-09-13 09:14:33 +00:00
};
Line discipline module now uses dynamically allocated data. Also fixed one or two other minor problems. [originally from svn r2141]
2002-10-26 10:16:19 +00:00
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
#define ECHOING (ldisc->localecho == FORCE_ON || \
(ldisc->localecho == AUTO && \
Withdraw support for the DECEDM escape sequence. Having decided that the terminal's local echo setting shouldn't be allowed to propagate through to termios, I think the local edit setting shouldn't either. Also, no other terminal emulator I know seems to implement this sequence, and if you enable it, things get very confused in general. I think it's generally better off absent; if somebody turns out to have been using it, then we'll at least be able to find out what it's good for.
2019-06-17 19:49:46 +00:00
(backend_ldisc_option_state(ldisc->backend, LD_ECHO))))
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
#define EDITING (ldisc->localedit == FORCE_ON || \
(ldisc->localedit == AUTO && \
Withdraw support for the DECEDM escape sequence. Having decided that the terminal's local echo setting shouldn't be allowed to propagate through to termios, I think the local edit setting shouldn't either. Also, no other terminal emulator I know seems to implement this sequence, and if you enable it, things get very confused in general. I think it's generally better off absent; if somebody turns out to have been using it, then we'll at least be able to find out what it's good for.
2019-06-17 19:49:46 +00:00
(backend_ldisc_option_state(ldisc->backend, LD_EDIT))))
Added local-editing line discipline to make raw backend usable [originally from svn r287]
1999-11-09 12:05:34 +00:00
Complete rework of terminal userpass input system. The system for handling seat_get_userpass_input has always been structured differently between GUI PuTTY and CLI tools like Plink. In the CLI tools, password input is read directly from the OS terminal/console device by console_get_userpass_input; this means that you need to ensure the same terminal input data _hasn't_ already been consumed by the main event loop and sent on to the backend. This is achieved by the backend_sendok() method, which tells the event loop when the backend has finished issuing password prompts, and hence, when it's safe to start passing standard input to backend_send(). But in the GUI tools, input generated by the terminal window has always been sent straight to backend_send(), regardless of whether backend_sendok() says it wants it. So the terminal-based implementation of username and password prompts has to work by consuming input data that had _already_ been passed to the backend - hence, any backend that needs to do that must keep its input on a bufchain, and pass that bufchain to seat_get_userpass_input. It's awkward that these two totally different systems coexist in the first place. And now that SSH proxying needs to present interactive prompts of its own, it's clear which one should win: the CLI style is the Right Thing. So this change reworks the GUI side of the mechanism to be more similar: terminal data now goes into a queue in the Ldisc, and is not sent on to the backend until the backend says it's ready for it via backend_sendok(). So terminal-based userpass prompts can now consume data directly from that queue during the connection setup stage. As a result, the 'bufchain *' parameter has vanished from all the userpass_input functions (both the official implementations of the Seat trait method, and term_get_userpass_input() to which some of those implementations delegate). The only function that actually used that bufchain, namely term_get_userpass_input(), now instead reads from the ldisc's input queue via a couple of new Ldisc functions. (Not _trivial_ functions, since input buffered by Ldisc can be a mixture of raw bytes and session specials like SS_EOL! The input queue inside Ldisc is a bufchain containing a fiddly binary encoding that can represent an arbitrary interleaving of those things.) This greatly simplifies the calls to seat_get_userpass_input in backends, which now don't have to mess about with passing their own user_input bufchain around, or toggling their want_user_input flag back and forth to request data to put on to that bufchain. But the flip side is that now there has to be some _other_ method for notifying the terminal when there's more input to be consumed during an interactive prompt, and for notifying the backend when prompt input has finished so that it can proceed to the next stage of the protocol. This is done by a pair of extra callbacks: when more data is put on to Ldisc's input queue, it triggers a call to term_get_userpass_input, and when term_get_userpass_input finishes, it calls a callback function provided in the prompts_t. Therefore, any use of a prompts_t which *might* be asynchronous must fill in the latter callback when setting up the prompts_t. In SSH, the callback is centralised into a common PPL helper function, which reinvokes the same PPL's process_queue coroutine; in rlogin we have to set it up ourselves. I'm sorry for this large and sprawling patch: I tried fairly hard to break it up into individually comprehensible sub-patches, but I just couldn't tease out any part of it that would stand sensibly alone.
2021-09-14 10:57:21 +00:00
static void ldisc_input_queue_callback(void *ctx);
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
static const TermLineEditorCallbackReceiverVtable ldisc_lineedit_receiver_vt;
Robert de Bath's patch: ^C ^Z and ^D send Telnet specials in terminal line discipline; also switching disciplines in midsession works better [originally from svn r400]
2000-03-11 14:03:04 +00:00
#define CTRL(x) (x^'@')
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
Ldisc *ldisc_create(Conf *conf, Terminal *term, Backend *backend, Seat *seat)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Expose the Ldisc structure tag throughout the code. That's one fewer anonymous 'void *' which might be accidentally confused with some other pointer type if I misremember the order of function arguments. While I'm here, I've made its pointer-nature explicit - that is, 'Ldisc' is now a typedef for the structure type itself rather than a pointer to it. A stylistic change only, but it feels more natural to me these days for a thing you're going to eventually pass to a 'free' function.
2018-09-11 14:02:59 +00:00
Ldisc *ldisc = snew(Ldisc);
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
memset(ldisc, 0, sizeof(Ldisc));
Line discipline module now uses dynamically allocated data. Also fixed one or two other minor problems. [originally from svn r2141]
2002-10-26 10:16:19 +00:00
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
ldisc->backend = backend;
Line discipline module now uses dynamically allocated data. Also fixed one or two other minor problems. [originally from svn r2141]
2002-10-26 10:16:19 +00:00
ldisc->term = term;
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
ldisc->seat = seat;
Line discipline module now uses dynamically allocated data. Also fixed one or two other minor problems. [originally from svn r2141]
2002-10-26 10:16:19 +00:00
Complete rework of terminal userpass input system. The system for handling seat_get_userpass_input has always been structured differently between GUI PuTTY and CLI tools like Plink. In the CLI tools, password input is read directly from the OS terminal/console device by console_get_userpass_input; this means that you need to ensure the same terminal input data _hasn't_ already been consumed by the main event loop and sent on to the backend. This is achieved by the backend_sendok() method, which tells the event loop when the backend has finished issuing password prompts, and hence, when it's safe to start passing standard input to backend_send(). But in the GUI tools, input generated by the terminal window has always been sent straight to backend_send(), regardless of whether backend_sendok() says it wants it. So the terminal-based implementation of username and password prompts has to work by consuming input data that had _already_ been passed to the backend - hence, any backend that needs to do that must keep its input on a bufchain, and pass that bufchain to seat_get_userpass_input. It's awkward that these two totally different systems coexist in the first place. And now that SSH proxying needs to present interactive prompts of its own, it's clear which one should win: the CLI style is the Right Thing. So this change reworks the GUI side of the mechanism to be more similar: terminal data now goes into a queue in the Ldisc, and is not sent on to the backend until the backend says it's ready for it via backend_sendok(). So terminal-based userpass prompts can now consume data directly from that queue during the connection setup stage. As a result, the 'bufchain *' parameter has vanished from all the userpass_input functions (both the official implementations of the Seat trait method, and term_get_userpass_input() to which some of those implementations delegate). The only function that actually used that bufchain, namely term_get_userpass_input(), now instead reads from the ldisc's input queue via a couple of new Ldisc functions. (Not _trivial_ functions, since input buffered by Ldisc can be a mixture of raw bytes and session specials like SS_EOL! The input queue inside Ldisc is a bufchain containing a fiddly binary encoding that can represent an arbitrary interleaving of those things.) This greatly simplifies the calls to seat_get_userpass_input in backends, which now don't have to mess about with passing their own user_input bufchain around, or toggling their want_user_input flag back and forth to request data to put on to that bufchain. But the flip side is that now there has to be some _other_ method for notifying the terminal when there's more input to be consumed during an interactive prompt, and for notifying the backend when prompt input has finished so that it can proceed to the next stage of the protocol. This is done by a pair of extra callbacks: when more data is put on to Ldisc's input queue, it triggers a call to term_get_userpass_input, and when term_get_userpass_input finishes, it calls a callback function provided in the prompts_t. Therefore, any use of a prompts_t which *might* be asynchronous must fill in the latter callback when setting up the prompts_t. In SSH, the callback is centralised into a common PPL helper function, which reinvokes the same PPL's process_queue coroutine; in rlogin we have to set it up ourselves. I'm sorry for this large and sprawling patch: I tried fairly hard to break it up into individually comprehensible sub-patches, but I just couldn't tease out any part of it that would stand sensibly alone.
2021-09-14 10:57:21 +00:00
bufchain_init(&ldisc->input_queue);
ldisc->input_queue_callback.fn = ldisc_input_queue_callback;
ldisc->input_queue_callback.ctx = ldisc;
bufchain_set_callback(&ldisc->input_queue, &ldisc->input_queue_callback);
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
if (ldisc->term) {
ldisc->le_rcv.vt = &ldisc_lineedit_receiver_vt;
ldisc->le = lineedit_new(ldisc->term, 0, &ldisc->le_rcv);
}
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
ldisc_configure(ldisc, conf);
Line discipline module now uses dynamically allocated data. Also fixed one or two other minor problems. [originally from svn r2141]
2002-10-26 10:16:19 +00:00
/* Link ourselves into the backend and the terminal */
if (term)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
term->ldisc = ldisc;
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (backend)
backend_provide_ldisc(backend, ldisc);
Line discipline module now uses dynamically allocated data. Also fixed one or two other minor problems. [originally from svn r2141]
2002-10-26 10:16:19 +00:00
return ldisc;
}
Expose the Ldisc structure tag throughout the code. That's one fewer anonymous 'void *' which might be accidentally confused with some other pointer type if I misremember the order of function arguments. While I'm here, I've made its pointer-nature explicit - that is, 'Ldisc' is now a typedef for the structure type itself rather than a pointer to it. A stylistic change only, but it feels more natural to me these days for a thing you're going to eventually pass to a 'free' function.
2018-09-11 14:02:59 +00:00
void ldisc_configure(Ldisc *ldisc, Conf *conf)
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
{
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
ldisc->telnet_keyboard = conf_get_bool(conf, CONF_telnet_keyboard);
ldisc->telnet_newline = conf_get_bool(conf, CONF_telnet_newline);
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
ldisc->protocol = conf_get_int(conf, CONF_protocol);
ldisc->localecho = conf_get_int(conf, CONF_localecho);
ldisc->localedit = conf_get_int(conf, CONF_localedit);
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
unsigned flags = 0;
if (ldisc->protocol == PROT_RAW)
flags |= LE_CRLF_NEWLINE;
if (ldisc->telnet_keyboard)
flags |= LE_INTERRUPT | LE_SUSPEND | LE_ABORT;
lineedit_modify_flags(ldisc->le, ~0U, flags);
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
}
Expose the Ldisc structure tag throughout the code. That's one fewer anonymous 'void *' which might be accidentally confused with some other pointer type if I misremember the order of function arguments. While I'm here, I've made its pointer-nature explicit - that is, 'Ldisc' is now a typedef for the structure type itself rather than a pointer to it. A stylistic change only, but it feels more natural to me these days for a thing you're going to eventually pass to a 'free' function.
2018-09-11 14:02:59 +00:00
void ldisc_free(Ldisc *ldisc)
Add the ability to close sessions. This adds *_free() functions to most areas of the code. Not all back-ends have been tested, but Telnet and SSH behave reasonably. Incidentally, almost all of this patch was written through Mac PuTTY, admittedly over a Telnet connection. [originally from svn r2615]
2003-01-15 23:30:21 +00:00
{
Complete rework of terminal userpass input system. The system for handling seat_get_userpass_input has always been structured differently between GUI PuTTY and CLI tools like Plink. In the CLI tools, password input is read directly from the OS terminal/console device by console_get_userpass_input; this means that you need to ensure the same terminal input data _hasn't_ already been consumed by the main event loop and sent on to the backend. This is achieved by the backend_sendok() method, which tells the event loop when the backend has finished issuing password prompts, and hence, when it's safe to start passing standard input to backend_send(). But in the GUI tools, input generated by the terminal window has always been sent straight to backend_send(), regardless of whether backend_sendok() says it wants it. So the terminal-based implementation of username and password prompts has to work by consuming input data that had _already_ been passed to the backend - hence, any backend that needs to do that must keep its input on a bufchain, and pass that bufchain to seat_get_userpass_input. It's awkward that these two totally different systems coexist in the first place. And now that SSH proxying needs to present interactive prompts of its own, it's clear which one should win: the CLI style is the Right Thing. So this change reworks the GUI side of the mechanism to be more similar: terminal data now goes into a queue in the Ldisc, and is not sent on to the backend until the backend says it's ready for it via backend_sendok(). So terminal-based userpass prompts can now consume data directly from that queue during the connection setup stage. As a result, the 'bufchain *' parameter has vanished from all the userpass_input functions (both the official implementations of the Seat trait method, and term_get_userpass_input() to which some of those implementations delegate). The only function that actually used that bufchain, namely term_get_userpass_input(), now instead reads from the ldisc's input queue via a couple of new Ldisc functions. (Not _trivial_ functions, since input buffered by Ldisc can be a mixture of raw bytes and session specials like SS_EOL! The input queue inside Ldisc is a bufchain containing a fiddly binary encoding that can represent an arbitrary interleaving of those things.) This greatly simplifies the calls to seat_get_userpass_input in backends, which now don't have to mess about with passing their own user_input bufchain around, or toggling their want_user_input flag back and forth to request data to put on to that bufchain. But the flip side is that now there has to be some _other_ method for notifying the terminal when there's more input to be consumed during an interactive prompt, and for notifying the backend when prompt input has finished so that it can proceed to the next stage of the protocol. This is done by a pair of extra callbacks: when more data is put on to Ldisc's input queue, it triggers a call to term_get_userpass_input, and when term_get_userpass_input finishes, it calls a callback function provided in the prompts_t. Therefore, any use of a prompts_t which *might* be asynchronous must fill in the latter callback when setting up the prompts_t. In SSH, the callback is centralised into a common PPL helper function, which reinvokes the same PPL's process_queue coroutine; in rlogin we have to set it up ourselves. I'm sorry for this large and sprawling patch: I tried fairly hard to break it up into individually comprehensible sub-patches, but I just couldn't tease out any part of it that would stand sensibly alone.
2021-09-14 10:57:21 +00:00
bufchain_clear(&ldisc->input_queue);
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
while (ldisc->inchunk_head) {
struct input_chunk *oldhead = ldisc->inchunk_head;
ldisc->inchunk_head = ldisc->inchunk_head->next;
sfree(oldhead);
}
lineedit_free(ldisc->le);
Add the ability to close sessions. This adds *_free() functions to most areas of the code. Not all back-ends have been tested, but Telnet and SSH behave reasonably. Incidentally, almost all of this patch was written through Mac PuTTY, admittedly over a Telnet connection. [originally from svn r2615]
2003-01-15 23:30:21 +00:00
if (ldisc->term)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ldisc->term->ldisc = NULL;
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (ldisc->backend)
backend_provide_ldisc(ldisc->backend, NULL);
Complete rework of terminal userpass input system. The system for handling seat_get_userpass_input has always been structured differently between GUI PuTTY and CLI tools like Plink. In the CLI tools, password input is read directly from the OS terminal/console device by console_get_userpass_input; this means that you need to ensure the same terminal input data _hasn't_ already been consumed by the main event loop and sent on to the backend. This is achieved by the backend_sendok() method, which tells the event loop when the backend has finished issuing password prompts, and hence, when it's safe to start passing standard input to backend_send(). But in the GUI tools, input generated by the terminal window has always been sent straight to backend_send(), regardless of whether backend_sendok() says it wants it. So the terminal-based implementation of username and password prompts has to work by consuming input data that had _already_ been passed to the backend - hence, any backend that needs to do that must keep its input on a bufchain, and pass that bufchain to seat_get_userpass_input. It's awkward that these two totally different systems coexist in the first place. And now that SSH proxying needs to present interactive prompts of its own, it's clear which one should win: the CLI style is the Right Thing. So this change reworks the GUI side of the mechanism to be more similar: terminal data now goes into a queue in the Ldisc, and is not sent on to the backend until the backend says it's ready for it via backend_sendok(). So terminal-based userpass prompts can now consume data directly from that queue during the connection setup stage. As a result, the 'bufchain *' parameter has vanished from all the userpass_input functions (both the official implementations of the Seat trait method, and term_get_userpass_input() to which some of those implementations delegate). The only function that actually used that bufchain, namely term_get_userpass_input(), now instead reads from the ldisc's input queue via a couple of new Ldisc functions. (Not _trivial_ functions, since input buffered by Ldisc can be a mixture of raw bytes and session specials like SS_EOL! The input queue inside Ldisc is a bufchain containing a fiddly binary encoding that can represent an arbitrary interleaving of those things.) This greatly simplifies the calls to seat_get_userpass_input in backends, which now don't have to mess about with passing their own user_input bufchain around, or toggling their want_user_input flag back and forth to request data to put on to that bufchain. But the flip side is that now there has to be some _other_ method for notifying the terminal when there's more input to be consumed during an interactive prompt, and for notifying the backend when prompt input has finished so that it can proceed to the next stage of the protocol. This is done by a pair of extra callbacks: when more data is put on to Ldisc's input queue, it triggers a call to term_get_userpass_input, and when term_get_userpass_input finishes, it calls a callback function provided in the prompts_t. Therefore, any use of a prompts_t which *might* be asynchronous must fill in the latter callback when setting up the prompts_t. In SSH, the callback is centralised into a common PPL helper function, which reinvokes the same PPL's process_queue coroutine; in rlogin we have to set it up ourselves. I'm sorry for this large and sprawling patch: I tried fairly hard to break it up into individually comprehensible sub-patches, but I just couldn't tease out any part of it that would stand sensibly alone.
2021-09-14 10:57:21 +00:00
delete_callbacks_for_context(ldisc);
Add the ability to close sessions. This adds *_free() functions to most areas of the code. Not all back-ends have been tested, but Telnet and SSH behave reasonably. Incidentally, almost all of this patch was written through Mac PuTTY, admittedly over a Telnet connection. [originally from svn r2615]
2003-01-15 23:30:21 +00:00
sfree(ldisc);
}
Expose the Ldisc structure tag throughout the code. That's one fewer anonymous 'void *' which might be accidentally confused with some other pointer type if I misremember the order of function arguments. While I'm here, I've made its pointer-nature explicit - that is, 'Ldisc' is now a typedef for the structure type itself rather than a pointer to it. A stylistic change only, but it feels more natural to me these days for a thing you're going to eventually pass to a 'free' function.
2018-09-11 14:02:59 +00:00
void ldisc_echoedit_update(Ldisc *ldisc)
Move echo/edit state change functionality out of ldisc_send. I'm not actually sure why we've always had back ends notify ldisc of changes to echo/edit settings by giving ldisc_send(ldisc,NULL,0,0) a special meaning, instead of by having a separate dedicated notify function with its own prototype and parameter set. Coverity's recent observation that the two kinds of call don't even have the same requirements on the ldisc (particularly, whether ldisc->term can be NULL) makes me realise that it's really high time I separated the two conceptually different operations into actually different functions. While I'm here, I've renamed the confusing ldisc_update() function which that special operation ends up feeding to, because it's not actually a function applying to an ldisc - it applies to a front end. So ldisc_send(ldisc,NULL,0,0) is now ldisc_echoedit_update(ldisc), and that in turn figures out the current echo/edit settings before passing them on to frontend_echoedit_update(). I think that should be clearer.
2014-11-22 16:12:47 +00:00
{
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
seat_echoedit_update(ldisc->seat, ECHOING, EDITING);
Move echo/edit state change functionality out of ldisc_send. I'm not actually sure why we've always had back ends notify ldisc of changes to echo/edit settings by giving ldisc_send(ldisc,NULL,0,0) a special meaning, instead of by having a separate dedicated notify function with its own prototype and parameter set. Coverity's recent observation that the two kinds of call don't even have the same requirements on the ldisc (particularly, whether ldisc->term can be NULL) makes me realise that it's really high time I separated the two conceptually different operations into actually different functions. While I'm here, I've renamed the confusing ldisc_update() function which that special operation ends up feeding to, because it's not actually a function applying to an ldisc - it applies to a front end. So ldisc_send(ldisc,NULL,0,0) is now ldisc_echoedit_update(ldisc), and that in turn figures out the current echo/edit settings before passing them on to frontend_echoedit_update(). I think that should be clearer.
2014-11-22 16:12:47 +00:00
Complete rework of terminal userpass input system. The system for handling seat_get_userpass_input has always been structured differently between GUI PuTTY and CLI tools like Plink. In the CLI tools, password input is read directly from the OS terminal/console device by console_get_userpass_input; this means that you need to ensure the same terminal input data _hasn't_ already been consumed by the main event loop and sent on to the backend. This is achieved by the backend_sendok() method, which tells the event loop when the backend has finished issuing password prompts, and hence, when it's safe to start passing standard input to backend_send(). But in the GUI tools, input generated by the terminal window has always been sent straight to backend_send(), regardless of whether backend_sendok() says it wants it. So the terminal-based implementation of username and password prompts has to work by consuming input data that had _already_ been passed to the backend - hence, any backend that needs to do that must keep its input on a bufchain, and pass that bufchain to seat_get_userpass_input. It's awkward that these two totally different systems coexist in the first place. And now that SSH proxying needs to present interactive prompts of its own, it's clear which one should win: the CLI style is the Right Thing. So this change reworks the GUI side of the mechanism to be more similar: terminal data now goes into a queue in the Ldisc, and is not sent on to the backend until the backend says it's ready for it via backend_sendok(). So terminal-based userpass prompts can now consume data directly from that queue during the connection setup stage. As a result, the 'bufchain *' parameter has vanished from all the userpass_input functions (both the official implementations of the Seat trait method, and term_get_userpass_input() to which some of those implementations delegate). The only function that actually used that bufchain, namely term_get_userpass_input(), now instead reads from the ldisc's input queue via a couple of new Ldisc functions. (Not _trivial_ functions, since input buffered by Ldisc can be a mixture of raw bytes and session specials like SS_EOL! The input queue inside Ldisc is a bufchain containing a fiddly binary encoding that can represent an arbitrary interleaving of those things.) This greatly simplifies the calls to seat_get_userpass_input in backends, which now don't have to mess about with passing their own user_input bufchain around, or toggling their want_user_input flag back and forth to request data to put on to that bufchain. But the flip side is that now there has to be some _other_ method for notifying the terminal when there's more input to be consumed during an interactive prompt, and for notifying the backend when prompt input has finished so that it can proceed to the next stage of the protocol. This is done by a pair of extra callbacks: when more data is put on to Ldisc's input queue, it triggers a call to term_get_userpass_input, and when term_get_userpass_input finishes, it calls a callback function provided in the prompts_t. Therefore, any use of a prompts_t which *might* be asynchronous must fill in the latter callback when setting up the prompts_t. In SSH, the callback is centralised into a common PPL helper function, which reinvokes the same PPL's process_queue coroutine; in rlogin we have to set it up ourselves. I'm sorry for this large and sprawling patch: I tried fairly hard to break it up into individually comprehensible sub-patches, but I just couldn't tease out any part of it that would stand sensibly alone.
2021-09-14 10:57:21 +00:00
/*
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
* If we've just turned off local line editing mode, and our
* TermLineEditor had a partial buffer, then send the contents of
* the buffer. Rationale: (a) otherwise you lose data; (b) the
* user quite likely typed the buffer contents _anticipating_ that
* local editing would be turned off shortly, and the event was
* slow arriving.
Complete rework of terminal userpass input system. The system for handling seat_get_userpass_input has always been structured differently between GUI PuTTY and CLI tools like Plink. In the CLI tools, password input is read directly from the OS terminal/console device by console_get_userpass_input; this means that you need to ensure the same terminal input data _hasn't_ already been consumed by the main event loop and sent on to the backend. This is achieved by the backend_sendok() method, which tells the event loop when the backend has finished issuing password prompts, and hence, when it's safe to start passing standard input to backend_send(). But in the GUI tools, input generated by the terminal window has always been sent straight to backend_send(), regardless of whether backend_sendok() says it wants it. So the terminal-based implementation of username and password prompts has to work by consuming input data that had _already_ been passed to the backend - hence, any backend that needs to do that must keep its input on a bufchain, and pass that bufchain to seat_get_userpass_input. It's awkward that these two totally different systems coexist in the first place. And now that SSH proxying needs to present interactive prompts of its own, it's clear which one should win: the CLI style is the Right Thing. So this change reworks the GUI side of the mechanism to be more similar: terminal data now goes into a queue in the Ldisc, and is not sent on to the backend until the backend says it's ready for it via backend_sendok(). So terminal-based userpass prompts can now consume data directly from that queue during the connection setup stage. As a result, the 'bufchain *' parameter has vanished from all the userpass_input functions (both the official implementations of the Seat trait method, and term_get_userpass_input() to which some of those implementations delegate). The only function that actually used that bufchain, namely term_get_userpass_input(), now instead reads from the ldisc's input queue via a couple of new Ldisc functions. (Not _trivial_ functions, since input buffered by Ldisc can be a mixture of raw bytes and session specials like SS_EOL! The input queue inside Ldisc is a bufchain containing a fiddly binary encoding that can represent an arbitrary interleaving of those things.) This greatly simplifies the calls to seat_get_userpass_input in backends, which now don't have to mess about with passing their own user_input bufchain around, or toggling their want_user_input flag back and forth to request data to put on to that bufchain. But the flip side is that now there has to be some _other_ method for notifying the terminal when there's more input to be consumed during an interactive prompt, and for notifying the backend when prompt input has finished so that it can proceed to the next stage of the protocol. This is done by a pair of extra callbacks: when more data is put on to Ldisc's input queue, it triggers a call to term_get_userpass_input, and when term_get_userpass_input finishes, it calls a callback function provided in the prompts_t. Therefore, any use of a prompts_t which *might* be asynchronous must fill in the latter callback when setting up the prompts_t. In SSH, the callback is centralised into a common PPL helper function, which reinvokes the same PPL's process_queue coroutine; in rlogin we have to set it up ourselves. I'm sorry for this large and sprawling patch: I tried fairly hard to break it up into individually comprehensible sub-patches, but I just couldn't tease out any part of it that would stand sensibly alone.
2021-09-14 10:57:21 +00:00
*/
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
if (!EDITING)
lineedit_send_line(ldisc->le);
Complete rework of terminal userpass input system. The system for handling seat_get_userpass_input has always been structured differently between GUI PuTTY and CLI tools like Plink. In the CLI tools, password input is read directly from the OS terminal/console device by console_get_userpass_input; this means that you need to ensure the same terminal input data _hasn't_ already been consumed by the main event loop and sent on to the backend. This is achieved by the backend_sendok() method, which tells the event loop when the backend has finished issuing password prompts, and hence, when it's safe to start passing standard input to backend_send(). But in the GUI tools, input generated by the terminal window has always been sent straight to backend_send(), regardless of whether backend_sendok() says it wants it. So the terminal-based implementation of username and password prompts has to work by consuming input data that had _already_ been passed to the backend - hence, any backend that needs to do that must keep its input on a bufchain, and pass that bufchain to seat_get_userpass_input. It's awkward that these two totally different systems coexist in the first place. And now that SSH proxying needs to present interactive prompts of its own, it's clear which one should win: the CLI style is the Right Thing. So this change reworks the GUI side of the mechanism to be more similar: terminal data now goes into a queue in the Ldisc, and is not sent on to the backend until the backend says it's ready for it via backend_sendok(). So terminal-based userpass prompts can now consume data directly from that queue during the connection setup stage. As a result, the 'bufchain *' parameter has vanished from all the userpass_input functions (both the official implementations of the Seat trait method, and term_get_userpass_input() to which some of those implementations delegate). The only function that actually used that bufchain, namely term_get_userpass_input(), now instead reads from the ldisc's input queue via a couple of new Ldisc functions. (Not _trivial_ functions, since input buffered by Ldisc can be a mixture of raw bytes and session specials like SS_EOL! The input queue inside Ldisc is a bufchain containing a fiddly binary encoding that can represent an arbitrary interleaving of those things.) This greatly simplifies the calls to seat_get_userpass_input in backends, which now don't have to mess about with passing their own user_input bufchain around, or toggling their want_user_input flag back and forth to request data to put on to that bufchain. But the flip side is that now there has to be some _other_ method for notifying the terminal when there's more input to be consumed during an interactive prompt, and for notifying the backend when prompt input has finished so that it can proceed to the next stage of the protocol. This is done by a pair of extra callbacks: when more data is put on to Ldisc's input queue, it triggers a call to term_get_userpass_input, and when term_get_userpass_input finishes, it calls a callback function provided in the prompts_t. Therefore, any use of a prompts_t which *might* be asynchronous must fill in the latter callback when setting up the prompts_t. In SSH, the callback is centralised into a common PPL helper function, which reinvokes the same PPL's process_queue coroutine; in rlogin we have to set it up ourselves. I'm sorry for this large and sprawling patch: I tried fairly hard to break it up into individually comprehensible sub-patches, but I just couldn't tease out any part of it that would stand sensibly alone.
2021-09-14 10:57:21 +00:00
}
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
void ldisc_provide_userpass_le(Ldisc *ldisc, TermLineEditor *le)
Complete rework of terminal userpass input system. The system for handling seat_get_userpass_input has always been structured differently between GUI PuTTY and CLI tools like Plink. In the CLI tools, password input is read directly from the OS terminal/console device by console_get_userpass_input; this means that you need to ensure the same terminal input data _hasn't_ already been consumed by the main event loop and sent on to the backend. This is achieved by the backend_sendok() method, which tells the event loop when the backend has finished issuing password prompts, and hence, when it's safe to start passing standard input to backend_send(). But in the GUI tools, input generated by the terminal window has always been sent straight to backend_send(), regardless of whether backend_sendok() says it wants it. So the terminal-based implementation of username and password prompts has to work by consuming input data that had _already_ been passed to the backend - hence, any backend that needs to do that must keep its input on a bufchain, and pass that bufchain to seat_get_userpass_input. It's awkward that these two totally different systems coexist in the first place. And now that SSH proxying needs to present interactive prompts of its own, it's clear which one should win: the CLI style is the Right Thing. So this change reworks the GUI side of the mechanism to be more similar: terminal data now goes into a queue in the Ldisc, and is not sent on to the backend until the backend says it's ready for it via backend_sendok(). So terminal-based userpass prompts can now consume data directly from that queue during the connection setup stage. As a result, the 'bufchain *' parameter has vanished from all the userpass_input functions (both the official implementations of the Seat trait method, and term_get_userpass_input() to which some of those implementations delegate). The only function that actually used that bufchain, namely term_get_userpass_input(), now instead reads from the ldisc's input queue via a couple of new Ldisc functions. (Not _trivial_ functions, since input buffered by Ldisc can be a mixture of raw bytes and session specials like SS_EOL! The input queue inside Ldisc is a bufchain containing a fiddly binary encoding that can represent an arbitrary interleaving of those things.) This greatly simplifies the calls to seat_get_userpass_input in backends, which now don't have to mess about with passing their own user_input bufchain around, or toggling their want_user_input flag back and forth to request data to put on to that bufchain. But the flip side is that now there has to be some _other_ method for notifying the terminal when there's more input to be consumed during an interactive prompt, and for notifying the backend when prompt input has finished so that it can proceed to the next stage of the protocol. This is done by a pair of extra callbacks: when more data is put on to Ldisc's input queue, it triggers a call to term_get_userpass_input, and when term_get_userpass_input finishes, it calls a callback function provided in the prompts_t. Therefore, any use of a prompts_t which *might* be asynchronous must fill in the latter callback when setting up the prompts_t. In SSH, the callback is centralised into a common PPL helper function, which reinvokes the same PPL's process_queue coroutine; in rlogin we have to set it up ourselves. I'm sorry for this large and sprawling patch: I tried fairly hard to break it up into individually comprehensible sub-patches, but I just couldn't tease out any part of it that would stand sensibly alone.
2021-09-14 10:57:21 +00:00
{
/*
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
* Called by term_get_userpass_input to tell us when it has its
* own TermLineEditor processing a password prompt, so that we can
* inject our input into that instead of putting it into our own
* TermLineEditor or sending it straight to the backend.
Complete rework of terminal userpass input system. The system for handling seat_get_userpass_input has always been structured differently between GUI PuTTY and CLI tools like Plink. In the CLI tools, password input is read directly from the OS terminal/console device by console_get_userpass_input; this means that you need to ensure the same terminal input data _hasn't_ already been consumed by the main event loop and sent on to the backend. This is achieved by the backend_sendok() method, which tells the event loop when the backend has finished issuing password prompts, and hence, when it's safe to start passing standard input to backend_send(). But in the GUI tools, input generated by the terminal window has always been sent straight to backend_send(), regardless of whether backend_sendok() says it wants it. So the terminal-based implementation of username and password prompts has to work by consuming input data that had _already_ been passed to the backend - hence, any backend that needs to do that must keep its input on a bufchain, and pass that bufchain to seat_get_userpass_input. It's awkward that these two totally different systems coexist in the first place. And now that SSH proxying needs to present interactive prompts of its own, it's clear which one should win: the CLI style is the Right Thing. So this change reworks the GUI side of the mechanism to be more similar: terminal data now goes into a queue in the Ldisc, and is not sent on to the backend until the backend says it's ready for it via backend_sendok(). So terminal-based userpass prompts can now consume data directly from that queue during the connection setup stage. As a result, the 'bufchain *' parameter has vanished from all the userpass_input functions (both the official implementations of the Seat trait method, and term_get_userpass_input() to which some of those implementations delegate). The only function that actually used that bufchain, namely term_get_userpass_input(), now instead reads from the ldisc's input queue via a couple of new Ldisc functions. (Not _trivial_ functions, since input buffered by Ldisc can be a mixture of raw bytes and session specials like SS_EOL! The input queue inside Ldisc is a bufchain containing a fiddly binary encoding that can represent an arbitrary interleaving of those things.) This greatly simplifies the calls to seat_get_userpass_input in backends, which now don't have to mess about with passing their own user_input bufchain around, or toggling their want_user_input flag back and forth to request data to put on to that bufchain. But the flip side is that now there has to be some _other_ method for notifying the terminal when there's more input to be consumed during an interactive prompt, and for notifying the backend when prompt input has finished so that it can proceed to the next stage of the protocol. This is done by a pair of extra callbacks: when more data is put on to Ldisc's input queue, it triggers a call to term_get_userpass_input, and when term_get_userpass_input finishes, it calls a callback function provided in the prompts_t. Therefore, any use of a prompts_t which *might* be asynchronous must fill in the latter callback when setting up the prompts_t. In SSH, the callback is centralised into a common PPL helper function, which reinvokes the same PPL's process_queue coroutine; in rlogin we have to set it up ourselves. I'm sorry for this large and sprawling patch: I tried fairly hard to break it up into individually comprehensible sub-patches, but I just couldn't tease out any part of it that would stand sensibly alone.
2021-09-14 10:57:21 +00:00
*/
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
ldisc->userpass_le = le;
}
static inline bool is_dedicated_byte(char c, InputType type)
{
switch (type) {
case DEDICATED:
return true;
case NORMAL:
return false;
case NONINTERACTIVE:
Complete rework of terminal userpass input system. The system for handling seat_get_userpass_input has always been structured differently between GUI PuTTY and CLI tools like Plink. In the CLI tools, password input is read directly from the OS terminal/console device by console_get_userpass_input; this means that you need to ensure the same terminal input data _hasn't_ already been consumed by the main event loop and sent on to the backend. This is achieved by the backend_sendok() method, which tells the event loop when the backend has finished issuing password prompts, and hence, when it's safe to start passing standard input to backend_send(). But in the GUI tools, input generated by the terminal window has always been sent straight to backend_send(), regardless of whether backend_sendok() says it wants it. So the terminal-based implementation of username and password prompts has to work by consuming input data that had _already_ been passed to the backend - hence, any backend that needs to do that must keep its input on a bufchain, and pass that bufchain to seat_get_userpass_input. It's awkward that these two totally different systems coexist in the first place. And now that SSH proxying needs to present interactive prompts of its own, it's clear which one should win: the CLI style is the Right Thing. So this change reworks the GUI side of the mechanism to be more similar: terminal data now goes into a queue in the Ldisc, and is not sent on to the backend until the backend says it's ready for it via backend_sendok(). So terminal-based userpass prompts can now consume data directly from that queue during the connection setup stage. As a result, the 'bufchain *' parameter has vanished from all the userpass_input functions (both the official implementations of the Seat trait method, and term_get_userpass_input() to which some of those implementations delegate). The only function that actually used that bufchain, namely term_get_userpass_input(), now instead reads from the ldisc's input queue via a couple of new Ldisc functions. (Not _trivial_ functions, since input buffered by Ldisc can be a mixture of raw bytes and session specials like SS_EOL! The input queue inside Ldisc is a bufchain containing a fiddly binary encoding that can represent an arbitrary interleaving of those things.) This greatly simplifies the calls to seat_get_userpass_input in backends, which now don't have to mess about with passing their own user_input bufchain around, or toggling their want_user_input flag back and forth to request data to put on to that bufchain. But the flip side is that now there has to be some _other_ method for notifying the terminal when there's more input to be consumed during an interactive prompt, and for notifying the backend when prompt input has finished so that it can proceed to the next stage of the protocol. This is done by a pair of extra callbacks: when more data is put on to Ldisc's input queue, it triggers a call to term_get_userpass_input, and when term_get_userpass_input finishes, it calls a callback function provided in the prompts_t. Therefore, any use of a prompts_t which *might* be asynchronous must fill in the latter callback when setting up the prompts_t. In SSH, the callback is centralised into a common PPL helper function, which reinvokes the same PPL's process_queue coroutine; in rlogin we have to set it up ourselves. I'm sorry for this large and sprawling patch: I tried fairly hard to break it up into individually comprehensible sub-patches, but I just couldn't tease out any part of it that would stand sensibly alone.
2021-09-14 10:57:21 +00:00
/*
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
* Non-interactive input (e.g. from a paste) doesn't come with
* the ability to distinguish dedicated keypresses like Return
* from generic ones like Ctrl+M. So we just have to make up
* an answer to this question. In particular, we _must_ treat
* Ctrl+M as the Return key, because that's the only way a
* newline can be pasted at all.
Complete rework of terminal userpass input system. The system for handling seat_get_userpass_input has always been structured differently between GUI PuTTY and CLI tools like Plink. In the CLI tools, password input is read directly from the OS terminal/console device by console_get_userpass_input; this means that you need to ensure the same terminal input data _hasn't_ already been consumed by the main event loop and sent on to the backend. This is achieved by the backend_sendok() method, which tells the event loop when the backend has finished issuing password prompts, and hence, when it's safe to start passing standard input to backend_send(). But in the GUI tools, input generated by the terminal window has always been sent straight to backend_send(), regardless of whether backend_sendok() says it wants it. So the terminal-based implementation of username and password prompts has to work by consuming input data that had _already_ been passed to the backend - hence, any backend that needs to do that must keep its input on a bufchain, and pass that bufchain to seat_get_userpass_input. It's awkward that these two totally different systems coexist in the first place. And now that SSH proxying needs to present interactive prompts of its own, it's clear which one should win: the CLI style is the Right Thing. So this change reworks the GUI side of the mechanism to be more similar: terminal data now goes into a queue in the Ldisc, and is not sent on to the backend until the backend says it's ready for it via backend_sendok(). So terminal-based userpass prompts can now consume data directly from that queue during the connection setup stage. As a result, the 'bufchain *' parameter has vanished from all the userpass_input functions (both the official implementations of the Seat trait method, and term_get_userpass_input() to which some of those implementations delegate). The only function that actually used that bufchain, namely term_get_userpass_input(), now instead reads from the ldisc's input queue via a couple of new Ldisc functions. (Not _trivial_ functions, since input buffered by Ldisc can be a mixture of raw bytes and session specials like SS_EOL! The input queue inside Ldisc is a bufchain containing a fiddly binary encoding that can represent an arbitrary interleaving of those things.) This greatly simplifies the calls to seat_get_userpass_input in backends, which now don't have to mess about with passing their own user_input bufchain around, or toggling their want_user_input flag back and forth to request data to put on to that bufchain. But the flip side is that now there has to be some _other_ method for notifying the terminal when there's more input to be consumed during an interactive prompt, and for notifying the backend when prompt input has finished so that it can proceed to the next stage of the protocol. This is done by a pair of extra callbacks: when more data is put on to Ldisc's input queue, it triggers a call to term_get_userpass_input, and when term_get_userpass_input finishes, it calls a callback function provided in the prompts_t. Therefore, any use of a prompts_t which *might* be asynchronous must fill in the latter callback when setting up the prompts_t. In SSH, the callback is centralised into a common PPL helper function, which reinvokes the same PPL's process_queue coroutine; in rlogin we have to set it up ourselves. I'm sorry for this large and sprawling patch: I tried fairly hard to break it up into individually comprehensible sub-patches, but I just couldn't tease out any part of it that would stand sensibly alone.
2021-09-14 10:57:21 +00:00
*/
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
return c == '\r';
default:
unreachable("those values should be exhaustive");
Complete rework of terminal userpass input system. The system for handling seat_get_userpass_input has always been structured differently between GUI PuTTY and CLI tools like Plink. In the CLI tools, password input is read directly from the OS terminal/console device by console_get_userpass_input; this means that you need to ensure the same terminal input data _hasn't_ already been consumed by the main event loop and sent on to the backend. This is achieved by the backend_sendok() method, which tells the event loop when the backend has finished issuing password prompts, and hence, when it's safe to start passing standard input to backend_send(). But in the GUI tools, input generated by the terminal window has always been sent straight to backend_send(), regardless of whether backend_sendok() says it wants it. So the terminal-based implementation of username and password prompts has to work by consuming input data that had _already_ been passed to the backend - hence, any backend that needs to do that must keep its input on a bufchain, and pass that bufchain to seat_get_userpass_input. It's awkward that these two totally different systems coexist in the first place. And now that SSH proxying needs to present interactive prompts of its own, it's clear which one should win: the CLI style is the Right Thing. So this change reworks the GUI side of the mechanism to be more similar: terminal data now goes into a queue in the Ldisc, and is not sent on to the backend until the backend says it's ready for it via backend_sendok(). So terminal-based userpass prompts can now consume data directly from that queue during the connection setup stage. As a result, the 'bufchain *' parameter has vanished from all the userpass_input functions (both the official implementations of the Seat trait method, and term_get_userpass_input() to which some of those implementations delegate). The only function that actually used that bufchain, namely term_get_userpass_input(), now instead reads from the ldisc's input queue via a couple of new Ldisc functions. (Not _trivial_ functions, since input buffered by Ldisc can be a mixture of raw bytes and session specials like SS_EOL! The input queue inside Ldisc is a bufchain containing a fiddly binary encoding that can represent an arbitrary interleaving of those things.) This greatly simplifies the calls to seat_get_userpass_input in backends, which now don't have to mess about with passing their own user_input bufchain around, or toggling their want_user_input flag back and forth to request data to put on to that bufchain. But the flip side is that now there has to be some _other_ method for notifying the terminal when there's more input to be consumed during an interactive prompt, and for notifying the backend when prompt input has finished so that it can proceed to the next stage of the protocol. This is done by a pair of extra callbacks: when more data is put on to Ldisc's input queue, it triggers a call to term_get_userpass_input, and when term_get_userpass_input finishes, it calls a callback function provided in the prompts_t. Therefore, any use of a prompts_t which *might* be asynchronous must fill in the latter callback when setting up the prompts_t. In SSH, the callback is centralised into a common PPL helper function, which reinvokes the same PPL's process_queue coroutine; in rlogin we have to set it up ourselves. I'm sorry for this large and sprawling patch: I tried fairly hard to break it up into individually comprehensible sub-patches, but I just couldn't tease out any part of it that would stand sensibly alone.
2021-09-14 10:57:21 +00:00
}
}
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
static void ldisc_input_queue_consume(Ldisc *ldisc, size_t size)
Complete rework of terminal userpass input system. The system for handling seat_get_userpass_input has always been structured differently between GUI PuTTY and CLI tools like Plink. In the CLI tools, password input is read directly from the OS terminal/console device by console_get_userpass_input; this means that you need to ensure the same terminal input data _hasn't_ already been consumed by the main event loop and sent on to the backend. This is achieved by the backend_sendok() method, which tells the event loop when the backend has finished issuing password prompts, and hence, when it's safe to start passing standard input to backend_send(). But in the GUI tools, input generated by the terminal window has always been sent straight to backend_send(), regardless of whether backend_sendok() says it wants it. So the terminal-based implementation of username and password prompts has to work by consuming input data that had _already_ been passed to the backend - hence, any backend that needs to do that must keep its input on a bufchain, and pass that bufchain to seat_get_userpass_input. It's awkward that these two totally different systems coexist in the first place. And now that SSH proxying needs to present interactive prompts of its own, it's clear which one should win: the CLI style is the Right Thing. So this change reworks the GUI side of the mechanism to be more similar: terminal data now goes into a queue in the Ldisc, and is not sent on to the backend until the backend says it's ready for it via backend_sendok(). So terminal-based userpass prompts can now consume data directly from that queue during the connection setup stage. As a result, the 'bufchain *' parameter has vanished from all the userpass_input functions (both the official implementations of the Seat trait method, and term_get_userpass_input() to which some of those implementations delegate). The only function that actually used that bufchain, namely term_get_userpass_input(), now instead reads from the ldisc's input queue via a couple of new Ldisc functions. (Not _trivial_ functions, since input buffered by Ldisc can be a mixture of raw bytes and session specials like SS_EOL! The input queue inside Ldisc is a bufchain containing a fiddly binary encoding that can represent an arbitrary interleaving of those things.) This greatly simplifies the calls to seat_get_userpass_input in backends, which now don't have to mess about with passing their own user_input bufchain around, or toggling their want_user_input flag back and forth to request data to put on to that bufchain. But the flip side is that now there has to be some _other_ method for notifying the terminal when there's more input to be consumed during an interactive prompt, and for notifying the backend when prompt input has finished so that it can proceed to the next stage of the protocol. This is done by a pair of extra callbacks: when more data is put on to Ldisc's input queue, it triggers a call to term_get_userpass_input, and when term_get_userpass_input finishes, it calls a callback function provided in the prompts_t. Therefore, any use of a prompts_t which *might* be asynchronous must fill in the latter callback when setting up the prompts_t. In SSH, the callback is centralised into a common PPL helper function, which reinvokes the same PPL's process_queue coroutine; in rlogin we have to set it up ourselves. I'm sorry for this large and sprawling patch: I tried fairly hard to break it up into individually comprehensible sub-patches, but I just couldn't tease out any part of it that would stand sensibly alone.
2021-09-14 10:57:21 +00:00
{
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
bufchain_consume(&ldisc->input_queue, size);
while (size > 0) {
size_t thissize = (size < ldisc->inchunk_head->size ?
size : ldisc->inchunk_head->size);
ldisc->inchunk_head->size -= thissize;
size -= thissize;
if (!ldisc->inchunk_head->size) {
struct input_chunk *oldhead = ldisc->inchunk_head;
ldisc->inchunk_head = ldisc->inchunk_head->next;
if (!ldisc->inchunk_head)
ldisc->inchunk_tail = NULL;
sfree(oldhead);
Complete rework of terminal userpass input system. The system for handling seat_get_userpass_input has always been structured differently between GUI PuTTY and CLI tools like Plink. In the CLI tools, password input is read directly from the OS terminal/console device by console_get_userpass_input; this means that you need to ensure the same terminal input data _hasn't_ already been consumed by the main event loop and sent on to the backend. This is achieved by the backend_sendok() method, which tells the event loop when the backend has finished issuing password prompts, and hence, when it's safe to start passing standard input to backend_send(). But in the GUI tools, input generated by the terminal window has always been sent straight to backend_send(), regardless of whether backend_sendok() says it wants it. So the terminal-based implementation of username and password prompts has to work by consuming input data that had _already_ been passed to the backend - hence, any backend that needs to do that must keep its input on a bufchain, and pass that bufchain to seat_get_userpass_input. It's awkward that these two totally different systems coexist in the first place. And now that SSH proxying needs to present interactive prompts of its own, it's clear which one should win: the CLI style is the Right Thing. So this change reworks the GUI side of the mechanism to be more similar: terminal data now goes into a queue in the Ldisc, and is not sent on to the backend until the backend says it's ready for it via backend_sendok(). So terminal-based userpass prompts can now consume data directly from that queue during the connection setup stage. As a result, the 'bufchain *' parameter has vanished from all the userpass_input functions (both the official implementations of the Seat trait method, and term_get_userpass_input() to which some of those implementations delegate). The only function that actually used that bufchain, namely term_get_userpass_input(), now instead reads from the ldisc's input queue via a couple of new Ldisc functions. (Not _trivial_ functions, since input buffered by Ldisc can be a mixture of raw bytes and session specials like SS_EOL! The input queue inside Ldisc is a bufchain containing a fiddly binary encoding that can represent an arbitrary interleaving of those things.) This greatly simplifies the calls to seat_get_userpass_input in backends, which now don't have to mess about with passing their own user_input bufchain around, or toggling their want_user_input flag back and forth to request data to put on to that bufchain. But the flip side is that now there has to be some _other_ method for notifying the terminal when there's more input to be consumed during an interactive prompt, and for notifying the backend when prompt input has finished so that it can proceed to the next stage of the protocol. This is done by a pair of extra callbacks: when more data is put on to Ldisc's input queue, it triggers a call to term_get_userpass_input, and when term_get_userpass_input finishes, it calls a callback function provided in the prompts_t. Therefore, any use of a prompts_t which *might* be asynchronous must fill in the latter callback when setting up the prompts_t. In SSH, the callback is centralised into a common PPL helper function, which reinvokes the same PPL's process_queue coroutine; in rlogin we have to set it up ourselves. I'm sorry for this large and sprawling patch: I tried fairly hard to break it up into individually comprehensible sub-patches, but I just couldn't tease out any part of it that would stand sensibly alone.
2021-09-14 10:57:21 +00:00
}
}
}
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
static void ldisc_lineedit_to_terminal(
TermLineEditorCallbackReceiver *rcv, ptrlen data)
Complete rework of terminal userpass input system. The system for handling seat_get_userpass_input has always been structured differently between GUI PuTTY and CLI tools like Plink. In the CLI tools, password input is read directly from the OS terminal/console device by console_get_userpass_input; this means that you need to ensure the same terminal input data _hasn't_ already been consumed by the main event loop and sent on to the backend. This is achieved by the backend_sendok() method, which tells the event loop when the backend has finished issuing password prompts, and hence, when it's safe to start passing standard input to backend_send(). But in the GUI tools, input generated by the terminal window has always been sent straight to backend_send(), regardless of whether backend_sendok() says it wants it. So the terminal-based implementation of username and password prompts has to work by consuming input data that had _already_ been passed to the backend - hence, any backend that needs to do that must keep its input on a bufchain, and pass that bufchain to seat_get_userpass_input. It's awkward that these two totally different systems coexist in the first place. And now that SSH proxying needs to present interactive prompts of its own, it's clear which one should win: the CLI style is the Right Thing. So this change reworks the GUI side of the mechanism to be more similar: terminal data now goes into a queue in the Ldisc, and is not sent on to the backend until the backend says it's ready for it via backend_sendok(). So terminal-based userpass prompts can now consume data directly from that queue during the connection setup stage. As a result, the 'bufchain *' parameter has vanished from all the userpass_input functions (both the official implementations of the Seat trait method, and term_get_userpass_input() to which some of those implementations delegate). The only function that actually used that bufchain, namely term_get_userpass_input(), now instead reads from the ldisc's input queue via a couple of new Ldisc functions. (Not _trivial_ functions, since input buffered by Ldisc can be a mixture of raw bytes and session specials like SS_EOL! The input queue inside Ldisc is a bufchain containing a fiddly binary encoding that can represent an arbitrary interleaving of those things.) This greatly simplifies the calls to seat_get_userpass_input in backends, which now don't have to mess about with passing their own user_input bufchain around, or toggling their want_user_input flag back and forth to request data to put on to that bufchain. But the flip side is that now there has to be some _other_ method for notifying the terminal when there's more input to be consumed during an interactive prompt, and for notifying the backend when prompt input has finished so that it can proceed to the next stage of the protocol. This is done by a pair of extra callbacks: when more data is put on to Ldisc's input queue, it triggers a call to term_get_userpass_input, and when term_get_userpass_input finishes, it calls a callback function provided in the prompts_t. Therefore, any use of a prompts_t which *might* be asynchronous must fill in the latter callback when setting up the prompts_t. In SSH, the callback is centralised into a common PPL helper function, which reinvokes the same PPL's process_queue coroutine; in rlogin we have to set it up ourselves. I'm sorry for this large and sprawling patch: I tried fairly hard to break it up into individually comprehensible sub-patches, but I just couldn't tease out any part of it that would stand sensibly alone.
2021-09-14 10:57:21 +00:00
{
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
Ldisc *ldisc = container_of(rcv, Ldisc, le_rcv);
if (ECHOING)
seat_stdout(ldisc->seat, data.ptr, data.len);
Complete rework of terminal userpass input system. The system for handling seat_get_userpass_input has always been structured differently between GUI PuTTY and CLI tools like Plink. In the CLI tools, password input is read directly from the OS terminal/console device by console_get_userpass_input; this means that you need to ensure the same terminal input data _hasn't_ already been consumed by the main event loop and sent on to the backend. This is achieved by the backend_sendok() method, which tells the event loop when the backend has finished issuing password prompts, and hence, when it's safe to start passing standard input to backend_send(). But in the GUI tools, input generated by the terminal window has always been sent straight to backend_send(), regardless of whether backend_sendok() says it wants it. So the terminal-based implementation of username and password prompts has to work by consuming input data that had _already_ been passed to the backend - hence, any backend that needs to do that must keep its input on a bufchain, and pass that bufchain to seat_get_userpass_input. It's awkward that these two totally different systems coexist in the first place. And now that SSH proxying needs to present interactive prompts of its own, it's clear which one should win: the CLI style is the Right Thing. So this change reworks the GUI side of the mechanism to be more similar: terminal data now goes into a queue in the Ldisc, and is not sent on to the backend until the backend says it's ready for it via backend_sendok(). So terminal-based userpass prompts can now consume data directly from that queue during the connection setup stage. As a result, the 'bufchain *' parameter has vanished from all the userpass_input functions (both the official implementations of the Seat trait method, and term_get_userpass_input() to which some of those implementations delegate). The only function that actually used that bufchain, namely term_get_userpass_input(), now instead reads from the ldisc's input queue via a couple of new Ldisc functions. (Not _trivial_ functions, since input buffered by Ldisc can be a mixture of raw bytes and session specials like SS_EOL! The input queue inside Ldisc is a bufchain containing a fiddly binary encoding that can represent an arbitrary interleaving of those things.) This greatly simplifies the calls to seat_get_userpass_input in backends, which now don't have to mess about with passing their own user_input bufchain around, or toggling their want_user_input flag back and forth to request data to put on to that bufchain. But the flip side is that now there has to be some _other_ method for notifying the terminal when there's more input to be consumed during an interactive prompt, and for notifying the backend when prompt input has finished so that it can proceed to the next stage of the protocol. This is done by a pair of extra callbacks: when more data is put on to Ldisc's input queue, it triggers a call to term_get_userpass_input, and when term_get_userpass_input finishes, it calls a callback function provided in the prompts_t. Therefore, any use of a prompts_t which *might* be asynchronous must fill in the latter callback when setting up the prompts_t. In SSH, the callback is centralised into a common PPL helper function, which reinvokes the same PPL's process_queue coroutine; in rlogin we have to set it up ourselves. I'm sorry for this large and sprawling patch: I tried fairly hard to break it up into individually comprehensible sub-patches, but I just couldn't tease out any part of it that would stand sensibly alone.
2021-09-14 10:57:21 +00:00
}
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
static void ldisc_lineedit_to_backend(
TermLineEditorCallbackReceiver *rcv, ptrlen data)
Complete rework of terminal userpass input system. The system for handling seat_get_userpass_input has always been structured differently between GUI PuTTY and CLI tools like Plink. In the CLI tools, password input is read directly from the OS terminal/console device by console_get_userpass_input; this means that you need to ensure the same terminal input data _hasn't_ already been consumed by the main event loop and sent on to the backend. This is achieved by the backend_sendok() method, which tells the event loop when the backend has finished issuing password prompts, and hence, when it's safe to start passing standard input to backend_send(). But in the GUI tools, input generated by the terminal window has always been sent straight to backend_send(), regardless of whether backend_sendok() says it wants it. So the terminal-based implementation of username and password prompts has to work by consuming input data that had _already_ been passed to the backend - hence, any backend that needs to do that must keep its input on a bufchain, and pass that bufchain to seat_get_userpass_input. It's awkward that these two totally different systems coexist in the first place. And now that SSH proxying needs to present interactive prompts of its own, it's clear which one should win: the CLI style is the Right Thing. So this change reworks the GUI side of the mechanism to be more similar: terminal data now goes into a queue in the Ldisc, and is not sent on to the backend until the backend says it's ready for it via backend_sendok(). So terminal-based userpass prompts can now consume data directly from that queue during the connection setup stage. As a result, the 'bufchain *' parameter has vanished from all the userpass_input functions (both the official implementations of the Seat trait method, and term_get_userpass_input() to which some of those implementations delegate). The only function that actually used that bufchain, namely term_get_userpass_input(), now instead reads from the ldisc's input queue via a couple of new Ldisc functions. (Not _trivial_ functions, since input buffered by Ldisc can be a mixture of raw bytes and session specials like SS_EOL! The input queue inside Ldisc is a bufchain containing a fiddly binary encoding that can represent an arbitrary interleaving of those things.) This greatly simplifies the calls to seat_get_userpass_input in backends, which now don't have to mess about with passing their own user_input bufchain around, or toggling their want_user_input flag back and forth to request data to put on to that bufchain. But the flip side is that now there has to be some _other_ method for notifying the terminal when there's more input to be consumed during an interactive prompt, and for notifying the backend when prompt input has finished so that it can proceed to the next stage of the protocol. This is done by a pair of extra callbacks: when more data is put on to Ldisc's input queue, it triggers a call to term_get_userpass_input, and when term_get_userpass_input finishes, it calls a callback function provided in the prompts_t. Therefore, any use of a prompts_t which *might* be asynchronous must fill in the latter callback when setting up the prompts_t. In SSH, the callback is centralised into a common PPL helper function, which reinvokes the same PPL's process_queue coroutine; in rlogin we have to set it up ourselves. I'm sorry for this large and sprawling patch: I tried fairly hard to break it up into individually comprehensible sub-patches, but I just couldn't tease out any part of it that would stand sensibly alone.
2021-09-14 10:57:21 +00:00
{
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
Ldisc *ldisc = container_of(rcv, Ldisc, le_rcv);
backend_send(ldisc->backend, data.ptr, data.len);
Complete rework of terminal userpass input system. The system for handling seat_get_userpass_input has always been structured differently between GUI PuTTY and CLI tools like Plink. In the CLI tools, password input is read directly from the OS terminal/console device by console_get_userpass_input; this means that you need to ensure the same terminal input data _hasn't_ already been consumed by the main event loop and sent on to the backend. This is achieved by the backend_sendok() method, which tells the event loop when the backend has finished issuing password prompts, and hence, when it's safe to start passing standard input to backend_send(). But in the GUI tools, input generated by the terminal window has always been sent straight to backend_send(), regardless of whether backend_sendok() says it wants it. So the terminal-based implementation of username and password prompts has to work by consuming input data that had _already_ been passed to the backend - hence, any backend that needs to do that must keep its input on a bufchain, and pass that bufchain to seat_get_userpass_input. It's awkward that these two totally different systems coexist in the first place. And now that SSH proxying needs to present interactive prompts of its own, it's clear which one should win: the CLI style is the Right Thing. So this change reworks the GUI side of the mechanism to be more similar: terminal data now goes into a queue in the Ldisc, and is not sent on to the backend until the backend says it's ready for it via backend_sendok(). So terminal-based userpass prompts can now consume data directly from that queue during the connection setup stage. As a result, the 'bufchain *' parameter has vanished from all the userpass_input functions (both the official implementations of the Seat trait method, and term_get_userpass_input() to which some of those implementations delegate). The only function that actually used that bufchain, namely term_get_userpass_input(), now instead reads from the ldisc's input queue via a couple of new Ldisc functions. (Not _trivial_ functions, since input buffered by Ldisc can be a mixture of raw bytes and session specials like SS_EOL! The input queue inside Ldisc is a bufchain containing a fiddly binary encoding that can represent an arbitrary interleaving of those things.) This greatly simplifies the calls to seat_get_userpass_input in backends, which now don't have to mess about with passing their own user_input bufchain around, or toggling their want_user_input flag back and forth to request data to put on to that bufchain. But the flip side is that now there has to be some _other_ method for notifying the terminal when there's more input to be consumed during an interactive prompt, and for notifying the backend when prompt input has finished so that it can proceed to the next stage of the protocol. This is done by a pair of extra callbacks: when more data is put on to Ldisc's input queue, it triggers a call to term_get_userpass_input, and when term_get_userpass_input finishes, it calls a callback function provided in the prompts_t. Therefore, any use of a prompts_t which *might* be asynchronous must fill in the latter callback when setting up the prompts_t. In SSH, the callback is centralised into a common PPL helper function, which reinvokes the same PPL's process_queue coroutine; in rlogin we have to set it up ourselves. I'm sorry for this large and sprawling patch: I tried fairly hard to break it up into individually comprehensible sub-patches, but I just couldn't tease out any part of it that would stand sensibly alone.
2021-09-14 10:57:21 +00:00
}
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
static void ldisc_lineedit_special(
TermLineEditorCallbackReceiver *rcv, SessionSpecialCode code, int arg)
Complete rework of terminal userpass input system. The system for handling seat_get_userpass_input has always been structured differently between GUI PuTTY and CLI tools like Plink. In the CLI tools, password input is read directly from the OS terminal/console device by console_get_userpass_input; this means that you need to ensure the same terminal input data _hasn't_ already been consumed by the main event loop and sent on to the backend. This is achieved by the backend_sendok() method, which tells the event loop when the backend has finished issuing password prompts, and hence, when it's safe to start passing standard input to backend_send(). But in the GUI tools, input generated by the terminal window has always been sent straight to backend_send(), regardless of whether backend_sendok() says it wants it. So the terminal-based implementation of username and password prompts has to work by consuming input data that had _already_ been passed to the backend - hence, any backend that needs to do that must keep its input on a bufchain, and pass that bufchain to seat_get_userpass_input. It's awkward that these two totally different systems coexist in the first place. And now that SSH proxying needs to present interactive prompts of its own, it's clear which one should win: the CLI style is the Right Thing. So this change reworks the GUI side of the mechanism to be more similar: terminal data now goes into a queue in the Ldisc, and is not sent on to the backend until the backend says it's ready for it via backend_sendok(). So terminal-based userpass prompts can now consume data directly from that queue during the connection setup stage. As a result, the 'bufchain *' parameter has vanished from all the userpass_input functions (both the official implementations of the Seat trait method, and term_get_userpass_input() to which some of those implementations delegate). The only function that actually used that bufchain, namely term_get_userpass_input(), now instead reads from the ldisc's input queue via a couple of new Ldisc functions. (Not _trivial_ functions, since input buffered by Ldisc can be a mixture of raw bytes and session specials like SS_EOL! The input queue inside Ldisc is a bufchain containing a fiddly binary encoding that can represent an arbitrary interleaving of those things.) This greatly simplifies the calls to seat_get_userpass_input in backends, which now don't have to mess about with passing their own user_input bufchain around, or toggling their want_user_input flag back and forth to request data to put on to that bufchain. But the flip side is that now there has to be some _other_ method for notifying the terminal when there's more input to be consumed during an interactive prompt, and for notifying the backend when prompt input has finished so that it can proceed to the next stage of the protocol. This is done by a pair of extra callbacks: when more data is put on to Ldisc's input queue, it triggers a call to term_get_userpass_input, and when term_get_userpass_input finishes, it calls a callback function provided in the prompts_t. Therefore, any use of a prompts_t which *might* be asynchronous must fill in the latter callback when setting up the prompts_t. In SSH, the callback is centralised into a common PPL helper function, which reinvokes the same PPL's process_queue coroutine; in rlogin we have to set it up ourselves. I'm sorry for this large and sprawling patch: I tried fairly hard to break it up into individually comprehensible sub-patches, but I just couldn't tease out any part of it that would stand sensibly alone.
2021-09-14 10:57:21 +00:00
{
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
Ldisc *ldisc = container_of(rcv, Ldisc, le_rcv);
backend_special(ldisc->backend, code, arg);
Complete rework of terminal userpass input system. The system for handling seat_get_userpass_input has always been structured differently between GUI PuTTY and CLI tools like Plink. In the CLI tools, password input is read directly from the OS terminal/console device by console_get_userpass_input; this means that you need to ensure the same terminal input data _hasn't_ already been consumed by the main event loop and sent on to the backend. This is achieved by the backend_sendok() method, which tells the event loop when the backend has finished issuing password prompts, and hence, when it's safe to start passing standard input to backend_send(). But in the GUI tools, input generated by the terminal window has always been sent straight to backend_send(), regardless of whether backend_sendok() says it wants it. So the terminal-based implementation of username and password prompts has to work by consuming input data that had _already_ been passed to the backend - hence, any backend that needs to do that must keep its input on a bufchain, and pass that bufchain to seat_get_userpass_input. It's awkward that these two totally different systems coexist in the first place. And now that SSH proxying needs to present interactive prompts of its own, it's clear which one should win: the CLI style is the Right Thing. So this change reworks the GUI side of the mechanism to be more similar: terminal data now goes into a queue in the Ldisc, and is not sent on to the backend until the backend says it's ready for it via backend_sendok(). So terminal-based userpass prompts can now consume data directly from that queue during the connection setup stage. As a result, the 'bufchain *' parameter has vanished from all the userpass_input functions (both the official implementations of the Seat trait method, and term_get_userpass_input() to which some of those implementations delegate). The only function that actually used that bufchain, namely term_get_userpass_input(), now instead reads from the ldisc's input queue via a couple of new Ldisc functions. (Not _trivial_ functions, since input buffered by Ldisc can be a mixture of raw bytes and session specials like SS_EOL! The input queue inside Ldisc is a bufchain containing a fiddly binary encoding that can represent an arbitrary interleaving of those things.) This greatly simplifies the calls to seat_get_userpass_input in backends, which now don't have to mess about with passing their own user_input bufchain around, or toggling their want_user_input flag back and forth to request data to put on to that bufchain. But the flip side is that now there has to be some _other_ method for notifying the terminal when there's more input to be consumed during an interactive prompt, and for notifying the backend when prompt input has finished so that it can proceed to the next stage of the protocol. This is done by a pair of extra callbacks: when more data is put on to Ldisc's input queue, it triggers a call to term_get_userpass_input, and when term_get_userpass_input finishes, it calls a callback function provided in the prompts_t. Therefore, any use of a prompts_t which *might* be asynchronous must fill in the latter callback when setting up the prompts_t. In SSH, the callback is centralised into a common PPL helper function, which reinvokes the same PPL's process_queue coroutine; in rlogin we have to set it up ourselves. I'm sorry for this large and sprawling patch: I tried fairly hard to break it up into individually comprehensible sub-patches, but I just couldn't tease out any part of it that would stand sensibly alone.
2021-09-14 10:57:21 +00:00
}
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
static void ldisc_lineedit_newline(TermLineEditorCallbackReceiver *rcv)
Complete rework of terminal userpass input system. The system for handling seat_get_userpass_input has always been structured differently between GUI PuTTY and CLI tools like Plink. In the CLI tools, password input is read directly from the OS terminal/console device by console_get_userpass_input; this means that you need to ensure the same terminal input data _hasn't_ already been consumed by the main event loop and sent on to the backend. This is achieved by the backend_sendok() method, which tells the event loop when the backend has finished issuing password prompts, and hence, when it's safe to start passing standard input to backend_send(). But in the GUI tools, input generated by the terminal window has always been sent straight to backend_send(), regardless of whether backend_sendok() says it wants it. So the terminal-based implementation of username and password prompts has to work by consuming input data that had _already_ been passed to the backend - hence, any backend that needs to do that must keep its input on a bufchain, and pass that bufchain to seat_get_userpass_input. It's awkward that these two totally different systems coexist in the first place. And now that SSH proxying needs to present interactive prompts of its own, it's clear which one should win: the CLI style is the Right Thing. So this change reworks the GUI side of the mechanism to be more similar: terminal data now goes into a queue in the Ldisc, and is not sent on to the backend until the backend says it's ready for it via backend_sendok(). So terminal-based userpass prompts can now consume data directly from that queue during the connection setup stage. As a result, the 'bufchain *' parameter has vanished from all the userpass_input functions (both the official implementations of the Seat trait method, and term_get_userpass_input() to which some of those implementations delegate). The only function that actually used that bufchain, namely term_get_userpass_input(), now instead reads from the ldisc's input queue via a couple of new Ldisc functions. (Not _trivial_ functions, since input buffered by Ldisc can be a mixture of raw bytes and session specials like SS_EOL! The input queue inside Ldisc is a bufchain containing a fiddly binary encoding that can represent an arbitrary interleaving of those things.) This greatly simplifies the calls to seat_get_userpass_input in backends, which now don't have to mess about with passing their own user_input bufchain around, or toggling their want_user_input flag back and forth to request data to put on to that bufchain. But the flip side is that now there has to be some _other_ method for notifying the terminal when there's more input to be consumed during an interactive prompt, and for notifying the backend when prompt input has finished so that it can proceed to the next stage of the protocol. This is done by a pair of extra callbacks: when more data is put on to Ldisc's input queue, it triggers a call to term_get_userpass_input, and when term_get_userpass_input finishes, it calls a callback function provided in the prompts_t. Therefore, any use of a prompts_t which *might* be asynchronous must fill in the latter callback when setting up the prompts_t. In SSH, the callback is centralised into a common PPL helper function, which reinvokes the same PPL's process_queue coroutine; in rlogin we have to set it up ourselves. I'm sorry for this large and sprawling patch: I tried fairly hard to break it up into individually comprehensible sub-patches, but I just couldn't tease out any part of it that would stand sensibly alone.
2021-09-14 10:57:21 +00:00
{
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
Ldisc *ldisc = container_of(rcv, Ldisc, le_rcv);
if (ldisc->protocol == PROT_RAW)
backend_send(ldisc->backend, "\r\n", 2);
else if (ldisc->protocol == PROT_TELNET && ldisc->telnet_newline)
backend_special(ldisc->backend, SS_EOL, 0);
else
backend_send(ldisc->backend, "\r", 1);
Complete rework of terminal userpass input system. The system for handling seat_get_userpass_input has always been structured differently between GUI PuTTY and CLI tools like Plink. In the CLI tools, password input is read directly from the OS terminal/console device by console_get_userpass_input; this means that you need to ensure the same terminal input data _hasn't_ already been consumed by the main event loop and sent on to the backend. This is achieved by the backend_sendok() method, which tells the event loop when the backend has finished issuing password prompts, and hence, when it's safe to start passing standard input to backend_send(). But in the GUI tools, input generated by the terminal window has always been sent straight to backend_send(), regardless of whether backend_sendok() says it wants it. So the terminal-based implementation of username and password prompts has to work by consuming input data that had _already_ been passed to the backend - hence, any backend that needs to do that must keep its input on a bufchain, and pass that bufchain to seat_get_userpass_input. It's awkward that these two totally different systems coexist in the first place. And now that SSH proxying needs to present interactive prompts of its own, it's clear which one should win: the CLI style is the Right Thing. So this change reworks the GUI side of the mechanism to be more similar: terminal data now goes into a queue in the Ldisc, and is not sent on to the backend until the backend says it's ready for it via backend_sendok(). So terminal-based userpass prompts can now consume data directly from that queue during the connection setup stage. As a result, the 'bufchain *' parameter has vanished from all the userpass_input functions (both the official implementations of the Seat trait method, and term_get_userpass_input() to which some of those implementations delegate). The only function that actually used that bufchain, namely term_get_userpass_input(), now instead reads from the ldisc's input queue via a couple of new Ldisc functions. (Not _trivial_ functions, since input buffered by Ldisc can be a mixture of raw bytes and session specials like SS_EOL! The input queue inside Ldisc is a bufchain containing a fiddly binary encoding that can represent an arbitrary interleaving of those things.) This greatly simplifies the calls to seat_get_userpass_input in backends, which now don't have to mess about with passing their own user_input bufchain around, or toggling their want_user_input flag back and forth to request data to put on to that bufchain. But the flip side is that now there has to be some _other_ method for notifying the terminal when there's more input to be consumed during an interactive prompt, and for notifying the backend when prompt input has finished so that it can proceed to the next stage of the protocol. This is done by a pair of extra callbacks: when more data is put on to Ldisc's input queue, it triggers a call to term_get_userpass_input, and when term_get_userpass_input finishes, it calls a callback function provided in the prompts_t. Therefore, any use of a prompts_t which *might* be asynchronous must fill in the latter callback when setting up the prompts_t. In SSH, the callback is centralised into a common PPL helper function, which reinvokes the same PPL's process_queue coroutine; in rlogin we have to set it up ourselves. I'm sorry for this large and sprawling patch: I tried fairly hard to break it up into individually comprehensible sub-patches, but I just couldn't tease out any part of it that would stand sensibly alone.
2021-09-14 10:57:21 +00:00
}
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
static const TermLineEditorCallbackReceiverVtable
ldisc_lineedit_receiver_vt = {
.to_terminal = ldisc_lineedit_to_terminal,
.to_backend = ldisc_lineedit_to_backend,
.special = ldisc_lineedit_special,
.newline = ldisc_lineedit_newline,
};
Backends: notify ldisc when sendok becomes true. (NFC) I've introduced a function ldisc_notify_sendok(), which backends should call on their ldisc (if they have one) when anything changes that might cause backend_sendok() to start returning true. At the moment, the function does nothing. But in future, I'm going to make ldisc start buffering typed-ahead input data not yet sent to the backend, and then the effect of this function will be to trigger flushing all that data into the backend. Backends only have to call this function if sendok was previously false: backends requiring no network connection stage (like pty and serial) can safely return true from sendok, and in that case, they don't also have to immediately call this function.
2021-09-14 09:13:28 +00:00
void ldisc_check_sendok(Ldisc *ldisc)
{
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
queue_idempotent_callback(&ldisc->input_queue_callback);
Backends: notify ldisc when sendok becomes true. (NFC) I've introduced a function ldisc_notify_sendok(), which backends should call on their ldisc (if they have one) when anything changes that might cause backend_sendok() to start returning true. At the moment, the function does nothing. But in future, I'm going to make ldisc start buffering typed-ahead input data not yet sent to the backend, and then the effect of this function will be to trigger flushing all that data into the backend. Backends only have to call this function if sendok was previously false: backends requiring no network connection stage (like pty and serial) can safely return true from sendok, and in that case, they don't also have to immediately call this function.
2021-09-14 09:13:28 +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
void ldisc_send(Ldisc *ldisc, const void *vbuf, int len, bool interactive)
Line discipline module now uses dynamically allocated data. Also fixed one or two other minor problems. [originally from svn r2141]
2002-10-26 10:16:19 +00:00
{
Clarify when ldisc->term may be NULL. Namely, any ldisc that you send actual data through should have a terminal attached, because the ldisc editing/echoing system is designed entirely for use with a terminal. The only time you can have an ldisc with no terminal is when it's only ever used by the backend to report changes to the front end in edit/echo status, e.g. by Unix Plink. Coverity spotted an oddity in ldisc_send which after a while I decided would never have actually caused a problem, but OTOH I agree that it was confusing, so now hopefully it's less so.
2014-11-22 10:37:14 +00:00
assert(ldisc->term);
if (interactive) {
Make calling term_nopaste() a cross-platform feature. It was one of those things that went in ages ago on Windows and never got replicated in the Unix front end. And it needn't be: ldisc.c is a perfect place to put it, since it knows which of the data it's sending is based on a keystroke and which is automatically generated, and it also has access to the terminal context. So now a keypress can interrupt a runaway paste on all platforms. [originally from svn r10025]
2013-08-17 16:06:40 +00:00
/*
* Interrupt a paste from the clipboard, if one was in
* progress when the user pressed a key. This is easier than
* buffering the current piece of data and saving it until the
* terminal has finished pasting, and has the potential side
* benefit of permitting a user to cancel an accidental huge
* paste.
*/
term_nopaste(ldisc->term);
}
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
InputType type;
if (len < 0) {
/*
* Less than zero means null terminated special string.
*/
len = strlen(vbuf);
type = DEDICATED;
} else {
type = interactive ? NORMAL : NONINTERACTIVE;
}
From RDB: a patch to allow special keys (^C, ^Z, Delete, Return) to send Telnet special sequences (Interrupt Process, Suspend, Erase Char, End Of Line) instead of their ASCII equivalents. In particular Return -> Telnet End Of Line is _always_ enabled irrespective of the configuration, while the others are optional. Also in this patch, an entertainingly ghastly use of `switch' to allow literal ^M^J to do the same thing as magic-^M (the Return key) when in Raw protocol. [originally from svn r1109]
2001-05-09 15:12:26 +00:00
/*
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
* Append our data to input_queue, and ensure it's marked with the
* right type.
From RDB: a patch to allow special keys (^C, ^Z, Delete, Return) to send Telnet special sequences (Interrupt Process, Suspend, Erase Char, End Of Line) instead of their ASCII equivalents. In particular Return -> Telnet End Of Line is _always_ enabled irrespective of the configuration, while the others are optional. Also in this patch, an entertainingly ghastly use of `switch' to allow literal ^M^J to do the same thing as magic-^M (the Return key) when in Raw protocol. [originally from svn r1109]
2001-05-09 15:12:26 +00:00
*/
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
bufchain_add(&ldisc->input_queue, vbuf, len);
if (!(ldisc->inchunk_tail && ldisc->inchunk_tail->type == type)) {
struct input_chunk *new_chunk = snew(struct input_chunk);
new_chunk->type = type;
new_chunk->size = 0;
new_chunk->next = NULL;
if (ldisc->inchunk_tail)
ldisc->inchunk_tail->next = new_chunk;
else
ldisc->inchunk_head = new_chunk;
ldisc->inchunk_tail = new_chunk;
From RDB: a patch to allow special keys (^C, ^Z, Delete, Return) to send Telnet special sequences (Interrupt Process, Suspend, Erase Char, End Of Line) instead of their ASCII equivalents. In particular Return -> Telnet End Of Line is _always_ enabled irrespective of the configuration, while the others are optional. Also in this patch, an entertainingly ghastly use of `switch' to allow literal ^M^J to do the same thing as magic-^M (the Return key) when in Raw protocol. [originally from svn r1109]
2001-05-09 15:12:26 +00:00
}
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
ldisc->inchunk_tail->size += len;
Rethink the whole line discipline architecture. Instead of having multiple switchable line disciplines, we now have a single unified one which changes its behaviour based on option settings. Each option setting can be suggested by the back end and/or the terminal handler, and can be forcibly overridden by the configuration. Local echo and local line editing are separate, independently switchable, options. [originally from svn r895]
2001-01-24 14:08:20 +00:00
/*
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
* And process as much of the data immediately as we can.
Rethink the whole line discipline architecture. Instead of having multiple switchable line disciplines, we now have a single unified one which changes its behaviour based on option settings. Each option setting can be suggested by the back end and/or the terminal handler, and can be forcibly overridden by the configuration. Local echo and local line editing are separate, independently switchable, options. [originally from svn r895]
2001-01-24 14:08:20 +00:00
*/
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
ldisc_input_queue_callback(ldisc);
}
static void ldisc_input_queue_callback(void *ctx)
{
Ldisc *ldisc = (Ldisc *)ctx;
/*
* Toplevel callback that is triggered whenever the input queue
* lengthens.
*/
while (bufchain_size(&ldisc->input_queue)) {
ptrlen pl = bufchain_prefix(&ldisc->input_queue);
const char *start = pl.ptr, *buf = pl.ptr;
size_t len = (pl.len < ldisc->inchunk_head->size ?
pl.len : ldisc->inchunk_head->size);
InputType type = ldisc->inchunk_head->type;
while (len > 0 && ldisc->userpass_le) {
char c = *buf++;
len--;
bool dedicated = is_dedicated_byte(c, type);
lineedit_input(ldisc->userpass_le, c, dedicated);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
if (!backend_sendok(ldisc->backend)) {
ldisc_input_queue_consume(ldisc, buf - start);
break;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
/*
* Either perform local editing, or just send characters.
*/
if (EDITING) {
while (len > 0) {
char c = *buf++;
len--;
bool dedicated = is_dedicated_byte(c, type);
lineedit_input(ldisc->le, c, dedicated);
}
ldisc_input_queue_consume(ldisc, buf - start);
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (ECHOING)
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
seat_stdout(ldisc->seat, buf, len);
if (type == DEDICATED && ldisc->protocol == PROT_TELNET) {
while (len > 0) {
char c = *buf++;
len--;
switch (c) {
case CTRL('M'):
if (ldisc->telnet_newline)
backend_special(ldisc->backend, SS_EOL, 0);
else
backend_send(ldisc->backend, "\r", 1);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
break;
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
case CTRL('?'):
case CTRL('H'):
if (ldisc->telnet_keyboard) {
backend_special(ldisc->backend, SS_EC, 0);
break;
}
case CTRL('C'):
if (ldisc->telnet_keyboard) {
backend_special(ldisc->backend, SS_IP, 0);
break;
}
case CTRL('Z'):
if (ldisc->telnet_keyboard) {
backend_special(ldisc->backend, SS_SUSP, 0);
break;
}
default:
backend_send(ldisc->backend, &c, 1);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
break;
}
}
New centralised version of local line editing. This takes over from both the implementation in ldisc.c and the one in term_get_userpass_input, which were imperfectly duplicating each other's functionality. The new version should be more consistent between the two already, and also, it means further improvements can now be made in just one place. In the course of this, I've restructured the inside of ldisc.c by moving the input_queue bufchain to the other side of the translation code in ldisc_send. Previously, ldisc_send received a string, an optional 'dedicated key' indication (bodgily signalled by a negative length) and an 'interactive' flag, translated that somehow into a combination of raw backend output and specials, and saved the latter in input_queue. Now it saves the original (string, dedicated flag, interactive flag) data in input_queue, and doesn't do the translation until the data is pulled back _out_ of the queue. That's because the new line editing system expects to receive something much closer to the original data format. The term_get_userpass_input system is also substantially restructured. Instead of ldisc.c handing each individual keystroke to terminal.c so that it can do line editing on it, terminal.c now just gives the Ldisc a pointer to its instance of the new TermLineEditor object - and then ldisc.c can put keystrokes straight into that, in the same way it would put them into its own TermLineEditor, without having to go via terminal.c at all. So the term_get_userpass_input edifice is only called back when the line editor actually delivers the answer to a username or password prompt. (I considered not _even_ having a separate TermLineEditor for password prompts, and just letting ldisc.c use its own. But the problem is that some of the behaviour differences between the two line editors are deliberate, for example the use of ^D to signal 'abort this prompt', and the use of Escape as an alternative line-clearing command. So TermLineEditor has a flags word that allows ldisc and terminal to set it up differently. Also this lets me give the two TermLineEditors a different vtable of callback functions, which is a convenient way for terminal.c to get notified when a prompt has been answered.) The new line editor still passes all the tests I wrote for the old one. But it already has a couple of important improvements, both in the area of UTF-8 handling: Firstly, when we display a UTF-8 character on the terminal, we check with the terminal how many character cells it occupied, and then if the user deletes it again from the editing buffer, we can emit the right number of backspace-space-backspace sequences. (The old ldisc line editor incorrectly assumed all Unicode characters had terminal with 1, partly because its buffer was byte- rather than character- oriented and so it was more than enough work just finding where the character _start_ was.) Secondly, terminal.c's userpass line editor would never emit a byte in the 80-BF range to the terminal at all, which meant that nontrivial UTF-8 characters always came out as U+FFFD blobs!
2023-03-04 12:56:01 +00:00
ldisc_input_queue_consume(ldisc, buf - start);
} else {
backend_send(ldisc->backend, buf, len);
ldisc_input_queue_consume(ldisc, len);
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
Robert de Bath's patch: ^C ^Z and ^D send Telnet specials in terminal line discipline; also switching disciplines in midsession works better [originally from svn r400]
2000-03-11 14:03:04 +00:00
}
Added local-editing line discipline to make raw backend usable [originally from svn r287]
1999-11-09 12:05:34 +00:00
}
Reference in New Issue Copy Permalink