This makes it a bit more convenient to control when and which
multiplexer(s) you want to connect to.
Now that each domain must have a name in the configuration file,
we can address them more conveniently from the command line.
This is mostly useful for folks on Windows, as you can also run
`wezterm start ssh user@host some command` to run the `ssh` binary in a
local pty and let it manage your ssh session.
On Windows the local pty currently breaks mouse reporting
(see https://github.com/microsoft/terminal/issues/376) so it is
desirable to avoid using a local pty if we're going to talk to a
remote system.
This commit makes it a bit more convenient to establish an ad-hoc ssh
session with a pty on a remote host. This method uses libssh2 under the
covers and thus doesn't support gssapi, which is potentially frustrating
for kerberized environments, but works ok for the majority of users.
There are two issues that I want to resolve in follow up work:
* The TERM has to be sent very early in the channel establishment,
before we "know" the TERM in the `portable-pty` interface. Will need to
figure out how to specify that earlier in an appropriate way.
* Similarly, if no command is specified, we should request the use
of the shell subsystem but we don't have a way to capture this
intend with the cmdbuilder. Will need to solve this too.
This commit adds (untested!) support for remote ttys over ssh.
It requires that the embedding application connect and authenticate
the ssh session prior to turning it into a PtySystem implementation.
They don't always work, so let's just not use them when under wsl.
Since we now know how to detect when we're running under wsl, we
can use that knowledge to bypass permission checking for the unix
domain sockets automatically too.
This helps diagnose problems where stderr is not visible.
Let's also capture them to the `log` stream too, and clarify
toml parsing errors, and fix the underlying problem with
ssh_domains not being allowed to be left unspecified.
I was too focused on the wsl case and didn't test this. We can't
redirect the process handles without causing some problems with
starting up cmd.exe. Comment out that portion of the code for
the moment.
This enables using large OSC buffers in a form that we can publish
to crates.io without blocking on an external crate. Large OSC
buffers are important both for some tunnelling use cases and for
eg: iTerm2 image protocol handling.
