illegalhex

Sorry for opening this and not following up, and I do appreciate the replies. Firstly, I do see binaries located in /opt/local/bin, see 00_workflow_creation.png, which is great but the problem that I'm dealing with is specifically consuming previously created workflow. Either workflows that I've created myself; and presumably I can control but let's put a pin in that; but importantly workflows someone else has created. The problem I have is that /opt/local/bin is only present for selecting which language to use, but that location isn't present when executing a workflow. Initially I thought that /opt/local/bin/python and /opt/local/bin/php are listed because I manually changed PATH via launchctl, see 01_launchctl, so that both the Alfred and the Alfred Preferences binary, have PATH set as `PATH=/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin` since I've modified launchd to change the default path, see 02_alfred_processes for details but the important thing is that PATH is indeed set to what I've set via launchctl. I did that under the naïve assumption that the preferences and main application were using PATH from their running process group, but it's quite clear that can't be completely right since executing workflow do not have /opt/local/bin even when the preferences application can find executables in /opt/local/bin. At this point I took a different tack, I removed launchd from the equation and launch both Alfred and Alfred Preferences directly as my user so that I could easily control PATH and set it back to launchd's default of `PATH=/usr/bin:/bin:/usr/sbin:/sbin` and got the same result. Even though /opt/local/bin is no longer in PATH for that process. At this point I was reasonably confident that Alfred isn't using the value of PATH set via launchd and having spawned processes use values inherent by the the process group. This largely leaves two options, that Alfred is hard coding PATH or Alfred is executing somesort of shell as my user to get PATH. The first option I discounted because of the statment of "Alfred doesn't hard code paths" so I focused on the second option. I have in my ~/.zshenv the single of `export PATH="$PATH:/opt/local/bin:/opt/local/sbin"` to ensure that macports binaries are always there, even when being ran as a non-interactive shell. To that end I've created a workflow that is `printenv` by both `/bin/zsh` and `/bin/zsh --no-rcs` and the only difference is exactly what I expected `/bin/zsh` has `/opt/local/bin:/opt/local/sbin` at the end of the path and `/bin/zsh --no-rcs` does not, see 03_workflow and 04_results. I then went to confirm that my ~/.zshenv file is indeed controlling that value and changed it to be `/opt/local/bin:/opt/local/sbin:$PATH` ran the workflow again with no change to `/bin/zsh --no-rcs` as I would expect, and `/bin/zsh` has a path of `/opt/local/bin:/opt/local/sbin:/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin` which does confirm that I can controlling PATH at the time of execution of `printenv` and via `~/.zshenv` but its quite clear that by the time zsh evaluates `~/.zshenv` PATH is already set to `/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin` which doesn't quite make sense. So another test to confirm my suspicion. I update `~/.zshenv` and the workflow as below. The idea is that since /etc/zshenv isn't setting anything the next file to be loaded is `~/.zshenv`—see `STARTUP/SHUTDOWN FILES` section under `man zsh(1)` if you aren't sure about the order that zsh loads files in—I should see PATH set as `/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin` then I export PATH with `/opt/local/bin:/opt/local/sbin` appended, then when the script is ran I should see that folder that doesn't exists, `/opt/homebrew/bin`, will be in PATH and zsh won't be able to find it. And then just to be sure, `~/.zshenv` was updated to have the single line of `echo "When reading /etc/zshenv the PATH is currently $PATH"` ``` echo "When reading ~/zshenv (sic) the PATH is currently $PATH" export PATH="$PATH:/opt/local/bin:/opt/local/sbin" echo " I've updated PATH in ~/zshenv (sic) to be $PATH" ``` ``` for folder in $(echo "$PATH" | tr ':' '\n'); do [ ! -d $folder ]; echo "check for $folder returned $?"; done echo "PATH is set to: $PATH" ``` Indeed we end up with `When reading /etc/zshenv the PATH is currently /opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin When reading ~/zshenv (sic) the PATH is currently /opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin I've updated PATH in ~/zshenv (sic) to be /opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/local/bin:/opt/local/sbin ` and being shown that the folder `/opt/homebrew/bin` since that folder doesn't exists, along with PATH being set to what ~/.zshenv set PATH to. See 05_path_is_strange. ``` check for /opt/homebrew/bin returned 0 check for /usr/local/bin returned 1 check for /usr/bin returned 1 check for /bin returned 1 check for /usr/sbin returned 1 check for /sbin returned 1 check for /opt/local/bin returned 1 check for /opt/local/sbin returned 1 PATH is set to: /opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/local/bin:/opt/local/sbin ``` Now after all that, I have to conclude that Alfred _must_ be setting PATH as hard coded value. The folder `/opt/homebrew/bin` does not exists on this machine and yet it is included in PATH as soon as `/etc/zshenv` is read. That folder isn't part of PATH of the running process so it can't come from there. Alfred couldn't read from disk to emulate from a list since that folder doesn't exist. The only plausible explanation is that somewhere Alfred has a hard coded value of `/opt/homebrew/bin` and is setting that value as part of PATH when dispatching processes as part of a workflow. Where, and how I have no idea. Speculation time, I can't say for certain, but I have a strong suspicion that Alfred has strings for `/opt/homebrew/bin`, `/usr/local/bin`, and `/opt/local/bin` hardcoded, somewhere. And while all three are used for searching for a scripting environment, only the first two are being used to set PATH during process dispatch from workflows. This would match my observed behaviour and the quite obvious amount of effort put in by the Alfred team about making sure that users have a stable path. I'm sure there is some history there, and honestly understandable. However, if that is the case, there is weird behaviour on where `/opt/local/bin` can be used for a scripting language but can't be used as location for any other binary which is very odd behaviour and strikes me as unintentional behaviour. Happy to go into more details if you need them, I realize this is an info dump. I don't think I need to tell you that managing PATH is hard, you've obvious done a lot of work to make sure that most users don't need to think about this, but I'm pretty sure I've found a bug that has slipped by since this a non standard use case.

Hi there, it would be extremely helpful to allow users to specify the PATH being set for workflows. 1) It seems that workflows do not use the PATH environmental variables of the parent Alfred process group. If I configure the Alfred daemon via launchctl the Alfred proces wil have the path of ‘/usr/bin:/bin:/usr/sbin:/sbin:/opt/local/bin:/opt/local/sbin’ as I intended, however any process spawned in workflows have a very different path of ‘/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin‘ which isn’t correct for my machine. 2) Workflows now use zsh with the ‘—no-rcs’ flag, including the 1Password workflow which is how I found this problem, so zsh won’t read ~/.zshenv. That is normally how I ensure that /opt/local/bin and /opt/local/sbin are in the path since I want them to be set even for non-login and non-interactive shells, for example say an Alfred workflows . But with the ‘—no-rcs’ flag being set only /etc/zshrc will get read resulting in PATH being wrong for my machine. 3) I can’t find where the ‘/opt/homebrew/bin:/usr/local/bin’ string is stored, I can tell that there is some string formatting somewhere when Alfred spawns zsh since if I change ‘/etc/zshenv’ to set PATH of ‘$PATH:/opt/local/bin:/opt/local/sbin‘ the shell has PATH of ‘/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/local/bin:/opt/local/sbin‘ so it would seem that Alfred is using ‘/opt/homebrew/bin:/usr/local/bin:$PATH’ but I can’t find where the string of ‘/opt/homebrew/bin:/usr/local/bin‘ is coming from. It doesn’t appear to be any user exposed setting nor can I find that in any plist file. Is it statically set in the binary? I really don’t want to do decompile the binary to find out. 4) it seems odd that the path for homebrew is being set but not macports if there is no user configurable way of setting that value. To assume that no user would have binaries in ‘/opt/local/bin’ and ‘/opt/local/sbin’, to not inherent values from the parent process group, give no way to set PATH by the user, and to launch zsh in a mode that only reads ‘/etc/zshenv’ is frustrating from a user prospective. it would seem that unless Alfred exposes a way to change how PATH is set users are left with either using /etc/zshenv to ensure that PATH is correct which feels not great as editing system files on macOS comes with some issues, or ensure that binaries exist in the PATH being set. I could see something like ‘sudo mkdir -p -m 755 /opt/homebrew/bin’ and then symlink subdirectories for bin and sbin to /opt/local/bin and sbin but that feels worse than using /etc/zshenv. But unless Alfred has some way, even if it is something like edit a plist file, to set PATH users are going to need to go out of their way to accommodate Alfred’s quirks.