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.

[patrik-simunic-cz]

What seems a bit off to me is namely the discrepancy between what I read in the Ghostty docs and what I see in the source code. I may be (and probably am) a way off, but from what I understand:

• the docs (macOS Login Shells) in essence say that... well, let me quote the very first and second to last sentence to summarize it:
  

  Ghostty respects the macOS traditions and will start each shell as a login shell.
  ...
  Therefore, most shell setup should still go in the .zshrc file so that any shells, terminal or otherwise, are initialized correctly.

• while the comment in source code (src/termio/Exec.zig#L969) states that by using the -l flag couple lines below:

  ...but now the shell isn't a login shell.

---

Anyone Ghostty-knowledgeable, please, correct my observations (regarding Mac):

• When no command option is specified, then Ghostty starts a "non-login" bash shell (without profile/rc), which then *somehow* starts a "login" zsh shell (with profile/rc) and all looks and works as expected
  
  
• When a command option is specified, then Ghostty starts a "non-login" bash shell (without profile/rc), which then directly executes the specified command and hence the command doesn't have access to the profile/rc environment

Now, the issue is, that since the command is executed in an earlier (effectively non-login) shell than is otherwise normally (started) available in the terminal, the command option is much less useful. Because if you want to use the command option, now you have to worry about "manually setting up the environment" before you can do anything.

If we could somehow move the execution of the command "down to the very last ('login') shell", instead of "replacing it" - it seems to me the problem would be solved.
I think there's noting wrong with the chain of shells Ghostty executes on startup to finally get to the login shell, but I think the command is executed in the wrong place (too early in the chain).

[c-wicklein]

I believe that Ghostty, like any macOS application, starts in an environment that does not benefit from the initialization of a login shell; that's just how macOS is. So, Ghostty sensibly starts an interactive shell for the user as a login shell. This means that Ghostty is necessarily on the hook to know how to start the user's login shell. The entirety of the problem here is that when Ghostty has an alternative command to execute, that command is simply passed to /bin/sh -c for evaluation, and I'm suggesting that (1) passing the command to a login instance of the user's shell and (2) passing the command by writing it to that shell's standard input is consistent with what the native terminal application Terminal.app must be doing and solves the originally stated problem of this discussion.

The work-around I suggested is just that, the simplest way I know to implement this behavior for ones self right now and without modifying Ghostty, but I think this behavior should ultimately be incorporated into Ghostty.

NB that what I'm suggesting isn't only a change in order but a change in method, that of passing the alternative command to the user's shell as input rather than on its command line. This reduces the amount of shell-specific knowledge Ghostty requires just to implement the feature of alternative commands to literally zero and cuts out the intermediate instance of /bin/sh, allowing users of a crazy, non-POSIX shell to write alternative commands for their crazy, non-POSIX shell. As what might be a bonus, Ghostty doesn't even need to know when the alternative command fails, because there's no failed instance of /bin/sh involved; once the command has been written to the shell, Ghostty just turns it over to the user for interaction and that's that.

[c-wicklein]

The Expect program I offered as a work-around is very much macOS-oriented in that it determines the user's shell by running dscl.

me@mbp16-chris ~/T/ghostty (main)> dscl . -read /Users/me UserShell
UserShell: /bin/zsh

If I wanted to do the same thing on Linux, I'd probably use getent instead of dscl, assuming Expect doesn't have a better way to get what is the user's shell.

[c-wicklein]

And, it probably doesn't play nice with shell integration. Running my alternative command from a login shell is relatively important to me; shell integration is a level of functionality I'm not used to and don't necessarily notice or miss. I'm content to think of Ghostty as a faster Terminal.app.

[c-wicklein]

@mitchellh ,

I've implemented my suggestion for how to handle the command and initial-command configuration options as entirely separate behaviors with their own parameters, send-command and initial-send-command; not changing how command works has made it easier to experiment without having to repeatedly recompile, so I've tried a few things:

command unset: ZSH runs as -/bin/zsh, no problems.
command = /bin/zsh: ZSH runs as -/bin/zsh, no problems
command = zsh: ZSH runs as -/zsh, still no problems

I'll pause here to mention that as long as Ghostty runs zsh, I expect things to work. I have both ~/.zshrc and ~/.zlogin linked to a unified initialization script that uses a sentinel environment variable to know when it has anything to do. Whether I'm given a login shell or not isn't a big deal.

command = fish: /usr/bin/login -flp me /bin/bash --noprofile --norc -c exec -l fish fails, game over.

This is the failure case which resulted in me noticing this discussion in the first place, and this still seems like a Ghostty problem.

me@Awesome ~> dscl . -read /Users/me | grep UserShell
UserShell: /bin/zsh

Bash is not my shell, so the environment initialization ZSH is responsible for didn't happen. Boo.

Finally, command unset, send-command = fish: -/bin/zsh has run fish and I'm all set.

In this last case, I've modified Surface's initialization to queue sending the send-command string to whatever Surface executes, i.e. to send the command line string fish\r to zsh as regular input, which both fixes my problem and makes any command line parsing concern with command disappear.

[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.

[00-kat]

That would be #2633.