simon-git: putty (main): Simon Tatham

Commits to Tartarus hosted VCS tartarus-commits at lists.tartarus.org
Thu Sep 26 11:54:18 BST 2024


TL;DR:
  964890f1 Stringify all the CONF_foo identifiers, for debugging.
  ed621590 Some int -> size_t cleanup in terminal.c API.
  c4c4d2c5 dup_mb_to_wc, dup_wc_to_mb: remove the 'flags' parameter.
  32b8da11 clipme(): remove some obsolete diagnostic code.
  4f756d2a Rework Unicode conversion APIs to use a BinarySink.
  75b6e12f Add two new string types to the Conf system.
  55d413a4 Add UTF-8 versions of dlg_editbox_{get,set}.
  dc4ac7c4 conf_editbox_handler: support the new string types.
  7980722f Document the split_into_argv functions better.
  841bf321 New abstraction for command-line arguments.
  b57fb48b Change type of CONF_username to the new CONF_TYPE_STR_AMBI.
  74150633 Add and use cmdline_arg_to_filename().
  ecfa6b27 Don't print long usage messages on a command-line error.
  11d1f377 Don't exit(1) after printing PGP key fingerprints.
  7d9d72ba Fix double line-wrapping in the -pgpfp message box.
  f8095548 Switch CONF_remote_cmd to being STR_AMBI.

Repository:     https://git.tartarus.org/simon/putty.git
On the web:     https://git.tartarus.org/?p=simon/putty.git
Branch updated: main
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2024-09-26 11:54:18

commit 964890f1a18064d2bfc816a5157f64068a20c388
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=964890f1a18064d2bfc816a5157f64068a20c388;hp=31ab5b8e3083d66fdfd9a243029c8bfc1a7a4b40
Author: Simon Tatham <anakin at pobox.com>
Date:   Mon Sep 23 15:12:18 2024 +0100

    Stringify all the CONF_foo identifiers, for debugging.
    
    When dumping out the contents of a Conf, it's useful not to have to
    guess what the integer indices mean.
    
    By putting these identifiers in a separate array in its own library
    module, I should avoid them getting linked in to production binaries
    to take up space, as long as conf_id() is only called from inside
    debug() statements. And to enforce _that_, it isn't even declared in a
    header file unless you #define DEBUG.

 misc.h               |  5 +++++
 utils/CMakeLists.txt |  1 +
 utils/conf_debug.c   | 15 +++++++++++++++
 3 files changed, 21 insertions(+)

commit ed621590b0aca54a9b5762a7228e103b23055df5
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=ed621590b0aca54a9b5762a7228e103b23055df5;hp=964890f1a18064d2bfc816a5157f64068a20c388
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Sep 24 09:37:36 2024 +0100

    Some int -> size_t cleanup in terminal.c API.
    
    term_do_paste and term_input_data_from_* were still taking int, which
    should be size_t. Not that I expect those functions to get >2^31 bytes
    of input in one go, but I noticed it while about to modify the same
    functions for another reason.

 putty.h             |  2 +-
 terminal/terminal.c | 13 +++++++------
 terminal/terminal.h |  2 +-
 3 files changed, 9 insertions(+), 8 deletions(-)

commit c4c4d2c5cb62c87e6741542f0148fe0a08527820
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=c4c4d2c5cb62c87e6741542f0148fe0a08527820;hp=ed621590b0aca54a9b5762a7228e103b23055df5
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Sep 24 08:46:39 2024 +0100

    dup_mb_to_wc, dup_wc_to_mb: remove the 'flags' parameter.
    
    This parameter was undocumented, and Windows-specific: its semantics
    date from before PuTTY was cross-platform, and are "Pass this flags
    parameter straight through to the Win32 API's conversion functions".
    So in Windows platform code you can pass flags like MB_USEGLYPHCHARS,
    but in cross-platform code, you dare not pass anything nonzero at all
    because the Unix frontend won't recognise it (or, likely, even
    compile).
    
    I've kept the flag for now in the underlying mb_to_wc / wc_to_mb
    functions. Partly that's because there's one place in the Windows code
    where the parameter _is_ used; mostly, it's because I'm about to
    replace those functions anyway, so there's no point in editing all the
    call sites twice.

 misc.h                      |  8 ++++----
 unix/window.c               |  4 ++--
 utils/dup_mb_to_wc.c        |  8 ++++----
 utils/dup_wc_to_mb.c        |  9 ++++-----
 windows/console.c           |  4 ++--
 windows/controls.c          |  2 +-
 windows/gss.c               |  2 +-
 windows/utils/filename.c    |  8 ++++----
 windows/utils/message_box.c |  4 ++--
 windows/window.c            | 14 +++++++-------
 10 files changed, 31 insertions(+), 32 deletions(-)

commit 32b8da1177162206e0d491fd978473231ffff199
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=32b8da1177162206e0d491fd978473231ffff199;hp=c4c4d2c5cb62c87e6741542f0148fe0a08527820
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Sep 24 08:32:16 2024 +0100

    clipme(): remove some obsolete diagnostic code.
    
    This #if completely replaced the actually useful version of clipme(),
    so I think it must have been used early in development before the
    useful version was even written.
    
    Since then it's bit-rotted to the point where it doesn't even make
    sense: the "#endif" is nested inside a while loop that the "#if 0" and
    "#else" are outside, so that if the condition were changed to evaluate
    true, you'd get syntactic nonsense out of the preprocessor.
    
    And I can't see any use for it now, even if it did compile! Get rid of
    it.

 terminal/terminal.c | 5 -----
 1 file changed, 5 deletions(-)

commit 4f756d2a4db767866af254a5bb733dcb89c27c88
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=4f756d2a4db767866af254a5bb733dcb89c27c88;hp=32b8da1177162206e0d491fd978473231ffff199
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Sep 24 08:18:48 2024 +0100

    Rework Unicode conversion APIs to use a BinarySink.
    
    The previous mb_to_wc and wc_to_mb had horrible and also buggy APIs.
    This commit introduces a fresh pair of functions to replace them,
    which generate output by writing to a BinarySink. So it's now up to
    the caller to decide whether it wants the output written to a
    fixed-size buffer with overflow checking (via buffer_sink), or
    dynamically allocated, or even written directly to some other output
    channel.
    
    Nothing uses the new functions yet. I plan to migrate things over in
    upcoming commits.
    
    What was wrong with the old APIs: they had that awkward undocumented
    Windows-specific 'flags' parameter that I described in the previous
    commit and took out of the dup_X_to_Y wrappers. But much worse, the
    semantics for buffer overflow were not just undocumented but actually
    inconsistent. dup_wc_to_mb() in utils assumed that the underlying
    wc_to_mb would fill the buffer nearly full and return the size of data
    it wrote. In fact, this was untrue in the case where wc_to_mb called
    WideCharToMultiByte: that returns straight-up failure, setting the
    Windows error code to ERROR_INSUFFICIENT_BUFFER. It _does_ partially
    fill the output buffer, but doesn't tell you how much it wrote!
    
    What's wrong with the new API: it's a bit awkward to write a sequence
    of wchar_t in native byte order to a byte-oriented BinarySink, so
    people using put_mb_to_wc directly have to do some annoying pointer
    casting. But I think that's less horrible than the previous APIs.
    
    Another change: in the new API for wc_to_mb, defchr can be "", but not
    NULL.

 marshal.h            |  12 +++
 putty.h              |   5 +-
 terminal/terminal.c  |  39 ++++-----
 unix/unicode.c       |  92 +++++++++++++---------
 unix/unifont.c       |  28 +++----
 unix/window.c        |  43 +++++-----
 utils/dup_mb_to_wc.c |  24 +++---
 utils/dup_wc_to_mb.c |  25 ++----
 windows/console.c    |  16 ++--
 windows/unicode.c    | 218 ++++++++++++++++++++++++++++++---------------------
 10 files changed, 265 insertions(+), 237 deletions(-)

commit 75b6e12f8461b806b2e913aa18ec44c372761942
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=75b6e12f8461b806b2e913aa18ec44c372761942;hp=4f756d2a4db767866af254a5bb733dcb89c27c88
Author: Simon Tatham <anakin at pobox.com>
Date:   Mon Sep 23 12:00:37 2024 +0100

    Add two new string types to the Conf system.
    
    This begins the process of making PuTTY more able to handle Unicode
    strings as a first-class type in its configuration. One of the new
    types, CONF_TYPE_UTF8, looks physically just like CONF_TYPE_STR but
    the semantics are that it's definitely encoded in UTF-8, instead of
    'shrug, whatever the system locale's encoding is'.
    
    Unfortunately, we can't yet switch over any Conf items to having that
    type, because our data representations in saved configuration (both on
    Unix and Windows) store char strings in the system encoding. So we'll
    have to change that representation at the same time, which risks
    breaking backwards compatibility with old PuTTYs reading the same
    configuration.
    
    So the other new type, CONF_TYPE_STR_AMBI, is intended as a
    transitional form, recording a configuration setting that _might_ be
    explicitly UTF-8 or might have the legacy 'shrug, whatever' semantics,
    depending on where we got it from.
    
    My general migration plan is that first I _enable_ Unicode support in
    a Conf item, by turning it into STR_AMBI; the Unicode version of the
    string (if any) is saved in a new location, and a best-effort
    local-charset version is saved where it's always been. That way new
    PuTTY can read the Unicode version, and old PuTTY reading that
    configuration will behave no worse than it would have done already.
    
    It would be nice to think that in the far future we've migrated
    everything to STR_AMBI and can move them all to mandatory UTF-8,
    obsoleting the old configuration. I think it's more likely we'll never
    get there. But at least _new_ Conf items, with no backwards
    compatibility requirement in the first place, can be CONF_TYPE_UTF8
    where appropriate.
    
    (In conf_get_str_ambi(), I considered making it mandatory via assert()
    to pass the 'utf8' output pointer as non-NULL, to defend against lazy
    adaptation of existing code by just changing the function call. But in
    fact I think there's a legitimate use case for not caring if the
    output is UTF-8 or not, because some of the existing SSH code
    currently just shoves strings like usernames directly on to the wire
    whether they're in the right encoding or not; so if you want to do the
    correct UTF-8 thing where possible and preserve legacy behaviour if
    not, then treating both classes of string the same _is_ the right
    thing to do.)
    
    This also requires linking the Unicode support into many Unix
    applications that hadn't previously needed it.

 CMakeLists.txt      |   9 ++++
 putty.h             |  60 +++++++++++++++++++++++--
 settings.c          |  38 ++++++++++++++++
 test/test_conf.c    | 116 ++++++++++++++++++++++++++++++++++++++++++++++++-
 unix/CMakeLists.txt |  24 +++++-----
 utils/conf.c        | 123 +++++++++++++++++++++++++++++++++++++++++++++-------
 6 files changed, 339 insertions(+), 31 deletions(-)

commit 55d413a47ad75bf5eef104b57bd9fd069c9391ed
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=55d413a47ad75bf5eef104b57bd9fd069c9391ed;hp=75b6e12f8461b806b2e913aa18ec44c372761942
Author: Simon Tatham <anakin at pobox.com>
Date:   Mon Sep 23 14:20:44 2024 +0100

    Add UTF-8 versions of dlg_editbox_{get,set}.
    
    There's no difficulty with implementing these, on either platform.
    Windows has native Unicode support for its edit boxes: we can set and
    retrieve the text as a wide-character string, and then converting it
    to and from UTF-8 is easy. And GTK has specified its edit boxes as
    being UTF-8 all along, no matter what the system locale.

 dialog.h           |  2 ++
 unix/dialog.c      | 18 ++++++++++++++++--
 windows/controls.c | 19 +++++++++++++++++++
 3 files changed, 37 insertions(+), 2 deletions(-)

commit dc4ac7c4e1bd6cba781f7940b308e5f0b92d9ca0
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=dc4ac7c4e1bd6cba781f7940b308e5f0b92d9ca0;hp=55d413a47ad75bf5eef104b57bd9fd069c9391ed
Author: Simon Tatham <anakin at pobox.com>
Date:   Mon Sep 23 16:55:44 2024 +0100

    conf_editbox_handler: support the new string types.
    
    Now you can use an ordinary edit box in the config setup to talk to a
    string-valued Conf setting typed as any of CONF_TYPE_STR,
    CONF_TYPE_UTF8 or CONF_TYPE_STR_AMBI.

 config.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

commit 7980722f55eef151618a7c3d43a3b2718520faf9
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=7980722f55eef151618a7c3d43a3b2718520faf9;hp=dc4ac7c4e1bd6cba781f7940b308e5f0b92d9ca0
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu Sep 26 10:23:50 2024 +0100

    Document the split_into_argv functions better.
    
    Even though I wrote them, I keep forgetting their semantics. In
    particular I can never quite remember off the top of my head whether
    they modify their input command line, or allocate it fresh. To make
    that clearer, I've made it a const parameter.
    
    (That means the output argstart pointers have the same awkward const
    -> mutable conversion as strchr - but then, strchr is itself precedent
    for that being the usual way to not-quite-handle that annoyance in C!)

 windows/platform.h              | 39 +++++++++++++++++++++++++++++++++++++--
 windows/utils/split_into_argv.c |  6 +++---
 2 files changed, 40 insertions(+), 5 deletions(-)

commit 841bf321d419d8549936d01633579d68908db112
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=841bf321d419d8549936d01633579d68908db112;hp=7980722f55eef151618a7c3d43a3b2718520faf9
Author: Simon Tatham <anakin at pobox.com>
Date:   Wed Sep 25 10:18:38 2024 +0100

    New abstraction for command-line arguments.
    
    This begins the process of enabling our Windows applications to handle
    Unicode characters on their command lines which don't fit in the
    system code page.
    
    Instead of passing plain strings to cmdline_process_param, we now pass
    a partially opaque and platform-specific thing called a CmdlineArg.
    This has a method that extracts the argument word as a default-encoded
    string, and another one that tries to extract it as UTF-8 (though it
    may fail if the UTF-8 isn't available).
    
    On Windows, the command line is now constructed by calling
    split_into_argv_w on the Unicode command line returned by
    GetCommandLineW(), and the UTF-8 method returns text converted
    directly from that wide-character form, not going via the system code
    page. So it _can_ include UTF-8 characters that wouldn't have
    round-tripped via CP_ACP.
    
    This commit introduces the abstraction and switches over the
    cross-platform and Windows argv-handling code to use it, with minimal
    functional change. Nothing yet tries to call cmdline_arg_get_utf8().
    
    I say 'cross-platform and Windows' because on the Unix side there's
    still a lot of use of plain old argv which I haven't converted. That
    would be a much larger project, and isn't currently needed: the
    _current_ aim of this abstraction is to get the right things to happen
    relating to Unicode on Windows, so for code that doesn't run on
    Windows anyway, it's not adding value. (Also there's a tension with
    GTK, which wants to talk to standard argv and extract arguments _it_
    knows about, so at the very least we'd have to let it munge argv
    before importing it into this new system.)

 cmdline.c                      |  37 ++++----
 defs.h                         |   2 +
 pscp.c                         | 139 +++++++++++++++------------
 psftp.c                        |  62 ++++++------
 psftp.h                        |   2 +-
 psocks.c                       |  35 +++----
 psocks.h                       |   5 +-
 putty.h                        |  34 +++++--
 unix/CMakeLists.txt            |   1 +
 unix/main-gtk-simple.c         |  34 +++----
 unix/platform.h                |   4 +
 unix/plink.c                   |  22 +++--
 unix/psocks.c                  |  33 +++----
 unix/sftp.c                    |   3 +-
 unix/utils/cmdline_arg.c       | 158 +++++++++++++++++++++++++++++++
 windows/CMakeLists.txt         |   1 +
 windows/pageant.c              |  30 +++---
 windows/platform.h             |  19 ++--
 windows/plink.c                |  20 ++--
 windows/psocks.c               |   4 +-
 windows/pterm.c                |  35 +++----
 windows/putty.c                |  34 +++----
 windows/puttygen.c             |  31 +++---
 windows/sftp.c                 |   3 +-
 windows/test/test_screenshot.c |  11 ++-
 windows/utils/aux_match_opt.c  |  39 ++++----
 windows/utils/cmdline_arg.c    | 209 +++++++++++++++++++++++++++++++++++++++++
 27 files changed, 724 insertions(+), 283 deletions(-)

commit b57fb48b274bdb5bea806d8aa4a08e7d4121e20d
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=b57fb48b274bdb5bea806d8aa4a08e7d4121e20d;hp=841bf321d419d8549936d01633579d68908db112
Author: Simon Tatham <anakin at pobox.com>
Date:   Mon Sep 23 16:59:11 2024 +0100

    Change type of CONF_username to the new CONF_TYPE_STR_AMBI.
    
    This is the pathfinding change that proves it's possible for _one_
    Conf setting to become Unicode-capable.
    
    That seems like quite a small reward for all the refactoring in the
    previous patches this week! But changing over one configuration
    setting is enough to get started with: once all the bugs are out of
    this one, we can try switching over some more.
    
    Changing the type to CONF_TYPE_STR_AMBI is enough by itself to make
    the configuration dialog box write it into Conf as UTF-8, because
    conf_editbox_handler automatically checks whether that possibility is
    available. However, setting the same Conf entry from the command line
    isn't automatic: I had to add code in the handler for the -l
    command-line option in cmdline.c.
    
    This commit also doesn't yet handle the _other_ way to specify a
    username on the command line: including it as part of the hostname
    argument via "putty user at host" or similar. That's more difficult,
    because it also requires deciding what to do about UTF-8 in the actual
    hostname.
    
    (That looks as if it ought to be possible: Windows should be able to
    handle looking up Unicode hostnames if you use GetAddrInfoW() in place
    of getaddrinfo(). But plumbing it through everything in between
    cmdline.c and windows/network.c is a bigger job than I'm prepared to
    do in this proof-of-concept commit.)

 cmdline.c        | 6 +++++-
 conf.h           | 2 +-
 pscp.c           | 2 +-
 settings.c       | 4 +++-
 test/test_conf.c | 2 +-
 unix/plink.c     | 2 +-
 6 files changed, 12 insertions(+), 6 deletions(-)

commit 74150633f199321d095601b25532a138e2334e12
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=74150633f199321d095601b25532a138e2334e12;hp=b57fb48b274bdb5bea806d8aa4a08e7d4121e20d
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Sep 24 17:50:19 2024 +0100

    Add and use cmdline_arg_to_filename().
    
    Converting a CmdlineArg straight to a Filename allows us to make the
    filename out of the wide-character version of the string on Windows.
    So now filenames specified on the command line should generally be
    able to handle pathnames containing Unicode characters not in the
    system code page.
    
    This change also involves making some char pointers _into_ Filename
    structs where they weren't previously: for example, the
    'openssh_config_file' variable in Windows Pageant's WinMain().

 cmdline.c                      | 25 ++++++++++++-------------
 putty.h                        |  1 +
 unix/main-gtk-simple.c         |  3 +--
 unix/utils/cmdline_arg.c       |  9 +++++++++
 windows/dialog.c               |  2 +-
 windows/pageant.c              | 18 +++++++++++-------
 windows/platform.h             |  2 +-
 windows/putty.c                |  8 ++++----
 windows/puttygen.c             | 12 +++++-------
 windows/test/test_screenshot.c |  5 +++--
 windows/utils/cmdline_arg.c    |  9 +++++++++
 windows/utils/screenshot.c     |  8 ++++----
 12 files changed, 61 insertions(+), 41 deletions(-)

commit ecfa6b273408d11ab0499ed9ee05605e9c210c05
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=ecfa6b273408d11ab0499ed9ee05605e9c210c05;hp=74150633f199321d095601b25532a138e2334e12
Author: Simon Tatham <anakin at pobox.com>
Date:   Wed Sep 25 16:17:07 2024 +0100

    Don't print long usage messages on a command-line error.
    
    In the course of debugging the command-line argument refactoring in
    previous commits, I found I wasn't quite sure whether PSCP thought I'd
    given it too many arguments, or too few, because it didn't print an
    error message saying which: it just printed its giant usage message.
    
    Over the last few years I've come to the belief that this is Just
    Wrong anyway. Printing the whole of a giant help message should only
    be done when the user asked for it: otherwise, print a short and
    to-the-point error, and maybe _suggest_ how to get help, but scrolling
    everything else off the user's screen is not a good response to a
    typo. I wrote this thought up more fully last year:
    
    https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/stop-helping/
    
    So, time to practise what I preach! The PuTTY tools now follow the
    'Stop helping!' principle. You can get full help by saying --help.
    
    Also, when we do print the help, we now exit(0) rather than exit(1),
    because there's no reason to report failure: we successfully did what
    the user asked us for.

 cmdgen.c        | 5 +++--
 pscp.c          | 6 +++---
 psftp.c         | 4 ++--
 unix/pageant.c  | 1 -
 unix/plink.c    | 6 ++++--
 windows/plink.c | 7 +++++--
 6 files changed, 17 insertions(+), 12 deletions(-)

commit 11d1f3776b2ae2a090c95095200c1c8f0bb01a8f
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=11d1f3776b2ae2a090c95095200c1c8f0bb01a8f;hp=ecfa6b273408d11ab0499ed9ee05605e9c210c05
Author: Simon Tatham <anakin at pobox.com>
Date:   Wed Sep 25 16:26:17 2024 +0100

    Don't exit(1) after printing PGP key fingerprints.
    
    That's not a failure outcome. The user asked for some information; we
    printed it; nothing went wrong. Mission successful, so exit(0)!
    
    I noticed this because it was sitting right next to some of the
    usage() calls modified in the previous commit. Those also had the
    misfeature of exiting with failure after successfully printing the
    help, possibly due to confusion arising from the way that usage() was
    _sometimes_ printed on error as well. But pgp_fingerprints() has no
    such excuse. That one's just silly.

 pscp.c                 | 2 +-
 psftp.c                | 2 +-
 unix/main-gtk-simple.c | 2 +-
 unix/plink.c           | 2 +-
 windows/pageant.c      | 2 +-
 windows/plink.c        | 2 +-
 windows/putty.c        | 2 +-
 windows/puttygen.c     | 2 +-
 8 files changed, 8 insertions(+), 8 deletions(-)

commit 7d9d72ba153338e15c033577e0a3026ab2b726fb
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=7d9d72ba153338e15c033577e0a3026ab2b726fb;hp=11d1f3776b2ae2a090c95095200c1c8f0bb01a8f
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu Sep 26 09:41:26 2024 +0100

    Fix double line-wrapping in the -pgpfp message box.
    
    While testing the new command-line handling, I tried actually using
    that option for the first time in a long time, and saw
    
       These are the fingerprints of the PuTTY PGP Master Keys. They
       can
       be used to establish a trust path from this executable to another
       one. See the manual for more information.
    
    because Windows MessageBox() had done its own wrapping on the text, at
    a slightly narrower width than the one implied by the hard newlines in
    the input string. Removed the mid-paragraph newlines, so that
    Windows's wrapping will be the only wrapping.

 windows/utils/pgp_fingerprints_msgbox.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

commit f80955488acdd3deccfc55dbff23124dd20318af
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=f80955488acdd3deccfc55dbff23124dd20318af;hp=7d9d72ba153338e15c033577e0a3026ab2b726fb
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu Sep 26 10:50:47 2024 +0100

    Switch CONF_remote_cmd to being STR_AMBI.
    
    The immediate usefulness of this is in pterm.exe: when the user uses
    -e to specify a command to run in the pterm, we retrieve the command
    in Unicode, store it in CONF_remote_cmd as UTF-8, and then in conpty.c
    we can extract it in the same form and convert it back to Unicode to
    pass losslessly to CreateProcessW. So now non-ACP Unicode works in
    that part of the pterm command line.

 conf.h           |  4 ++--
 ssh/mainchan.c   | 10 +++++++---
 test/test_conf.c |  2 +-
 unix/plink.c     |  4 ++--
 windows/conpty.c | 25 +++++++++++++++----------
 windows/plink.c  |  4 ++--
 windows/pterm.c  |  4 ++--
 7 files changed, 31 insertions(+), 22 deletions(-)



More information about the tartarus-commits mailing list