Big Sur Beta open Terminal command fails to launch script apps

On Big Sur Beta 9 (9/30/20) the Terminal open command fails to launch script applications, both old and new. Nothing happens and the command returns without error. It doesn’t matter if Script Debugger or the Apple Script Editor is/was used to create the app or where the script app exists, even in the Applications directory. Example: ‘open -a TestScriptApp’. I’ve reported this via Apple’s Feedback Assistant app.

Applescript apps cannot access command line parameters, so I have lots of scripts use the open command to indirectly pass them via environment variables, which is quite handy. My script ecosystem is quite broken until this gets fixed.

FWIW, I just tried this on my test Mac:

open -a /Users/shane/Desktop/

and it worked fine. So perhaps there’s something else going on.

Thanks for that, but using a path also doesn’t work for me, even a path directly to the binary executable in the MacOS sub-directory; just does nothing and returns to the shell prompt. I’ve also tried the -b option using the bundle ID, signed and unsigned apps, and placing the script apps in the /Application directory, all to no avail. I have Terminal set for Full Disk Access and Accessibility too. Clicking script apps in the Finder works fine, but that won’t allow me to pass parameters. Very strange.

It sounds like you’ve tried all the obvious things. I presume you’ve confirmed that open is working with other apps.

I suppose you could try calling open via do shell script, to pin down whether Terminal is the problem.

Is your test Mac a mostly pristine Mac OS or like my system which was updated to Big Sur from my standard Mac loaded with years of added apps and scripts? The reason I ask is I just discovered the open command running in a completely pristine latest Big Sur beta in a Parallels VM works perfectly. (A simple “on run-beep-end run” stored as an application launches as expected with 'open -a '. That VM beta was created by installing a pristine Mojave system which was then updated to the latest Big Sur Beta.) To me, this implies this bug is related to the fact that I’ve updated to the Big Sur Beta from my fully loaded user system.

Why only script apps fail to launch with the open command, I haven’t a clue. I can double-click them in Finder and they launch OK, but that doesn’t allow me to pass parameters in the form of environment strings. My “do shell script” statements are where I first saw the problem, then found out this occurs even in Terminal. I’ve done lots of tests, resetting and dumping the Launch Services database, trying both signed and unsigned scripts, etc. I am investigating further and will report any findings.

I just tested it on a MacBook Pro that’s a couple of years old. It’s not used heavily, but it’s been updated many times.


Have you check that the executable in the bundle ‘applet’ is executable.

chmod +x /Contents/MacOS/applet

Any script that that is not executable will fail with open command.

Thanks for the tips and info. I just checked and my script apps are marked executable. If they weren’t I assume double-clicking them in the Finder would fail, and everything worked fine before the Big Sur beta upgrade. I also have script apps that execute via launchd and they are running normally, as are script apps run via keystroke triggers in Butler.

Nothing shows up in the system log. If I use the -W option with the open command to wait until execution ends, the shell won’t return for the next prompt even though no actions at all appear to be occurring and no extra process shows up in Activity Monitor. All very strange.

I’ve failed to find the reason for this problem. I even tried examining the open command source by downloading all 195 tar files of Darwin from Apple, but failed to find the open command there, even though other commands are present.

Currently I’ve changed my do shell script strings from using the open command to pointing to the hard-wired full executable paths of my script apps (…/Contents/MacOS/applet) and redirecting shell output to null and running in the background (">/dev/null 2>&1 &").

If I eventually discover why this problem is occurring, or a future MacOS update removes it I will update here.

Unfortunate news on the problem of the open command line failing to open script apps. Turns out the problem occurs depending on how many launchd tasks I have in my system, and not on which launchd items are present. I discovered this by doing a Safe Boot and seeing the problem disappear. I then spent a few hours attempting to isolate the “culprit” plist file only to find out the bug re-appears depending upon how many active entries I have.

Another hint that launching apps has bugs in the Big Sur Beta 9: three times now I’ve had the Finder give errors when double-clicking documents, claiming it doesn’t know who they belong to. And then when I use the Finder to drop the documents onto the app icons, the apps claims the files are corrupted. Rebooting fixes this problem, implying Launch Services is somehow getting corrupted.

We’ll just have to wait for Apple to knock some more bugs out. I’ll report back when the open command line problem is fixed. Otherwise, I’ve not had any problems using Big Sur Beta 9 as my standard OS version.

FWIW, I’ve seen some of those Finder issues too.

Big Sur Beta 10 still has the open command line problem of failing to open any script applications on my system. If I remove most of my launchd items and reboot, the problem goes away. This problem is not sensitive to which launchd items I have enabled.