paulw Posted November 4, 2021 Share Posted November 4, 2021 22 hours ago, vitor said: Alfred doesn’t (and shouldn’t) edit the script’s contents, so if php is literally written on it the issue still manifests. But you (or the author) can edit the script. Add to it, at the top, the line export PATH="/opt/homebrew/bin:/usr/local/bin:${PATH}" and it should work. Oh, ok, I would have thought that Alfred would be able to make use of the user's PATH, instead of having to explicitly define it in the scripts. Is there a reason why it can't? Link to comment
vitor Posted November 4, 2021 Share Posted November 4, 2021 (edited) 1 hour ago, paulw said: the user's PATH That doesn’t exist. Instead, what you’re doing is defining a PATH in your shell’s startup files (like .bashrc or .zshrc) which is evaluated every time you open a terminal session. That’s an important distinction. What you’re thinking of as a configuration of the user is in fact of the shell and doesn’t exist outside of it. If you change your shell, your PATH doesn’t transfer without you doing something because the new one isn’t reading the old files. In theory, Alfred could try to find the startup files of every shell and read them to load the PATH. In practice, that could go very wrong. It would be confusing if you have multiple of those, and setting the PATH doesn’t happen only when you explicitly set it in the shell, it can be (and is) modified by version managers such as chruby and pyenv. So now Alfred would need to parse all of your (possibly slow—ever tried oh-my-zsh?) shell startup files on every call of every script, of which there can be multiple on any single Workflow run. And in the end, what we’d get from it would be a flux of broken unsharable Workflows which “works on [the dev’s] machine” but not on anyone else’s because they have a particular shell setup you don’t. 1 hour ago, paulw said: that Alfred would be able So Alfred could do it, but it’s good design that it doesn’t. Edited November 4, 2021 by vitor Link to comment
paulw Posted November 4, 2021 Share Posted November 4, 2021 @vitor, wonderful, thanks so much for clarifying. Now I understand the issues much more clearly! Link to comment
deanishe Posted November 5, 2021 Share Posted November 5, 2021 When you log into macOS, your session isn’t bootstrapped from a shell like it is on Linux (at least, it used to be), so none of the settings in your .bashrc or .zshrc are loaded. Those files are also explicitly for interactive sessions (when the shell is connected to a terminal emulator like Terminal.app or iTerm), so they also aren’t loaded when you run bash/zsh from any other application, like Alfred. paulw 1 Link to comment
BocciaMan Posted February 7, 2022 Share Posted February 7, 2022 I resolved the php issue and got the Units workflow to work by installing php via Homebrew. I hope this benefits all. Brew install php This is what got the workflow to work for me. Softov 1 Link to comment
godbout Posted April 17 Share Posted April 17 On 7/1/2021 at 3:05 AM, Andrew said: My solution will likely be to make the default scripting language paths globally configurable, so you change it in one place to "fix" it for all workflows. wondering if that has ever been implemented? my PHPs are installed through asdf, not homebrew. so currently i have a manual symlink through within the homebrew bin. works, but kinda suck. Link to comment
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now