Ghostty doesn't source files like .zshrc when launched from a .command file

[lumap]

When launched from a .command file on macOS (.sh equivalent), Ghostty doesn't source files like .zshrc before executing the command file. This is a bug because the default Terminal app on macOS does so, and this behavior might break some people's files

[mitchellh]

Converted to a discussion to get more details here.

My first question is: do other terminals also do this? I assume so but good to verify.

If they do, I'm curious how they do it. I think some research is required to provide some input on this.

[lumap]

checked with iTerm2, it does load those files. I'm not sure how it does it tho :/

[notjames]

same happens with bash even with the command set to /path/to/bash --login
the only rc file that gets sourced is $HOME/.bashrc

All of my other terminals source $HOME/.bash_profile which in turn sources the rest of the rc files.

[patrik-simunic-cz]

I'm fairly certain Alacritty suffers from the same issue. Some time ago I tried to configure Alacritty to run tmux attach || tmux on startup and it just immediately exited when launched as Alacritty.app, but worked perfectly when launched from an existing terminal.
I guessed that it had not sourced the ~/.zshrc when launched directly - but worked when launched from existing terminal, because it inherited the environment variables from an already initialized shell.

Now the exact same happens with Ghostty - the only difference is that Ghostty is a lot easier to debug since the window helpfully stays open when the command option fails to execute 😆

Unfortunately hardcoding the --noprofile --norc (https://github.com/ghostty-org/ghostty/blob/main/src/termio/Exec.zig#L1000) makes the command option somewhat troublesome.
For instance: the vast majority of online resources speak about adding the export PATH="/opt/homebrew/bin:$PATH" either to .zshrc or .bash_profile files. And since neither of those are sourced by Ghostty, then no brew installed program (such as tmux) is available in Ghostty's command option. There are workarounds, but none without any issues:

1. I can use absolute path (eg. command = "/opt/homebrew/Cellar/tmux/3.5a/bin/tmux")
   
   This locks me into a specific version - when I upgrade, I have to update the Ghostty config. This also goes directly agains the multiplatform nature of Ghostty - ability to share my Ghostty config across different machines (on my Linux machine, tmux is certainly not installed at /opt/homebrew/Cellar/tmux/...).
   
   
2. I can create a script startup.sh and run this script using the command option. In this script then manually source the .zshrc file and only then run tmux attach || tmux.
   
   But manually sourcing the profile/rc files is... well, less than ideal. No to mention that the script needs to be interpreted by something, so the interpreter needs to be hardcoded into this startup script (eg. #!/bin/zsh vs #!/bin/bash). Sourcing .zshrc with bash prints stderr - and the default shell on most Linux distros is not zsh. Hence this startup script is, again, platform specific and difficult to share between Darwin and Linux.

---

@mitchellh Since you seem to have some reason for not sourcing the profile / rc files on startup, I don't actually know of any suggestion about what to with this issue... 😅 But it is in fact at least a headache (if not an issue), since the lack of environment variables (namely extended PATH) greatly decreases the usefulness of the command option. At the very least usefulness "in a multiplatform manner."

[c-wicklein]

Since you seem to have some reason for not sourcing the profile / rc files on startup, I don't actually know of any suggestion about what to with this issue... 😅 But it is in fact at least a headache (if not an issue), since the lack of environment variables (namely extended PATH) greatly decreases the usefulness of the command option. At the very least usefulness _"in a multiplatform manner."

Try instead executing a login shell and writing the command you want to run to the standard input of that shell before interaction begins. This is how I suspect Terminal.app works, and you can effectively implement this outside of Ghostty with expect.. example in my earlier comments further down in this discussion.

[noway]

I ran into the same issue. Repro steps:

1. Have zsh and Oh My Zsh installed

2. Create start.command:

#!/bin/bash
printenv ZSH
echo "^ this is ZSH env variable"
exec $SHELL

3. Run:

open -a /Applications/Ghostty.app ./start.command

4. Run:

open -a /Applications/iTerm.app ./start.command

5. Run:

open -a /System/Applications/Utilities/Terminal.app ./start.command

6. Observe differences:

[thinkyhead]

Temporary workaround for your .command files…

if [[ $TERM_PROGRAM == "ghostty" ]]; then
  if [[ $SHELL =~ "/zsh" ]]; then
    [[ -e ~/.zprofile     ]] && source ~/.zprofile
    [[ -e ~/.zshrc        ]] && source ~/.zshrc
  elif [[ $SHELL =~ "/bash" ]]; then
    [[ -e ~/.bash_profile ]] && source ~/.bash_profile
    [[ -e ~/.bashrc       ]] && source ~/.bashrc
  fi
fi

[thinkyhead]

I'm also seeing a strange related bug. After the .command (or .sh, etc.) exits Ghostty uses 100% CPU while it waits for…

Process exited. Press any key to close the terminal.

Maybe related to #3998 ?

[c-wicklein]

I don't think it make sense to speak of what shell configuration files Ghostty does or does not source given that Ghostty isn't a shell.

By default, Ghostty seems to execute the user's login shell as a login shell, presumably by prepending a - to argv[0]. When Ghostty executes any other command, say as configured with the command directive and presumably when passed a command via open -a, Ghostty seems to execute that command by passing it as an additional argument to /bin/sh -c.

On macOS, Terminal can also be configured to execute an alternative command at start up, but crucially, besides accepting the alternative command, Terminal also has an option as to whether or not that command is "run inside [a] shell." When this option is not selected, Terminal either executes the command directly or perhaps indirectly via /bin/sh -c; I haven't explored which. When this option is selected, Terminal executes the user's login shell as a login shell, uses this instance of $SHELL to execute the alternative command, presumably by writing the command string to the shell's standard input (hence why the command is echoed in the terminal), and then turns the interactive shell over to the user. The alternative command might still be running, or it might have completed. If the alternative command does complete at any point, the user is left to interact with the instance of his login shell.

It would be fantastic if Ghostty had an option for executing an alternative command which worked the same way as "run inside [a] shell" does with Terminal. One nicety of the method Terminal uses is that it's not necessary to know how to pass a command to a shell (although -c does seem to be fairly universal). Another nicety is that if the alternative command "breaks", the user still has a working shell; the terminal doesn't simply close. Finally, and what motivated me to search discussions, is that the method Terminal uses results in the command being evaluated in a "fully initialized shell."

My login shell is /bin/zsh, and my personal environment is completely "configured" by ZSH's initialization scripts. Once I have a "fully-initialized" interactive login instance of ZSH, I generally choose to run fish. With Terminal, I can simply specify an alternative command of fish, check "run inside [a] shell", and I'm all set. With Ghostty, because the alternative command isn't run inside a login shell, I must instead do this...

First, configure Ghostty:

command = /Users/me/bin/ghostty-shell-wrapper.sh fish

Then, provide the command wrapper:

#!/usr/bin/env bash

set -euo pipefail
shopt -s nullglob

SHELL=$(dscl . -read /Users/"$(whoami)" | grep -E '^UserShell:' | awk '{ print $2 }')
exec "$SHELL" -li -c "$1" "$@"

If I don't involve the intermediate login shell, Ghostty won't be able to find fish. The directory /Users/me/macpkg/fish/3.7.1/root/bin is added to PATH as part of ZSH's initialization process via Lmod.

The work-around I'm using isn't quite the same as what Terminal does, but it's good enough for now. A work-around involving expect(1) would allow for replicating the behavior of Terminal by actually writing the alternative command to my login shell.

[c-wicklein]

This expect(1) script functions as an alternative to /Users/me/bin/ghostty-shell-wrapper.sh above and works by starting an interactive login shell (assuming -li has that effect), sends the arguments of the command to the shell as input, then turns the shell over to the user. This more or less replicates the behavior of Terminal with "run inside shell" checked. I would have preferred to set argv[0] to -$SHELL rather than pass -li, but I don't see how to do that with spawn.

#!/usr/bin/env expect

log_user 0

trap {
    set rows [stty rows]
    set cols [stty columns]
    stty rows $rows columns $cols < $spawn_out(slave,name)
} WINCH

set shell [string trim [lindex [split [exec dscl . -read /Users/[exec whoami] UserShell] ":"] 1]]
spawn $shell -li
send "$argv\r"
interact

[c-wicklein]

Perhaps the same idiom could be used to address #2483 ?

[tko]

Could this be a case some env vars are defined in terminal-specifc rc-files which /etc/bashrc and/or /etc/zshrc source conditionally, and there isn't one for ghostty? e.g. I see

[ -r "/etc/bashrc_$TERM_PROGRAM" ] && . "/etc/bashrc_$TERM_PROGRAM"

and

[ -r "/etc/zshrc_$TERM_PROGRAM" ] && . "/etc/zshrc_$TERM_PROGRAM"

(Took me a while to figure nix was configured in /etc/zshrc_iTerm.app and I needed to create /etc/zshrc_ghostty)

[noway]

Unfortunately, I don't think that's the case for me.

I have all the env vars when I open Ghostty normally. I only experience the issue when I drag-and-drop a .command file onto Ghostty or run open -a /Applications/Ghostty.app ./start.command.

[thinkyhead]

Ghostty also fails to handle spaces in paths and filenames when wrapping the launch command for the OPEN Apple Event. If the file you have set Ghostty as the handler for or drop on the Ghostty application is named "Launch Me.command" or "Run Me.sh" then Ghostty will throw an error that there is no file named "Launch" or "Run."

[c-wicklein]

I would start a new discussion for problems related to file names containing spaces.