Post flight shell script error: "launch path not accessible"


#1

I wish to use a postflight shell script to run an appleScript over a JPEG manipulated in RB, after the RB processing is complete. The RB processing writes the processed JPEG file to the selected directory in the penultimate step. But the shell script (the final step) does not complete.

I am getting an error in the RB console “NSInvalidArgumentException: launch path not accessible”. I think this may mean that the location of the processed file that is passed to the shell script is not accessible by my AppleScript (a temporary directory?).

The shell script I am attempting to run as the last step in my RB window is:

#!/bin/bash
osascript /path/to/my/scripts/folder/Mozjpg-Low.scpt “$1”

The shell script is located in the same scripts directory. It should be read-accessible to RB.

When I run this command from the terminal replacing the argument with the path of the file that RB writes it runs fine.

What am I doing wrong?


#2

Try giving the full path to osascript: /usr/bin/osascript. I’m guessing /usr/bin isn’t in the $PATH environment.


#3

Thanks Gus. I checked: /usr/bin is certainly in my $PATH (hence the script works without it when run in the Terminal).

I’ve tried adding the full path to the script ("/usr/bin/osascript…") anyway: no change. Same error in the RB console.


#4

Is your shell script executable?


#5

Hello Gus,

I have changed the AppleScript so I can call it directly from RB.

However my AppleScript processes only JPEGs so I convert to JPEG before writing the file in the penultimate step in RB (then call the AppleScript).

When I process an image that is already a JPEG the script processes the ORIGINAL JPEG file. When I process some other file (e.g. a PSD), RB writes a JPEG but the script fails.

Could I just confirm that the path RB passes to the shell script (that calls the AppleScript) is the path + filename + extension of the processed file and not the input file?

Thank you.


#6

In Retrobatch builds 704 and earlier they process on the original file. The idea was that you’d maybe filter some things out via machine learning or rules, and then run your script against the original.

So here’s an idea I’m contemplating: maybe it should process on the last known location? So if it’s after a write, then use that, otherwise the original. Does that seem reasonable to you?


#7

Not only reasonable but clever and helpful. Thank you Gus.


#8

I’ve just put up a new build (#706) which fixes this issue. Try it out and let me know how it works for you: http://flyingmeat.com/download/latest/#retrobatch