This builder is an efficient way to construct space-separated shell
command strings.
We use it in setupBash to avoid using an intermediate array of arguments
to construct our bash command line.
This makes `libghostty-vt` build for freestanding wasm targets (aka a
browser) and produce a `ghostty-vt.wasm` file. This exports the same C
API that libghostty-vt does.
This commit specifically makes the changes necessary for the build to
build properly and for us to run the build in CI. We don't yet actually
try using it...
Fixes a crash when NSLocale returns nil for languageCode or countryCode
properties. This can happen when the app launches without locale
environment variables set.
The crash occurs at `src/os/locale.zig:87-88` when trying to call
`getProperty()` on a nil object. The fix adds a null check and falls
back to `en_US.UTF-8` instead of dereferencing null.
## Testing
Tested by running with locale variables unset:
```bash
unset LC_ALL && ./zig-out/Ghostty.app/Contents/MacOS/ghostty
```
Before: segmentation fault
After: launches successfully with fallback locale
std.net.isValidHostname is currently too generous. It considers strings
like ".example.com", "exa..mple.com", and "-example.com" to be valid
hostnames, which is incorrect according to RFC 1123 (the currently
accepted standard).
Until the standard library function is improved, we can use this local
implementation that does follow the RFC 1123 standard.
I asked Claude to perform an audit of the code based on its understand
of the RFC. It suggested some additional test cases and considers the
overall implementation to be robust (its words) and standards compliant.
Ref: https://www.rfc-editor.org/rfc/rfc1123
This reimplements the MAC address-aware URI parsing logic used by the
OSC 7 handler and adds an additional .raw_path option that returns the
full, unencoded path string (including query and fragment values), which
is needed for compliant kitty-shell-cwd:// handling.
Notably, this implementation takes an options-based approach that allows
these additional behaviors to be enabled at runtime. It also leverages
two std.Uri.parse guarantees:
1. Return slices point into the original text string.
2. .raw components don't require unescaping (.percent_encoded does).
The implementation is in a new 'os.uri' module because its now generic
enough to not be hostname-oriented.
We use os.uri.parseUri and its parsing options to reimplement our OSC 7
file-style URI handling. This has two advantages:
First, it fixes kitty-shell-cwd scheme handling. This scheme expects the
full, unencoded path string, whereas the file scheme expects normal URI
percent encoding. This was preventing paths containing "special" URI
characters (like "path?") from working correctly in our bash, zsh, and
elvish shell integrations, which report working directories using the
kitty-shell-cwd scheme. (fish uses file URIs, which work as expected.)
Second, we can greatly simplify our hostname and path string handling
because we can now rely on the "raw" std.Uri component form to always
provide the correct representation.
Lastly, this lets us remove the previous URI-related code from the
os.hostname module, restoring its focus to hostname-related functions.
See: #5289
This fix was found by Claude Code, but I manually reviewed this change
and removed extraneous changes made by the AI tool.
Co-authored-by: moderation <michael@sooper.org>
## Description of changes
Added Hungarian locale files, and corresponding translation
For the translation I mainly relied on my native skills, double checked
my work using LLMs.
Copilot generated summary:
This pull request introduces Hungarian language support to the
application by adding translations and updating the locale
configurations. The most important changes include the addition of
Hungarian translations in the `.po` file and registering the new locale
in the application's supported locales.
### Hungarian Language Support:
* Added Hungarian translations for various UI elements and messages in
the `po/hu_HU.UTF-8.po` file. This includes translations for prompts,
dialogs, menus, and other interface components.
* Updated the supported locales list in `src/os/i18n.zig` to include
`hu_HU.UTF-8`, enabling Hungarian as an available language option.
## Picture(s) of the translation
GNU gettext simply is a PITA on certain platforms (i.e. Windows, musl
Linux, etc.) and currently it's not possible to cleanly remove i18n
from the build process, making building Ghostty on the aforementioned
platforms difficult. By providing users with a way to opt-out of the
i18n mechanisms (or opt-in, on platforms where i18n is disabled by
default) we can make sure that people at least have *some* way of
building Ghostty before i18n mechanisms can be integrated neatly.
Partial implementation of #5256
This implements the core changes necessary to open urls using an apprt
action rather than doing it directly from the core.
Implements the open_url action in the GTK and GLFW apprts.
Note that this should not be merged until a macOS-savvy developer can add
an implementation of the open_url action for the macOS apprt.
This makes it so `zig build run` can take arguments such as
`--config-default-files=false` or any other configuration. Previously,
it only accepted commands such as `+version`.
Incidentally, this also makes it so that the app in general can now take
configuration arguments via the CLI if it is launched as a new instance
via `open`. For example:
open -n Ghostty.app --args --config-default-files=false
This previously didn't work. This is kind of cool.
To make this work, the libghostty C API was modified so that
initialization requires the CLI args, and there is a new C API to try to
execute an action if it was set.
This PR introduces support for Irish (Gaeilge), the first official
language of Ireland and an EU working language.
The translation file was initialized using the standard gettext tooling:
` msginit -i po/com.mitchellh.ghostty.pot -l $LANG -o "po/$LANG.po"`
The locale code `ga_IE` follows ISO standards for Gaeilge as spoken in
Ireland.
I'm happy to volunteer as the ongoing maintainer of the Irish
translation and will keep it up to date as Ghostty evolves.
Go raibh maith agat!
Without waiting on the xdg-open process on linux/freebsd, we end up with
a defunct (zombie) process after each time we open a URL.
For example, after click on two URLs in a ghostty, here is the output of
`ps ux | grep xdg-open`:
```
pbui 8364 0.0 0.0 0 0 tty7 Z+ 05:03 0:00 [xdg-open] <defunct>
pbui 8453 0.0 0.0 0 0 tty7 Z+ 05:03 0:00 [xdg-open] <defunct>
```
Perhaps we should revisit 695bc30, which removed the wait in the first
place. On my machine running Alpine Linux 3.22, `xdg-open` does not stay
alive and finishes immediately, thus making it safe to call wait (and
not block). This is also the case on my other machine running Ubuntu
24.04: `xdg-open` launches the URL in a browser and terminates
immediately.
Either way, this process must be waited upon eventually. Otherwise, we
will accumulate a collection of defunct processes until the terminal
itself terminates.
