-
-
Notifications
You must be signed in to change notification settings - Fork 30.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Python Launcher app on macOS 10.15+ fails to run scripts #84657
Comments
I can’t figure out how to use Python Launcher on Catalina. Or it is broken. Anyway: It does absolutely nothing. When I double click a scriopt file, I se very shortly the preferences window of Launcher, and this is all. The script is not executed. I made a very simple script which writes a small text file. The script works flawlessly, when I call it in the terminal, but the Launcher seems not even to open it. Is this a bug with Catalina, or what is to be done? |
Thanks for the report. At first glance, it does look like it's broken on macOS 10.15. I'll look into it. |
Thank you! That’s an Information which Looks bad but has good parts. At least it may be not my fault ;) Best regards Werner Hintze Am 2. Mai 2020, 19:10 +0200 schrieb Ned Deily <report@bugs.python.org>:
|
I tried to report this concern under Documentation, but got shot down as duplicate. I have the same results. I tried to make Launcher the default "Open With" application for a script, also tried dragging (and Option dragging) the script to the Launcher, neither worked. I have received several results:
|
An update on this: it turns out there are two different problems with the launcher app as a result of security changes introduced in macOS 10.15 Catalina. The first is that the launcher did not execute files launched with it (for example, by double-clicking on the source file or by dragging the file to the launcher icon). The launcher launches but no Terminal window opens. That problem has been fixed in the just released python.org macOS installer for 3.8.3 and will be fixed in the next releases of 3.7.x and 3.9.x (pre-release). The second problem is that the launcher app is not able to launch Terminal.app to run the script if Terminal.app was not already running. Unfortunately, I was not able to provide a fix for that problem in time for 3.8.3. However, there is a relatively easy workaround until that fix is available. Before using the launcher app, just ensure that Terminal.app is already launched; the launcher will then be able to run any number of scripts in new terminal windows as expected. One easy standard way to launch Terminal.app is to invoke Spotlight by clicking on the "magnifying glass" icon near the upper right end of the macOS menu bar and then typing the letters "terminal" followed by the Return key in the resulting search window. When a script is done running, just close the terminal window but don't quit Terminal.app if you want to keep using the launcher. |
I appreciate the update. |
Well heck. Last login: Thu May 14 07:57:11 on ttys000
But what do I know? % cd '/Volumes/BigHDD/Ortho4XP-master/' && '/usr/bin/pythonw' '/Volumes/BigHDD/Ortho4XP-master/Ortho4XP_v130.py' && echo Exit status: $? && exit 1
Traceback (most recent call last):
File "/Volumes/BigHDD/Ortho4XP-master/Ortho4XP_v130.py", line 9, in <module>
import O4_Imagery_Utils as IMG
File "./src/O4_Imagery_Utils.py", line 597
SyntaxError: Non-ASCII character '\xc2' in file ./src/O4_Imagery_Utils.py on line 597, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details
But what do I know? % |
Glenn, you will need to change the Interpreter setting in the Launcher Preferences panel. In the box that says "/usr/bin/pythonw", type "/usr/local/bin/python3"; that setting will then be remembered on subsequent launches. |
Thank you Ned. So close now. After your final fix, if I understood you correctly, we will no longer have to open Terminal? And, excuse my vast knowledge gap, but will it ever be possible to not have the terminal run in the future? |
It is working now. However, I end up with two terminal windows open. |
Is there no way to edit a previous comment? |
That's correct. That's the way the Launcher works on previous version on macOS.
That's the way the Launcher works. It's a very simple-minded application. Essentially all it does for you is to provide an easy way from the Finder to run a Python script in a terminal window, i.e. by double-clicking or by drag-and-drop. Like on other Unix-based systems, Python on macOS is typically used as a command line program that runs under a Unix shell in a terminal window of some sort. Python itself does not provide a macOS GUI application interface; that is something that IDLE does (and other third-party IDEs that support Python). The Launcher app dates back to the very earliest days of Mac OS X when Python for Classic MacOS (System 9) was ported over. The Launcher is not really used very much as far as I can tell and its age shows with some usability and even security concerns. If you are comfortable using a terminal window and a Unix shell, you may find it more convenient to just run scripts directly there rather than indirectly using the Launcher, e.g. $ cd Documents # or whatever Folder
$ python3.8 your_script.py Or, to open Python in interactive mode, where you can enter statements and immediately see the results: $ python3.8 If you prefer a full-featured dev environment, you can use IDLE.
On the current bugs.python.org, no, sorry!
As far as I know, opening Preferences is a "feature" of the Launcher and can't be prevented. |
I believe, I found a simple way to get what you are looking for: Open Automator and create an app. Save this as MyPythonLauncher or what you want. Test it: Drop a Python script on the app. It should execute without opening the Terminal (at least if it is a GUI-script). If this is not clear, write me on we.hintze@gmail.com --
|
From comments in duplicate bpo-46043: |
FWIW, I'm experimenting with using Scripting Bridge instead of raw Apple Events in Python Laucher. Mostly to check if that fixes the issue because I can run scripts in Terminal using Scripting Bridge from a Python script using PyObjC. Scripting Bridge would also result in slightly easier to read code. On my machine (M1 Mac Book running macOS 12.0.1) Python Launcher cannot start scripts (as described in this issue). Same when I strip code signatures (and ad-hoc sign without using the hardened runtime) |
It looks like this is related to code signing and entitlements, in particular:
As mentioned before I've experimented with ScriptingBridge in Python Launcher, replacing "doscript.m" by the code below:
That's equivalent to the python code I posted earlier. This is not production quality code, it compiles with a warning about "doScript:in:" that can be avoided by a different way of using ScriptingBridge. That's irrelevant for this experiment though. When I test the call to "doScript:in:" *fails* (returns nil) when launching the app regularly, and *succeeds* when running as a terminal command (as mentioned earlier). |
Pfff.... Apple's documentation is too incomplete. In recent versions the apple events entitlement only works when the program also has an NSAppleEventsUsageDescription key in Info.plist with a string value that describes why it needs the entitlement, this information is shown to the user on first launch. When I add this key to info.plist and resign the launcher works. I forgot to create a screenshot of this and cannot recreate the system dialog that gets shown, probably documentement somewhere that I haven't found yet... For now I used: <key>NSAppleEventsUsageDescription</key> This requires no code changes. |
Thanks, Ronald, for tracking down the NSAppleEventsUsageDescription requirement! The PR here solves two problems encountered by users of the macOS Python Launcher app on recent macOS releases (10.14+):
The solution to item 1 was to no longer specify an absolute path to Terminal.app but rather let LaunchServices figure out the path. Item 2 was fixed by adding the NSAppleEventsUsageDescription key to the launcher app's property list. The first time the launcher runs, macOS displays a message to the user requesting permission to use Apple events; if granted by the user, the launcher will now be able to send open events to Terminal.app and all is well. Tested on the most recent releases of macOS 12, 11, 10.16, 10.15, 10.14, and 10.9 and on both Intel and Apple Silicon Macs. Merged for release in 3.9.10, 3.10.2, and 3.11.0a4. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: