When one develops Ghostty while using Ghostty it could lead to an
interesting conundrum: the freshly built Ghostty would use the parent
Ghostty's resources, which would be stale and not reflect any new
changes to resources. This is especially bad for translators, since
their translations would not be reflected in the newly built Ghostty
if they happen to run it under older Ghostty, which is not only
counterintuitive and also painful in terms of workflow.
Now, on debug builds we always try to use the terminfo detection method
first in order to locate the zig-out/share/ghostty folder, and only fall
back to GHOSTTY_RESOURCES_DIR if the executable is for some reason no
longer in zig-out. You can test this behavior by manually moving the
Ghostty executable out of zig-out, and then launching it with and without
Ghostty.
Installing resources directly under ${prefix}/share causes conflicts
with other packages. This will become more problematic whenever Ghostty
is opened and becomes packaged in distributions.
Instead, install all resources under a "ghostty" subdirectory (i.e.
${prefix}/share/ghostty). This includes themes, shell integration, and
terminfo files.
Only "/usr/share" style paths use the "ghostty" subdirectory. On macOS,
Ghostty is already isolated within its app bundle, and if
$GHOSTTY_RESOURCES_DIR is set then we assume that points to the actual
resources dir (without needing to append "ghostty" to it).
Changes:
- Add WindowsPty, which uses the ConPTY API to create a pseudo console
- Pty now selects between PosixPty and WindowsPty
- Windows support in Command, including the ability to launch a process with a pseudo console
- Enable Command tests on windows
- Add some environment variable abstractions to handle the missing libc APIs on Windows
- Windows version of ReadThread
