@agriggio Hi Alberto, for some reason when I launch ART (latest nightly arm64 build) from the MacOS launcher, user commands don’t seem to launch.
It only works if I start ART from a terminal, and if I provide the complete path to the bundled ART-cli (/Applications/ART.app/Contents/MacOS/ART-cli) in the user command bash script (even if I put ART-cli in /usr/local/bin).
Am I doing soemthing wrong?
I don’t know, I need to investigate… maybe some hardened security settings in the latest macOS? Did you upgrade to 26 perhaps? FWIW everything works fine here, but that might be because I built ART myself.
EDIT: I just tested the nightly build from github and (after whitelisting with xattr -dr com.apple.quarantine ART.app) it works fine for me, on macOS 26…
I’m still on Sequoia 15.6 (Mac mini M1). The app is whitelisted, but still when I try to run a user command nothing happends, I don’t even see the zenity message that is supposed to appear.
If I start ART from terminal and provide the full path to ART-cli in the command script, it works.
If I start ART from terminal but don’t provide the full path to ART-cli in the command script, I see the zenity message but no image is created(i guess because ART-cli is not found).
That’s not a big deal for me, I just wanted to help a French user from the French forum.
Just to understand: does the command work if you use absolute paths to ART-cli, zenity and any other binary that you are using in the user command? If so, it might just be that your PATH env var is set up differently when using the terminal wrt. when using the ART app – I think this is normally the case on macOS (I’m still new to the platform so I haven’t figured out all the differences with linuxes…)
No it’s only the ART binaries for which I have to supply the full path. Both zenity and gmic are supplied without full path.
Here’s an example that works if I run ART from terminal with /Applications/ART.app/Contents/MacOS/ART
#!/bin/bash
d=$(mktemp -d)
/Applications/ART.app/Contents/MacOS/ART-cli --progress -s -Y -t -j -o "$d" -c "$@" 2>"$d/error" |
zenity --width=500 --progress --auto-close --text="Aurora…"
gmic "$d"/*.jpg gcd_aurora 6,1,0 output "$@"-aurora.jpg
rm -rf "$d"
I meant not from the terminal – sorry if that was unclear
Well, if I don’t run ART from the terminal, whatever I set in the script (full paths or not) the user command doesn’t work.
Correction: it looks if I provide full paths for all executables in the script, then the user command does work when ART is not started from terminal.
Did you try changing the #!/bin/bash shebang to #!/bin/zsh (the default macos shell)?
In fact my last test was with #!/bin/zsh.
Ok, then a simple workaround is to set PATH at the beginning of the user command so that you don’t need to specify the full paths of the executables… I think there might be other ways, e.g. a quick search gives me this link (warning: I didn’t read it…)
Thanks, I’ll take a look.
So, I tried to add the paths to /etc/paths as suggested in the link you gave, I restarted the machine, verified the new $PATH variable was updated, but this didn’t change anything.
What worked instead, was to set $PATH in the user command for every program (including the full path to ART-cli):
export PATH=/opt/homebrew/bin:/Applications/ART.app/Contents/MacOS:$PATH