This is useful (essential!) for fixing up the default auth sock
under gnome, as we do not have a way to do that via whatever
logic may be present in the shell startup files.
This is done with a wezterm twist: not only is the auth sock forwarded,
but the mux on the remote end will automatically maintain a symlink to
point to the auth sock of the most recently active mux client, and set
SSH_AUTH_SOCK to that symlink so that your remote panes should always be
referencing something sane.
refs: https://github.com/wez/wezterm/issues/1647
refs: https://github.com/wez/wezterm/discussions/988
This commit expands the set of data that we track for each client to
include the SSH_AUTH_SOCK. This defaults to the value of that env var on
the machine where the ClientId is constructed, which may be remote from
the mux server.
For the proxy scenario, a remote SSH_AUTH_SOCK path is not addressable,
and what we really want is the local SSH_AUTH_SOCK path from that SSH
session, so we introduce awareness of whether the current session is a
proxy session. Proxy sessions register the mux-local-proxy-id during the
setup of the proxy, but we don't apply the identity to the mux. Instead,
we wait for the remote client to send their identity and that is
annotate to show that it has been routed via a proxy and, crucially, has
the SSH_AUTH_SOCK replaced with the mux-local-proxy-id SSH_AUTH_SOCK.
```
; wezterm cli list-clients
USER HOST PID CONNECTED IDLE WORKSPACE FOCUS SSH_AUTH_SOCK
wez foo 336500 86.944834352s 944.834352ms default 3 /home/wez/.1password/agent.sock
wez foo (via proxy pid 337457) 337314 1.944834352s 944.834352ms 4 /tmp/ssh-XXXXTfGSp7/agent.337456
```
For the SSH_AUTH_SOCK to be populated, ssh agent forwarding also needs
to be enabled for SSH exec() calls; previously it was enabled only for
pty channels.
Since this commit changes the ABI of the mux protocol, the codec
version has been bumped.
This allows individual call sites to be able to force an immediate
resolution of the process information.
This should help to address https://github.com/wez/wezterm/issues/4811
wherein the problem seems to be that the cwd used for a new spawn
is taken from a stale read.
otherwise, the termwiz line reader can become confused and
fail to recognize key presses like `(` which have SHIFT and LEFT_SHIFT
set.
refs: https://github.com/wez/wezterm/issues/3999
Factor out the probe_screen_size method from the Terminal
trait and put it into a ProbeCapabilities struct.
This makes it easier to introduce other sorts of probed
information without making the Terminal trait grow all sorts
of additional methods.
A Terminal may choose not to support probing, which it cannot
if it doesn't have Read + Write handles to an underlying terminal
(such as some special cases in wezterm).
Neither of these understand image protocols, and both are
an additional processing layer between the application and
wezterm.
This commit detects and wraps OSC sequences in tmux's passthru
sequence so that the data is passed on to wezterm rather than
elided from the data stream.
For image protocols in both tmux and conpty, work a little
smarter and explicitly move the cursor position to the same
location that wezterm would move it to. That prevents the
display from being as mangled by tmux/conpty due to a diverging
understanding of the cursor position.
The logic isn't perfect, and can result in the x-coordinate
being incorrect, and this won't work with the new --position
argument either in its current state, without adding a lot
of complexity to deal with scrolling and relative and absolute
positioning handling.
To facilitate that, a new termwiz Terminal trait method has
been added to probe the terminal name, version, cell and pixel
dimensions. It's not pretty.
refs: https://github.com/wez/wezterm/issues/3624
refs: https://github.com/wez/wezterm/issues/3716
ssh connection or host authentication errors would not be displayed
when the config was in its default exit_behavior=Close state.
This commit introduces some plumbing to allow a pane to override
the effective exit_behavior value, so that ssh sessions can now
rewrite it to CloseOnCleanExit while they are in the process
of connecting.
refs: #3941
I believe that this was obsoleted long ago by the ThreadedWriter
logic that is present in the terminal implementation so we no
longer need to limit the write chunk size.
refs: #3683
If the client program is drip feeding us input at a rate faster than 1
character per mux_output_parser_coalesce_delay_ms (e.g. it is printing
output read from a serial port faster than this), we would previously
wait indefinitely for new input, because we would always poll with a new
timeout [...]delay_ms in the future. In the worst case, this would create
a busy loop that starves the other panes of an opportunity to read from
their ptys, making all of them unresponsive. Address this by making a
note of when the first character was read, and do not wait longer than
[...]delay_ms after this time.
Fixes#3466.
https://github.com/wez/wezterm/discussions/3480#discussioncomment-5567569
mentioned that running `wezterm cli spawn --domain-name SSH:foo`,
closing that tab and running `wezterm cli spawn --domain-name SSH:foo`
again failed.
The error message had no useful context.
This commit adds more context.
The stack trace in https://github.com/wez/wezterm/issues/3425
shows a recursive borrow triggered indirectly by spawning
a subprocess and having that trigger the wndproc.
This commit doesn't really fix the recursive problem, but may
sidestep it, and it's probably best to avoid always running
the `wsl` command to get this list anyway, similar to the
change in 25255d90d6
refs: https://github.com/wez/wezterm/issues/3425
If the target domain_id doesn't match the source pane.domain_id(),
then we consider the filesystem namespace to be incompatible and
won't try to use it.
refs: https://github.com/wez/wezterm/issues/3442
This commit teaches the config about SerialDomains, and the mux
layer about constructing a SerialDomain, then changes the GUI
layer to use those pieces to set up `wezterm serial`.
A new `serial_ports` config is added, and the GUI layer knows how
to apply it to the set of domains in the mux.
The result of this is that you can now define a domain for each
serial port and spawn a serial connection into a new tab or window
in your running wezterm gui instance.
