fork doesn't honor PATH setting

[bill-torpey]

Because we care about file timestamps, we use a post-checkout hook that invokes git-restore-mtime (https://github.com/MestreLion/git-tools). To simplify things, I add the script directory to my PATH in .bash_profile, but fork doesn't honor that setting.

[DanPristupov]

To simplify things, I add the script directory to my PATH in .bash_profile, but fork doesn't honor that setting.

Then you must start Fork from bash, otherwise it won't receive that PATH (open -a Fork) https://github.com/ForkIssues/Tracker/issues/430#issuecomment-429013890

[bill-torpey]

PATH is also set in .bashrc, but fork still can't find things. Using a script to start fork is not great -- I already do that with SourceTree, which is one of the reasons I'm looking at fork.

[DanPristupov]

PATH is also set in .bashrc, but fork still can't find things.

Fork doesn't read settings of some other applications. Same as other application don't read Fork settings.

In unix ENV is inherited from the parent process.

[bill-torpey]

Fork doesn't read settings of some other applications. Same as other application don't read Fork settings.

Not the application, the OS. Applications are expected to take settings from the OS.

In unix ENV is inherited from the parent process.

Well, this is on Mac, so kinda unix, but not exactly. Not sure how fork umm, forks, but at least on Linux there are options to preserve parent environment or not. fork may have good reasons to not preserve the parent process' environment, but if so it would be very helpful to have a setting in fork itself to add directories to PATH/(DY)LD_LIBRARY_PATH.

[Andrew-Au]

PATH is also set in .bashrc

Is the issue that you're setting the path in .bashrc, not .profile (or equivalent)? The Finder session is not an interactive shell, so it will not source .bashrc when the session starts.

Fork is spawned by the Finder, so it also has no reason to run .bashrc.

Note: I think I'm mis-using the term Finder here, but the meaning should be obvious.

[bill-torpey]

Yes, it appears that macOS is rather strict about setting environment variables for GUI apps, which causes issues for a bunch of other apps as well, including SourceTree.

The latest release of SourceTree fixes this issue: https://jira.atlassian.com/browse/SRCTREE-7184. I can confirm that this works. (FWIW, previous workaround was to invoke SourceTree from a command shell which was bundled as an app -- not great).

[Andrew-Au]

I wrote a little test app in Swift, and the environment passed to it via double-click in Finder was indeed minimal, without sourcing either .zprofile (login session) or .zshrc (interactive shell).

I'm going to go out on a limb and claim this is probably correct behaviour. Although one could argue that the act of logging in via the Finder should trigger the profile.

However, the consequence is that any app that wants to run a Unix subprocess in the same context as a user shell needs to actually spawn the appropriate environment, not just run the executable in the host app's environment.

$SHELL is set, so you could try executing {SHELL} command. Might need tweaks to ensure that the appropriate startup files are sourced (e.g. passing -l to the shell or adding a hyphen prefix to argv[0]).

[CodingMarkus]

Environment variables only inherit to child processes. If you set an environment variable in a process, only child processes will see it, not parent processes and also not processes on the same level. UI applications are no child processes of bash or zsh, unless you start them from such a shell.

The very first process that macOS starts after the kernel has loaded is launchd, which acts like init on Linux/FreeBSD and brings up the rest of the system. Everything launched down the pipe inherits the environment of launchd and passes that on to its children, unless the environment is overridden first, which Finder doesn't do. Actually, Finder does not even start applications itself, it uses Launch Services to do that and Launch Services instructs launchd to start the application (in previous versions two instances of launchd were running, a system one running as root and a user one running as the logged in user, the later one will start the UI application and provide the environment, but already in Monterey there's only one launchd instance left).

What you can do is to write your own process that first changes the environment and then launches Fork. E.g. start Automator app and create a new "Application". As action add Run Shell Script. Select /bin/zsh as shell and then add two lines:

export PATH=...
open -a Fork

Save it wherever you want and use that starter to start Fork. Note that no matter what shell you use in Automator, the shell will not read any config files (the shell is not launched in interactive mode or as login shell), the default PATH will be /usr/bin:/bin:/usr/sbin:/sbin in either case. So you would usually append to that whatever you need:

export PATH="$PATH:/whateverDir1:/whateverDir2:..."

[vrnvorona]

Yes, it appears that macOS is rather strict about setting environment variables for GUI apps, which causes issues for a bunch of other apps as well, including SourceTree.

The latest release of SourceTree fixes this issue: jira.atlassian.com/browse/SRCTREE-7184. I can confirm that this works. (FWIW, previous workaround was to invoke SourceTree from a command shell which was bundled as an app -- not great).

If SourceTree does it, so can we? It's really annoying issue since 99% of tutorials and stuff teach to set up env in .zshrc and similar files and suddenly it doesn't work by itself.

[aparajita]

It's a MUST, otherwise commit hooks tend to fail.

Tower uses an environment.plist file in their Application Support directory.

[b2nkuu]

i found solution at is stack https://stackoverflow.com/questions/51636338/what-does-launchctl-config-user-path-do

hope your help.

[chimit]

Start Fork from your command line and it will derive ENV of the parent process. You can do that using open -a Fork command or just fork if you installed Fork CLI tools. https://github.com/fork-dev/Tracker/issues/430#issuecomment-429013890

Installing Fork CLI tools doesn't fix the problem for me. Running Fork from the command line every time is not very convenient. Any chances to get it work out of the box, @DanPristupov?

[ValentinGurkov]

I am hoping some sort of a solution gets considered. BTW, I belive more or less https://github.com/fork-dev/Tracker/issues/1227 also describes the same problem, probably the issues can be merged.

[wmadden]

@DanPristupov wouldn't this problem be solved by running git hooks in a new shell which can load the user's .profile etc itself according to their local setup? Nobody really cares what env vars Fork has access to, only the shell spawned to run the git hook commands

[niklasravnsborg]

@wmadden The git hook commands are probably executed directly without a shell; if it would spawn a shell, then this shell would take its own configuration into account, where the PATH could be modified.

For me personally, it would not only be important for git hooks but also for the git and gpg binaries, since I want to have control over which ones are used.

[wmadden]

I believe Fork has its own git implementation, no?

[niklasravnsborg]

I believe Fork has its own git implementation, no?

You can customize the git binary in it's settings.

[DanPristupov]

I need a hand with testing. Can anyone contact me by email, please? support@fork.dev