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 enables users to override the normal invocation completely,
which is helpful for example when connecting into a gui from
a remote host.
I was wondering why prefer-mux was in here, and my commit message
from 7afc9e4d56 suggests that I
hit an issue where the gui wasn't running and where I didn't care
because I wanted to hit the mux.
I think that makes it a little awkward to blanket remove the
--prefer-mux flag, but for those that don't want it, they should now
be able to configure to allow connected to the gui
```
ssh_domains = {
{
name = "shortname",
remote_address = "hostname",
override_proxy_command = "wezterm cli proxy",
},
},
```
This resolves an issue where `WEZTERM_UNIX_SOCKET=something wezterm cli
proxy` would use `something` for the unix domain path when checking that
an existing instance was up and running, but would then use the default
implicit socket path when dropping into the proxy passthrough stage.
What we do here is transform the connected client into its configuration
and use that instead of trying to re-derive the socket from incomplete
information.
The motivating example is using SSH to get into a workstation that
is running a GUI wezterm with no explicit unix domain mux.
When using an exec domain as a default_mux_server_domain, you currently
witness the following behavior:
- Newly started mux-servers create a pane in the exec domain.
- Splitting an existing pane will create the new pane in the exec
domain.
- Calling [wezterm cli spawn] will create a new tab or window in the
exec domain.
- Creating a new tab from the Gui does *not* run in the exec domain.
This appears to be due to the fact that ClientDomain hardcodes an
assumption that the default domain_id of the remote mux-server is 0.
Instead of having ClientDomain issue a SpawnV2 RPC explicitly asking for
domain_id 0, simply use DefaultDomain.
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.
double-tapping the window title could lead to a cycle between
client and server.
The cycle is broken here by having the client defer advising
the server of a title change, and sending the now-current
title rather than the title embedded in the notification
from the mux layer.
refs: #1598
refs: #522
In debug builds I noticed that sometimes we'd fail to connect
to a newly spawned unix server.
Increase the timeout to give it a chance to start up before
we error out.
The server-side ownership of the palette is a stumbling block for
many users, so let's fix it.
This commit allows the client to pass its configured palette to
the server when it connects, and when the config is changed.
That palette takes precedence over the palette from the server config.
However, if the remote application uses any escape sequences that
redefine the color palette, the color palette that was active at
that point in time is forked and use as the basis, and will remain
the active palette until the palette is reset via escape sequences.
refs: https://github.com/wez/wezterm/issues/2686
refs: https://github.com/wez/wezterm/issues/3397
Work harder to notice and handle the PaneRemoved notification
more centrally, which allows removing some earlier workarounds.
Now when we receive PaneRemoved, we take the opportunity to handle
missing mapping or stale mapping between local and remote ids and
perform a resync before continuing to handle the PaneRemoved message.
Doing it this way means that we don't need to second guess the timing
of notification or the resync, so we end up with the correct sequence
of notifications, and the result is the correct size of the splits
because the local and remote aren't independently managing the
the pane removal with conflicting ideas of the new size.
refs: https://github.com/wez/wezterm/issues/3386
Three issues:
* The initial connect would leave the dpi assigned to 0, resulting
in incorrect scaling when using imgcat until the window was resized
and the correct dpi was passed up.
* On resize, we'd only compare the row/col count and not notice changes
in pixel dimensions/dpi
* On the server side, when processing a resize and recomputing
the tab size, we would omit the pixel dimensions and leave
the resulting tabs and panes with 0 dimensions, breaking imgcat
because it thought the window was 0x0.
refs: https://github.com/wez/wezterm/issues/3366
This commit causes the mux to generate a PaneFocused notification
when the active pane is changed.
The mux server will forward that as a unilateral PDU to connected
clients.
The clientpane implementation will handle that by applying the
same state to the local mux.
refs: #2863
* Translate from File to EncodedFile as needed
* Adopt blob leases in the mux server
* Fix an issue where the first image sent by the mux server would
be replaced on the client by its background image, if configured.
Removed the ImageData::id field to resolve this: you should use
the hash field instead to identify and disambiguate images.
Bumped the termwiz API version because this is conceptually
a breaking change to the API
refs: https://github.com/wez/wezterm/issues/3343
- Removes closures and function calls for types that implement default:
```rust
// Change
let _my_str = get_str().unwrap_or(String::new);
// To
let _my_str = get_str().unwrap_or_default();
```
- Uses the `.cloned()/.copied()` methods where possible
- Use function pointer instead of simple closure
May improve performace, as closures generate more code, and this might
unlock some inlining opportunities.
Threads through a GuiPosition from mux window creation to allow it to be
used when the corresponding gui window is created.
SpawnCommand now has an optional position field to use for that purpose.
```lua
wezterm.mux.spawn_window {
position = {
x = 10,
y = 300,
-- Optional origin to use for x and y.
-- Possible values:
-- * "ScreenCoordinateSystem" (this is the default)
-- * "MainScreen" (the primary or main screen)
-- * "ActiveScreen" (whichever screen hosts the active/focused window)
-- * {Named="HDMI-1"} - uses a screen by name. See wezterm.gui.screens()
-- origin = "ScreenCoordinateSystem"
},
}
```
refs: https://github.com/wez/wezterm/issues/2976
This allows removing a bunch of unwrap/expect calls.
However, my primary motive was to replace the cases where we used
Mux::get() == None to indicate that we were not on the main thread.
A separate API has been added to test for that explicitly rather than
implicitly.
We weren't matching the domain id when resolving the remote->local pane
mapping, which meant that having 2 or more mux client domains active
would lead to associating eg: remote pane id 1 with whichever local
pane was associated with any remote pane id 1 *first*.
This commit requires that both the domain id and the remote pane id
match.
refs: https://github.com/wez/wezterm/issues/2616
