Go directly to the underlying env_logger crate, as pretty_env_logger
hasn't been updated in some time, and I'd like to be able to redirect
the log output to a file more directly, and that feature is in a newer
version of the env logger than pretty_env_logger was pulling in.
It looks like the debian 9 test failures with libssh are the
same underlying issue as https://github.com/wez/wezterm/issues/1262
Poking around in the debug output, and then spelunking through the code,
we can use the `pubkeyacceptedtypes` ssh config option to add the key
type to the list of keys. This doesn't appear to be a documented
option in the current versions of openssh.
I'm not 100% sure that this is right, but it's worth a shot.
A recent cargo update caused openssl-sys to do a minor semver update
from 0.9.71 -> 0.9.72, but that release downgraded from openssl 3
to openssl 1 to resolve a performance regression:
<https://github.com/sfackler/rust-openssl/pull/1578>
That in turn caused libssh to fail to build because the ENGINE
feature required by libssh isn't compiled in in openssl-src 1
crate when vendoring on windows.
For now, my libssh git repo is constrained to openssl-sys 0.9.71,
and we're pointing to that from the wezterm repo.
In the mux layer, we have some code that takes a `Child` and then
does a bit of naughty reaching through the abstraction to get at
the pid/handle of the child so that we can send it signals even
if the child is itself mutably (and thus exclusively) borrowed
for the purposes of waiting.
That worked fine for local processes spawned in the mux, but we also
use LocalPane to wrap around arbitrary `Child`ren, such as Ssh,
that are not local and that don't have a local process id, which
meant that this hack wouldn't work for them.
To make things a bit worse, those ssh ptys were used to ssh2 days
where we didn't have a way to signal the remote process and just
did nothing, leading to confusing situations such as
https://github.com/wez/wezterm/issues/1197
This commit graduates the hack mentioned in the first paragraph
to its own ChildKiller trait. This makes the concept of waiting
for the Child distinct from signalling it and explicitly allows
getting a separate object that can be used for signalling.
With that in place, we're forced to implement something appropriate
for the ssh pty implementations; one in the pty crate itself,
one in wezterm-ssh and the wrapper that we use in the mux crate.
The upshot of this is that the `CloseCurrentPane` action now operates
correctly on panes that were the result of split operations.
This is a fairly far-reaching commit. The idea is:
* Introduce a unicode_version config that specifies the default level
of unicode conformance for each newly created Terminal (each Pane)
* The unicode_version is passed down to the `grapheme_column_width`
function which interprets the width based on the version
* `Cell` records the width so that later calculations don't need to
know the unicode version
In a subsequent diff, I will introduce an escape sequence that allows
setting/pushing/popping the unicode version so that it can be overridden
via eg: a shell alias prior to launching an application that uses a
different version of unicode from the default.
This approach allows output from multiple applications with differing
understanding of unicode to coexist on the same screen a little more
sanely.
Note that the default `unicode_version` is set to 9, which means that
emoji presentation selectors are now by-default ignored. This was
selected to better match the level of support in widely deployed
applications.
I expect to raise that default version in the future.
Also worth noting: there are a number of callers of
`unicode_column_width` in things like overlays and lua helper functions
that pass `None` for the unicode version: these will assume the latest
known-to-wezterm/termwiz version of unicode to be desired. If those
overlays do things with emoji presentation selectors, then there may be
some alignment artifacts. That can be tackled in a follow up commit.
refs: #1231
refs: #997
This works, but on macOS, there is a segfault in openssl when the
session is closed... I'm going to try this on Linux to see if it
is consistent behavior and ponder next steps.
Adding an edge from wezterm-ssh -> async_ossl causes the
openssl vendoring feature selection logic to trigger, which
in turn allows `cargo build -p window --examples` to succeed
again on macos.
Since removing the regular periodic background tasks, we're now
prone to not noticing child processes exiting.
This commit explicictly schedules a thread to do that on Windows
so that we can close a tab as soon as it exits.
There are a few notable changes as a result:
* A number of `.ssh/config` options are now respected; host matching
and aliasing and identity file are the main things
* The authentication prompt is inline in the window, rather than
popping up a separate authentication window
Refs: https://github.com/wez/wezterm/issues/457
I can't get this to succeed though; I suspect there may be a lingering
bug from libssh2 and/or trailing support for newer openssh features.
refs: https://github.com/wez/wezterm/issues/457
