executables in /usr/local/bin not found in macOS 10.15

[reduzent]

On Linux, [command] finds executables in /usr/bin/ and /usr/local/bin. On macOS 10.15 (Catalina), [command] only finds executables in /usr/bin, but not in /usr/local/bin. exec <command> where <command> is some binary from /usr/local/bin returns 2 on the left outlet, while the other outlets are silent.

[umlaeute]

that looks like a PATH issue (most likely in your .profilerc).

if so, i think you cannot "fix" it in [command], as the current behaviour is actually desired and configured by the user (in reality it is configured by the system, and whatever the user did to make /usr/local/bin visible in the terminal did not catch the case of [command] - and other process spawning methods. but that's a configuration error on the user's side).

my point is, that you cannot distinguish the system defaults from actually user-desired configuration, and thus i would err on allowing the user to configure PATH as they want it and not override their decision.

just add some documentation on how to add /usr/local/bin to the PATH.

[umlaeute]

as an aside: it might be interesting to be able to set per-process environment variables (so you can manually add /usr/local/bin and /Users/reduzent/.backdoor/bin/ to your PATH).

setting envvars could be done via a simple [env( message to [command]. the only missing part is to query the current value of an envvar (my gut feeling tells me that [command] is not the right object for this; however you could already do something like [exec echo $PATH()

[reduzent]

You're right in that the problem probably doesn't lie in [command] itself. I am not sure where the difference comes from:

• [command]: PATH=/usr/bin:/bin:/usr/sbin:/sbin
• Terminal.app: PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

On a default macOS installation, without modifying anything, [command] doesn't see the same set of commands as the terminal app, which is confusing. I wonder, if [command] should just add /usr/local/bin for a more consistent experience.

[umlaeute]

my naive explanation is: Terminal.app starts bash, which in turn reads .bashrc (and /etc/bashrc) where you can set all the PATHs you like.

in reality its more like this: paths are stored in /etc/paths (and /etc/paths.d/) and these are added in /etc/profile via a call to path_helper.

see also https://apple.stackexchange.com/questions/128897

i still think that adding random paths "for a more consistent experience" is a disservice to the user, as it makes the experience inconsistent on a grander scale (Terminal.app, ssh, cron, [command],...)

[reduzent]

/etc/paths and /etc/paths.d/ are considered by shells. Normal applications (.app) do not consider it, according to:

https://apple.stackexchange.com/questions/106355/setting-the-system-wide-path-environment-variable-in-mavericks

When launching Pd from Terminal / bash, [command] has all the paths set.

Since I'm usually running Pd from the command line on Linux, I first thought that is maybe the reason I see the same paths in [command] as in the terminal. However, when I launch Pd as application, I still get the same paths. On Linux, it seems there is no difference between the user session and the shell session. On macOS, the env in an application is much sparser compared to the env of bash.

I guess, the only non-hacky way to address that is to implement #16.

[reduzent]

This is not an issue with [command], rather in which environment Pd is launched. I close this