1
0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00

Docs: -legacy-charset-handling also applies to PuTTY.

(As of commit f9943e2ffd.)
This commit is contained in:
Jacob Nevins 2024-11-23 13:17:12 +00:00
parent d5d5eefa5f
commit 628a9486af

View File

@ -1185,11 +1185,10 @@ box for host certification authorities, as described in
\k{config-ssh-kex-cert}. When you dismiss that dialog box, PuTTY will \k{config-ssh-kex-cert}. When you dismiss that dialog box, PuTTY will
terminate. terminate.
\S2{using-cmdline-legacy-console} \i{\c{-legacy-stdio-prompts}}, \S2{using-cmdline-legacy-stdio-prompts} \i{\c{-legacy-stdio-prompts}}:
\i{\c{-legacy-charset-handling}}: handle Windows console prompts like handle Windows console prompts like older versions of PuTTY
older versions of PuTTY
These options apply to all of PSCP, PSFTP and Plink on Windows: all This option applies to all of PSCP, PSFTP and Plink on Windows: all
the tools in the PuTTY suite that run in a Windows console and make the tools in the PuTTY suite that run in a Windows console and make
SSH connections. SSH connections.
@ -1204,12 +1203,13 @@ responses will be read from the console (and not from where you've
redirected your input). redirected your input).
Another advantage of reading directly from the Windows console is that Another advantage of reading directly from the Windows console is that
the tools can read input as Unicode. So this also allows you to enter the tools can read input as \i{Unicode}. So this also allows you to
usernames and passwords that contain characters not in the Windows enter usernames and passwords that contain characters not in the
system's default character set. Windows system's default character set.
In older versions of PuTTY, the prompts used the tool's ordinary I/O In versions of the PuTTY tools up to and including 0.81, the prompts
handles, so prompt output and user responses could be redirected. used the tool's ordinary I/O handles, so prompt output and user
responses could be redirected.
We think the new behaviour is more likely to be useful. For example, We think the new behaviour is more likely to be useful. For example,
if you have a local command that generates output, and you want to if you have a local command that generates output, and you want to
@ -1225,16 +1225,47 @@ more awkward.
However, we recognise that people may have customised complicated However, we recognise that people may have customised complicated
workflows around the old behaviour. So if you need to switch back to workflows around the old behaviour. So if you need to switch back to
it, there are two options to switch some or all of the behaviour back it, you can do so by specifying \c{-legacy-stdio-prompts} on the
to the old way: command-line.
\c{-legacy-charset-handling} makes the tools read prompt responses in To fully revert to the previous behaviour, you'd also need to specify
the system's default character set instead of Unicode. If the new \c{-legacy-charset-handling} (see the next section). (Even without
Unicode-based input causes a username or password not to work as you that option, prompt handling with \c{-legacy-stdio-prompts} may not be
expected, and it worked in earlier versions of PuTTY, you can use this fully Unicode-clean.)
option to switch back to doing it the old way.
\c{-legacy-stdio-prompts} makes the tools use the redirectable I/O \S2{using-cmdline-legacy-charset-handling} \i{\c{-legacy-charset-handling}}:
channels for prompts, instead of talking directly to the console. So handle character set in prompts like older versions of PuTTY
if you were relying on being able to redirect prompt input and output,
you can use this option. This option applies to PuTTY (on all platforms), and also to all of
PSCP, PSFTP and Plink on Windows.
In current versions of PuTTY, when you are prompted in the terminal
window for things like SSH usernames and passwords, the responses you
type are interpreted as \i{Unicode}, and transmitted to the server as
such, even if the terminal is otherwise configured to use a different
character encoding (see \k{config-charset}). Similarly, the same
prompts from the Windows console tools will unconditionally interpret
their input as Unicode.
This behaviour is in line with the SSH standards; it allows things
like usernames to use the full character set of the user's native
language, and ensures that different keystrokes you type for your
password are actually treated distinctly.
However, if you are used to the behaviour of the PuTTY tools up to
version 0.81, this could cause a previously working username and/or
password not to work as you expected. For instance, if you had set a
password including some \i{accented characters}, this change in
behaviour could cause the same keystrokes you've always entered to
start sending a different sequence of bytes to the server, denying you
access (and you wouldn't even be able to see the difference, since the
password is not shown when you type it).
\c{-legacy-charset-handling} reverts the PuTTY tools' behaviour to how
it was previously: what you type at these prompts will be interpreted
according to the \q{Remote character set} (for PuTTY) or Windows'
default character set (for the Windows console tools).
(For example, this could allow you to log in to change your password
to make using this option unnecessary in future. But if you're doing
that, make sure the terminal is configured as UTF-8!)