This commit allows wezterm to spawn programs into the host rather
than in the container environment.
It feels weird that it is so trivial to "break out" of the container
sandbox, but I'm not complaining.
There are some unfortunate consequences:
* there is no `wezterm` installed on the host, so no ability to `wezterm
cli` to control it from other apps
* The unix domain socket is scoped inside the sandbox, so there's "no
way" for `wezterm cli` to reach inside anyway.
But: with this, it is at least usable to start a flatpak and open a
shell.
refs: https://github.com/wez/wezterm/issues/2229
An ExecDomain is a variation on WslDomain with the key difference
being that you can control how to map the command that would be
executed.
The idea is that the user can define eg: a domain for a docker
container, or a domain that chooses to run every command in its
own cgroup.
The example below shows a really crappy implementation as a
demonstration:
```
local wezterm = require 'wezterm'
return {
exec_domains = {
-- Commands executed in the woot domain have "WOOT" echoed
-- first and are then run via bash.
-- `cmd` is a SpawnCommand
wezterm.exec_domain("woot", function(cmd)
if cmd.args then
cmd.args = {
"bash",
"-c",
"echo WOOT && " .. wezterm.shell_join_args(cmd.args)
}
end
-- you must return the SpawnCommand that will be run
return cmd
end),
},
default_domain = "woot",
}
```
This commit unfortunately does more than should go into a single
commit, but I'm a bit too lazy to wrangle splitting it up.
* Reverts the nil/null stuff from #2177 and makes the
`ExtendSelectionToMouseCursor` parameter mandatory to dodge
a whole load of urgh around nil in table values. That is
necessary because SpawnCommand uses optional fields and the
userdata proxy was making that a PITA.
* Adds some shell quoting helper functions
* Adds ExecDomain itself, which is really just a way to
to run a callback to fixup the command that will be run.
That command is converted to a SpawnCommand for the callback
to process in lua and return an adjusted version of it,
then converted back to a command builder for execution.
refs: https://github.com/wez/wezterm/issues/1776
I think I'd like to make a config option for this, but for the moment,
this first pass unconditionally updates the base environment with
data from the registry.
refs: https://github.com/wez/wezterm/issues/1848
The serial port is always in non-blocking mode so we need to use our
own timeout and `poll(2)`.
While we're in here, the `wait` method could cause the gui to exit
immediately on startup because we'd interpret its immediate error
return result as child process completion.
This commit makes the wait method look at the carrier detect signal
and propagates IO errors back as completion events.
refs: https://github.com/wez/wezterm/issues/1594
The idea is that we want to be able to spawn into wsl with the
convenience of a local domain, but without the awkwardness of
it having a different filesystem namespace.
It would also be great to be able to spawn a new tab or pane
in the same domain and pick up the cwd of the existing one.
The WslDomain allows the user to explicitly list WslDomains
and control eg: default shell, username and so on, but wezterm
will pre-fill a default list of domains based on the `wsl -l`
output that we were already using in the launcher menu.
The existing LocalDomain has been augmented to understand that
it may need to fixup a command invocation and that gives it
the opportunity to rewrite the command so that we can launch
it via `wsl.exe` and pass down the cwd and so on.
This same technique might be extensible to eg: docker instances
in the future.
This commit:
* Introduces `wsl_domains` config and its default list of wsl
distributions
* Creates LocalDomain instances from that list
* The launcher menu allows spawning a new tab via one of those domains
ConPTY emits a sequence that sets the title to the name of the
program that is initially launched into it.
This commit tries to ignore that sequence in that circumstance,
so that the logic in b5d156c282
can more dynamically set the tab title.
For some reason, winapi's HANDLE type isn't compatible with the core
rust ffi HANDLE type when cross compiling.
This commit adds some casts.
```
cd pty
cargo build --release --target x86_64-pc-windows-msvc
```
refs: #1389
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 got lost somewhere along the way.
Importantly, we need to explicitly set the pty to use invalid stdio
handles for the spawned child in order to avoid a weird situation
where eg: cmd or powershell would end up writing to the log file
despite it being spawned into its own PTY.
refs: #1358
Without this check, something, presumably in the guts of rust itself,
generates `fatal runtime error: assertion failed:
output.write(&bytes).is_ok()` on the output stream of the spawned child
when attempting to spawn `wsl.exe` on linux.
refs: #1005
Looking at #900; the unconditional directory change on startup
is "bad" because it only happens on Windows.
This commit removes it and instead puts the logic into the pty
layer to match the unix behavior.
The behavior is:
* If the command specifies the cwd, use that.
* Otherwise, use the home directory
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.
Since the original code was written, Rust grew and stabilized
an interface for specifying argv0 for the child process, so
we can remove the fragile `-l` argument passing.
refs: https://github.com/wez/wezterm/issues/753
This commit first delivers SIGHUP, then follows up with a regular
kill after a grace period. This should allow processes an opportunity
to clean up when eg: the terminal window is closed.
Co-authored-by: Wez Furlong <wez@wezfurlong.org>
closes: #490
* Add Sync marker to child process created through pty spawn
* Add 'Sync' to Windows build of pty
* Wrap proc in WinChild in a Mutex
* Make sure the Mutex is not locked for long by cloning
* Add config option to specify default current working directory
* Make `cwd` of CLI take precedence over `default_cwd`
* Update docs for `default_cwd` and Launching Programs
Explains the `default_cwd` property more succinctly on the `Config` struct.
Adds documentation on the various ways to set the working directory and the logic used to decide the working directory.
wezterm sets a more restrictive umask (`0o077`) by default so that any files
that it creates (eg: unix domain socket, log files) are more secure
by default.
However, some environments rely on the more general default of (`0o022`)
without checking that it is set.
This matters because programs spawned by wezterm inherit its more
restricted umask.
I hadn't noticed this because I've had `umask 022` in my shell RC files
since sometime in the 1990's.
This commit adds some plumbing to the pty layer to specify an optional
umask for the child process, and some more to our umask saver helper
so that any thread can determine the saved umask without needing a
reference to the saver itself, which may be in a different crate.
The logic in the config crate has been adjusted to connect the saved
value to the default command builder arguments.
The net result of this is that running `wezterm -n start bash -- --norc`
and typing `umask` in the resultant window now prints `0022`.
refs: #416
