'--posix' starts bash in POSIX mode (like /bin/sh). This is rarely used
for interactive shells, and removing automatic shell integration support
for this option allows us to simply/remove some exceptional code paths.
Users are still able to manually source the shell integration script.
Also fix an issue where we would still inject GHOSTTY_BASH_RCFILE if we
aborted the automatic shell integration path _after_ seeing an --rcfile
or --init-file argument.
Bash shell detection was originally disabled in #1823 due to problems
with /bin/bash on macOS.
Apple distributes their own patched version of Bash 3.2 on macOS that
disables the POSIX-style $ENV-based startup path:
e5397a7e74/bash-3.2/shell.c (L1112-L1114)
This means we're unable to perform our automatic shell integration
sequence in this specific environment. Standard Bash 3.2 works fine.
Knowing this, we can re-enable bash shell detection by default unless
we're running "/bin/bash" on Darwin. We can safely assume that's the
unsupported Bash executable because /bin is non-writable on modern macOS
installations due to System Integrity Protection.
macOS users can either manually source our shell integration script
(which otherwise works fine with Apple's Bash) or install a standard
version of Bash from Homebrew or elsewhere.
For now, bash integration must be explicitly enabled (by setting
`shell-integration = bash`). Our automatic shell integration requires
bash version 4 or later, and systems like macOS continue to ship bash
version 3 by default. This approach avoids the cost of performing a
runtime version check.
Fish automatic integration taken as an example.
Just like fish, Elvish checks `XDG_DATA_DIRS` for its modules.
Thus, Fish integration in zig is reused, and integration in
Elvish now removes `GHOSTTY_FISH_XDG_DIR` environment variable
on launch.
When the -c option is present, then commands are read from the first
non-option argument command string. Our simple implementation assumes
that if we see at least the '-c' option, a command string was given, and
the shell is always considered to be non-interactive - even if the '-i'
(interactive) option is also given.
bash reads HISTFILE at startup to locate its history file, but this is
apparently too early for it to be able to expand home-relative paths. We
now manually expand the full path and add that to the environment.
This change adds automatic bash shell detection and integration.
Unlike our other shell integrations, bash doesn't provide a built-in
mechanism for injecting our ghostty.bash script into the new shell
environment.
Instead, we start bash in POSIX mode and use the ENV environment
variable to load our integration script, and the rest of the bash
startup sequence becomes the responsibility of our script to emulate
(along with disabling POSIX mode).
When a shell is forced, we would supply its /-prefixed executable name
to mimic a path location. The rest of the integration detection logic
assumes just a base executable name. Fix the forced names accordingly.
Also add a unit test for this "force shell" behavior.
This adds a new option to the shell integration feature set, `no-title`.
If this option is set, the shell integration will not automatically
update the window title.
