2

Major edit

I've just discovered that the Automator workflow I'm having problems with works perfectly if I run it by pressing 'play' in the Automator window, and it seemingly only fails when I save it as a Quick Action and try and run it by clicking the button in the Preview pane.

Original post

I have an Automator action that iterates through a list of files selected in the Finder, running a python script on each of them in turn. The workflow receives a list of files or folders in the Finder, and then consists of a single 'Run Shell Script' block with 'Pass input: as arguments'.

for f in "$@"
do
    /path/to/python_distro /path/to/script.py "$f"
done

In Catalina, this fails with an error: The action “Run Shell Script” encountered an error: “path/to/python_distro: can't open file '/path/to/script.py': [Errno 1] Operation not permitted

How can I get Catalina to permit this? I've already tried adding Automator to the list of apps that are allowed Full Disk Access, and restarted Automator and killall Finder'd, but that did not fix my problem.

Improve this question
6
  • I'm experiencing a very similar issue too with Catalina, Automator, and python2. How complex are your python scripts? Can you run a simple print("Hello World") script from automator? – TabsNotSpaces Nov 4 '19 at 17:37
  • @TabsNotSpaces Yes, that works fine—it's just when I want to access files on the filesystem that it fails, as far as I can tell. – John Coxon Nov 4 '19 at 22:54
  • 1
    @TabsNotSpaces I think I might have misinterpreted you—running print() statements setting the shell to Python works, but having script.py above simply be a single print statement does not. – John Coxon Nov 5 '19 at 10:26
  • OK - we're experiencing different problems then. Catalina also changed how PATH is set in Automator, so I am currently unable to import 3rd party packages into my automator python scripts – TabsNotSpaces Nov 6 '19 at 20:50
  • @TabsNotSpaces The reason that my print() statement works okay is due to the edit above. Although if you find out how to change the PATH in automator so that you can import third-party packages, I suspect that would also solve the issue I'm having here, so please post it as an answer! – John Coxon Nov 11 '19 at 17:34
1

In my case adding the Finder to the apps having full disk access in system prefs > security & confidentiality > confidentiality tab enabled me to run a Python script (without this I was also getting an "Operation not permitted" error).

Improve this answer
1
  • Thank you so much! – John Coxon Dec 21 '20 at 13:04
2

Running python scripts in shell scripts seems to work for me. Does the script have executable flags set?

Also, is there any reason you're using a shell script to pass the arguments to the python script, and not just embedding the python script in the Action?

You can set the 'Shell' drop-down value to /usr/bin/python, to use the bundled system python; or you can just use #!/usr/bin/env python at the start of your script.

Automator will even help you out by offering:

import sys

for f in sys.argv[1:]:
    print f

to get your arguments into your script.

Improve this answer
6
  • This way enables me to keep the script in a github repo and have it update when I make changes to the repo; but I’ll try both your suggestions and report back! – John Coxon Nov 4 '19 at 12:18
  • Marking the script as executable did not work, but using your #! trick to specify my preferred Python distro and then putting the script in Automator directly did. I won't mark this as the answer just yet, in case someone has an answer that answers the question more directly, but I'll do so tomorrow if nobody does. Thank you! – John Coxon Nov 4 '19 at 23:07
  • Hi Ben, I'm afraid I think I might need to unaccept your answer. Turns out the reason that the #! trick worked was because I wasn't relying on anything Python 3-specific in that script; but if I create an Automator workflow that just contains the 'Run Shell Script' action and have a script that's just #!/usr/bin/env python print(2/3) I get 0 returned, which is a clear indicator that Python 2 is running and not my Python 3 distribution. As such, I'm back to needing to run any Python 3 script from Bash, sadly. – John Coxon Nov 11 '19 at 17:19
  • (See also a major edit to the question to reflect a revelation I just had about the problem.) – John Coxon Nov 11 '19 at 17:35
  • @JohnCoxon Shouldn't it be #!/usr/bin/env python3 ...? Without the 3, then 2 is expected. – benwiggy Nov 11 '19 at 20:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .