putty-source/stubs/no-console.c

/*
 * Stub functions for when console.c is not linked into a program.
 */

#include "putty.h"

bool console_set_batch_mode(bool newvalue)
{
    return false;
}

bool console_set_stdio_prompts(bool newvalue)
{
    return false;
}
Handle the -batch option centrally in cmdline.c. This removes one case from several of the individual tools' command-line parsers, and moves it into a central place where it will automatically be supported by any tool containing console.c. In order to make that not cause a link failure, there's now a stubs/no-console.c which GUI clients of cmdline.c must include. 2022-11-24 20:00:48 +00:00			`/*`
			`* Stub functions for when console.c is not linked into a program.`
			`*/`

			`#include "putty.h"`

			`bool console_set_batch_mode(bool newvalue)`
			`{`
			`return false;`
			`}`
New system for reading prompts from the console. Until now, the command-line PuTTY tools (PSCP, PSFTP and Plink) have presented all the kinds of interactive prompt (password/passphrase, host key, the assorted weak-crypto warnings, 'append to log file?') on standard error, and read the responses from standard input. This is unfortunate because if you're redirecting their standard input (especially likely with Plink) then the prompt responses will consume some of the intended session data. It would be better to present the prompts _on the console_, even if that's not where stdin or stderr point. On Unix, we've been doing this for ages, by opening /dev/tty directly. On Windows, we didn't, because I didn't know how. But I've recently found out: you can open the magic file names CONIN$ and CONOUT$, which will point at your actual console, if one is available. So now, if it's possible, the command-line tools will do that. But if the attempt to open CONIN$ and CONOUT$ fails, they'll fall back to the old behaviour (in particular, if no console is available at all). In order to make this happen consistently across all the prompt types, I've introduced a new object called ConsoleIO, which holds whatever file handles are necessary, knows whether to close them afterwards (yes if they were obtained by opening CONFOO$, no if they're the standard I/O handles), and presents a BinarySink API to write to them and a custom API to read a line of text. This seems likely to break _someone's_ workflow. So I've added an option '-legacy-stdio-prompts' to restore the old behaviour. 2022-11-24 12:46:25 +00:00
			`bool console_set_stdio_prompts(bool newvalue)`
			`{`
			`return false;`
			`}`