mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-01-09 17:38:00 +00:00
80aed96286
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. |
||
|---|---|---|
| .. | ||
| CMakeLists.txt | ||
| no-ca-config.c | ||
| no-cmdline.c | ||
| no-console.c | ||
| no-gss.c | ||
| no-print.c | ||
| no-rand.c | ||
| no-term.c | ||
| no-timing.c | ||
| null-cipher.c | ||
| null-key.c | ||
| null-lp.c | ||
| null-mac.c | ||
| null-opener.c | ||
| null-plug.c | ||
| null-seat.c | ||