Can the following very special case be made work under Sequoia - and of course, how?:
# Tell applications in the target user's session to quit gracefully
sudo launchctl asuser "$USER_ID" osascript -e '
tell application "System Events"
launch
set appList to name of every application process whose background only is false
repeat with appName in appList
try
tell application appName to quit
end try
end repeat
log out
end tell
'
This is an attempt to more gracefully log users out, instead of brute force killing their loginwindow process or doing
No idea whether this is the cause but the -e option is used to add a single line of script, not an entire script. You can string commands together with multiple -e.
The man page for osascript provides three approaches (including -e).
No, that’s not the issue. Try for yourself:
• Copy the following (completely nonsensical in various ways) script into a file called ‘test.sh’, do a chmod +x on it and run it:
#!/bin/bash
osascript -e 'tell app "System Events"
beep
end tell'
It works.
The issue clearly seems to be the tightening of security measures against vicious Apple Scripts in Sequoia. I only wonder if there is a method to grant security permissions to this kind of scheme in a proper way.
I also wonder if it is possible to put the AS code in an apple script applet deployed to every user’s account, give it the necessary permissions and call it via
sudo launchctl asuser "$USER_ID"
from a shell script avoiding osascript altogether.
I hope members of the community will share their experiences and insights.
Does one really have to force kill out logged-in users just to be able to restart a machine for an OS update?! This, IMHO, is ridiculous.
Great! This indeed works flawlessly! Thanks a lot, this really helps! (Sorry for the belated reply, just only managed to try this out a minute ago.)
Although I do not really get what Accessibility settings of the executing account (as opposed to the target account) has got to do with this. Accessibility normally is related to GUI scripting, which does not get used in my case. And yes, well, the target is a GUI session. And yes, well, I am using System Events, the process in charge of GUI scripting. But all of this to me looks more like coincidences.
If at all, I’d have expected the target account would have to accept / allow being manipulated from the outside.
Do know of any sources where I could update myself on this issue?
Once again: a great many thanks for this invaluable hint!
Regret unaware of additional resources. I only became aware after encountering the same issue when scripting some Apple Mail functions and just did some internet digging and trial-and-error testing. Happy it helped in your case…
FWIW, in macOS 27.0 Golden Gate, the Accessibility entry in Privacy & Security is renamed to Device Control and Data Access, and it’s described in the dialog as:
Apps with this access can view and send email, edit contacts and photos, monitor your keyboard, track websites, record your screen, control any app on your Mac, and more.
There is also a Privacy & Security entry called App Management, which I don’t recall from earlier versions of macOS, but perhaps that’s just my poor memory. This entry is described as:
Allow the applications below to update or delete other applications.
It is a bit difficult to know what belongs where in Security & Privacy.
One addition here: Last night I realized that Accessibility settings alone are not enough. In the target account the respective terminal app needs to have permission to use System Events (for my intended purpose). I realized this when I tried to run my script experiments in Terminal.app where it did not work, whereas in iTerm it had. The difference was that iTerm had the permission set, whereas Terminal.app didn’t. This all makes sense as a precaution to open a security loophole. So to be able to use a script like the one proposed by me the admin has to make sure that this permission is set in advance in every user account on the machine.
I am seeing some slow progress with my Safe Logout Script but in the end it will and can not be failsafe because it has to use UI scripting of unknown applications and will be only marginally better than force killing of the user with wide variation on the individual circumstances, from perfectly saving all open documents before quitting to circumstances that make sending kill -9 of an application unavoidable to be able to quit other running applications more gracefully.
The main standard the script hopes to be able to rely on is the fact that after sending an application quit saving yes event, all document based applications will post a save dialog for dirty and previously unsaved documents, with a text field for the file name highlighted and a save button that can be pressed by sending keystroke return. After a lot of tweaking this now seems to work fairly well. When I can come up with some kind of satisfiying version of this script I will post it here.