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
That version has the ability to use SSH agent forwarding.
This commit doesn't enable that functionality, it's just updating
the version and adjusting for changes in the upstream.
This is useful for setting up a reasonable initial environment.
For example, on Windows you might want to set the `prompt` environment
so that some basic shell integration is enabled; this will cause new
tabs to open with the same cwd as the current tab:
```
set_environment_variables = { "prompt"="$E]7;file://localhost/$P$E\\$P$G" }
```
This setting is intended to apply only to the local domain.
refs: https://github.com/wez/wezterm/issues/146
This allows this prompt setting to work:
```
prompt $E]7;file://localhost/$P$E\$P$G
```
although this one sets it for future prompts:
```
setx prompt $E]7;file://localhost/$P$E\$P$G
```
refs: https://github.com/wez/wezterm/issues/146
At some recent point in history, I effective broke multiple tabs in
`wezterm ssh HOST` by allowing them to contend in weird ways on locks,
leading to a horribly sluggish experience where multiple keypresses
in alternate tabs would appear to be swallowed until IO happened in
another tab. Yuk!
This commit fixes that up by teaching channels how to wait cooperatively
and to attempt a read in all waiting channels when the fd becomes
readable.
It's too fiddly to setup in practice, and literally no one has
expressed an interest in using it.
Removing it simplifies some upcoming work.
Closes: https://github.com/wez/wezterm/issues/35
Tested only on windows with a USB serial connector to my NUC running
linux.
This allows opening up wezterm on a serial port connection.
Serial is closer to a tty than a pty, so it is a bit different
to configure and use.
This commit allows running:
```
wezterm serial COM3
```
to open a window that connects to the specified COM port.
You can change the baud rate with:
```
wezterm serial --baud 9600 COM3
```
There are more options that could be set, but I'm a bit lazy and
have only exposed the baud rate to the wezterm cli so far.
Previously we had the logic for this in wezterm itself; it would know
how to figure out which shell to run, or whether we should run a
different program by default (the `default_prog` setting).
This was OK, but when I added support for ssh we hit a conceptual
issue: the local side of the ssh session doesn't have any information
about the shell that should be invoked on the remote side and instead
needs to ask the remote to figure that out. The interfaces defined
in the code didn't allow for this.
This commit formalizes the concept of a default program and allows
it to be carried through to the pty layer, including over ssh sessions.
Since we now have enough smarts to figure out the local shell and the
local home dir, I've removed the logic that run `login -pf` on macos
by default; this should make the terminal startup very slightly faster
on macos, but since I'm currently on a windows system, I can only test
linux and windows on this side of this commit. I'll follow up on macos
later.
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.
