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
I noticed that wezterm is picking up garbage from gnome too,
so let's trigger the random fd closing function on all unix
systems.
It turns out that iterating the entries in /dev/fd works on
BSD and Linux which is nice.
Needed to re-order a couple of things to match recent changes.
Also: don't hard fail if the ssh server rejects a setenv request,
just log the error instead.
Seems that you need to have read everything you want before you
call waitpid, otherwise the pending data seems to be snipped and
prevented from being read.
closes: https://github.com/wez/wezterm/issues/187
Since the last release we've migrated from failure -> anyhow,
added more functions to the command builder, improved windows
support and have compatibility with the `smol` crate.
refs: https://github.com/wez/wezterm/issues/166
This commit allows loading the console functions from `conpty.dll`
instead of `kernel32.dll` which means that we can update and
track newer features than have been deployed to Windows.
In practical terms this means that we can now unlock mouse input
reporting in eg: VIM running under WSL.
refs: https://github.com/microsoft/terminal/issues/376
We're jumping the gun on this issue, which is tracking making
a proper supportable way to deploy this sort of update:
refs: https://github.com/microsoft/terminal/issues/1130
For now it seems easier just for us to bundle our own copy of
these bits.
This includes a speculative change to include those in our
Windows downloads also.
The binaries were built from
4f8acb4b9f
