Script no longer works under Sequoia - HELP?

Desktop & Console macOS
1

I have a friend that just had to replace an older Intel Mac Mini that was part of his Home Entertainment System. He had a script that ran on boot up that is described below. However it seems that due to changes in macOS, it no longer works properly, and Apple Tech Support is unable to help. I hope that perhaps someone here can come up with a possible solution. If more info is needed, I can relay the request to him..

Thanks

Details: New Mac Mini (M4) running Sequoia 15.5 (all of the latest security updates installed). An AppleScript, running in Script Editor, that opens the Terminal app and sends 3 commands (keyboard entry) will sometimes run perfectly & other times will not run (due to keystrokes permission error). A standalone app made from the script will also sometimes work perfectly and other times not. The very latest version of Python3 is installed on the Mini.

The standalone app is needed so I can make it a login item and run the script if there is a power failure and the Mac Mini reboots.

The script was working PERFECTLY (both in Script Editor and as a standalone app) on a previous Mac Mini (2014 Intel).

This is the script:

delay 30

tell application "Terminal"
activate
end tell

tell application "System Events"
keystroke "cd pigs"
key code 36
end tell

tell application "System Events"
keystroke "sudo python3 pigs.py"
key code 36
end tell

tell application "System Events"
keystroke "[Mini administrator password]"
key code 36
end tell

  1. When launched, the script waits 30 seconds before opening Terminal. This is to allow the Mini time to fully reboot after a power failure.

  2. Script opens Terminal.

  3. Script changes Terminal’s command line to the “pigs” (folder). The pigs folder is in my user account directory.

  4. Script runs pigs.py (which is a python script).

  5. A sudo command requires the administrator’s password, the final step enters that password.

I realize that neither you or virtually anyone else will have a pigs directory or the pigs.py script on their Mac. But other directories and/or programs could be substituted for testing.

Again, sometimes this script works, other times it doesn’t. I cannot figure out any rhyme or reason nor any common situation that explains why it will sometimes run. It’s like a roll of the dice. Again, it worked PERFECTLY (for about 10 years) on my previous Mac Mini (older OS).

These are the errors that pop up when the script chokes. First, when it is run in the Script Editor and chokes:

thumbnail
thumbnail1080×1077 94.7 KB

This is the error when the standalone app chokes:

thumbnail-2
thumbnail-2598×576 108 KB

Both apps have been given the necessary permission (accessibility):

thumbnail-3
thumbnail-31080×960 95.9 KB

Right after it chokes, I can run it again and it might work (no error). Sometimes it works, sometimes it doesn’t. VERY weird! When it fails, it is failing at the very first keyboard command (“cd pigs”).

Any help you can provide is appreciated!

1 Like
2

did you try to add system events to the accessibility list ?

‘/System/Library/CoreServices/System Events.app’

3

I would not do it like this at all in the first place. I would rather write .plist file and let launch daemon call Python script.

Nice and short explanation of what launch daemons and launch agents are:

How to call Python script from launch daemon:

Pros: you don’t need to send keystrokes and “enter” password, as launch daemon will launch your script under root; your script will run without the need for user to login

Cons: your .plist file or your script could “hang” and make computer not accessible even through SSH due to the way how launchd is used to launch everything on macOS, so be very cautious.

1 Like
4

came here to say launchd was the answer but didn’t know that macOS could hang over something like this, and that kinda makes me angry (at apple). :smiley:

cron still works on macOS… even if launchd supposed to be used, maybe cron might be a better solution?

5

Well, if that happens you should be angry at yourself. Standard way of starting daemons on startup was init, and cron for scheduled jobs. Apple supported that, but decided to do better, and launchd is better.

In “init” world, sshd and everything else is basically running all the time in background, hundreds of daemons, most of the time doing nothing but waiting for connection on port 22. On macOS, after startup and before login only few daemons are running. In case of SSH, launchd will detect connection on port 22, launch sshd and let it handle the connection.

So, if you made mistake in your plist file or in the script you are trying to launch, startup process hangs and you can’t even access it through SSH. I learned in hard way some 15 years ago, I’ve had typo in my .plist, restarted the server remotely and in a few minutes realised I have to call someone to grant me access to server room on the other side of town to fix the problem.

6

for a commercial operating system, I’ve seen bad configs hang linux, but not windows (at least not the NT varieties, and cloudstrike doesn’t count). Windows will fail or timeout and log the error.

Thats my hangup. Things should break gracefully. The possibility on various linux distros makes sense: the audience is much different than the macOS audience – even their developer/pro users.

7

my friend posted this also on MacRumors and got the following response

You could simply use
AppleScript:
tell application "Terminal"
    do script "echo 'Mini administrator password' | sudo -S python3 ~/pigs/pigs.py"
    activate
end tell
saved as Run-only

He tried it and said it has worked perfectly on 5 test reboots…

Thanks to everyone

2 Likes