Failure to access UI scripting in Terminal not resulting in error

AppleScript
, ,
#21

The keystroke failure is supposed to be caught there. It used to be. Now it’s random.

#22

I will. Thank you. But that used to work with Big Sur. With Monterey it fails randomly with the script floats without sending the keystroke until I kill it. Sometimes it works but it works every time with Big Sur.

#23

Sorry, I wasn’t being clear. In what situations would a keystroke command fail ? That is to say, in what situations would the keystroke command throw an error ?

#24

The keystroke can’t happen because there is no accessibility access for ex.

That’s the reason why I put the try block in the first place. I keep changing my scripts to I need to re-register them in the Security preferences. When I forget to do that, instead of wondering for hours why the thing does not work I prefer to have the script remind me that I need to re-register it. Hence the contents of the alert message.

That’s how it used to work.

Now, regardless of whether the script is re-registered or not, it will not be able to do the keystroke. Terminal is activated, and then, nothing, the script just floats. Debugging in SD did not give me any hint. Even when I run it step by step, it just stops there and wait for something, I have no idea why.

#25

I think you can determine ahead of time whether accessibility has been granted by reading the System Events property UI elements enabled. It might require the authorised/de-authorised application to be restarted in order to report the most up-to-date status.

Out of interest, when creating new Terminal windows manually using cmd+N, do these open as new windows or new tabs ? What do you prefer ?

#26

The script is granted accessibility. So that try block is just here for when I modify the script and I forget to re-register it or whatever.

Nonetheless, since I upgraded to Monterey, the scripts stopped to even try to keystroke (that’s my best interpretation) since it floats (it’s an “application” script) and just stops reacting. And I reproduced that behavior running it from SD as well.

It does not reach the point where it fails the keystroke and thus, no error message or whatever.

I notice also that (I doubt that’s related, but maybe) since moving to Monterey, the “open .” from Terminal will not put Finder in front of Terminal, like it used to do before Monterey, but it opens it behind and I have to use the application selector to move to Finder. Same for all applications that are “programmatically” launched (ex. the script we’re discussing now, for ex.)

But in the case of the activate command in the script, it does activate Terminal, put it front and send the keystroke command, except that it succeeds sometimes or gets stuck there other times, seemingly at random.

#27

I’ve change the settings to open new windows in tabs a few days ago. I don’t mind either. Terminal is a mess with windows and tabs anyway so I’m not relying on that.

Now that you mention that I could try to create a new window.

#28

I found a way around UI scripting Terminal to open a new tab:

on launchMyCommand(myCommand)
	do shell script "osascript -e 'tell app \"Terminal\" to do script \"\"'"
	
	# Then I ask the newly created window to run the command
	tell application "Terminal"'s front window
		do script myCommand in its last tab
		activate
	end tell
	return
end launchMyCommand

I hope that I’m done with this issue now.

#29

I was going to suggest you did this, because then either of following AppleScript commands can be used to create new tabs in Terminal:

tell application "Terminal"
		activate
		do script ""
end tell

or

tell application "Terminal"
		activate
		open "/path/to/directory"
end tell

The latter will require a specific path, which will then be the $PWD in that new terminal tab. The first, as you’ve already established, can be used to target a specific tab or window if you wish to run a command in an existing tab rather than creating a new one.

So, from your script just above:

shouldn’t need the call out to do shell script, as it should work just with:

tell application "Terminal"
		activate
		set T to do script ""
end tell

The do script return value is a reference to the newly created tab, which you can target with further do script commands:

tell application "Terminal"
		activate
		set T to do script ""
		tell T to do script myCommand
end

Finally, a quick note about Terminal tab and window references: regardless of how many terminal windows are open, and how many tabs in each window are present, every physical tab is in fact a terminal window class object. Every window class object has precisely one, and only one, child tab class object. For example, say you have one physical window with four tabs open: in any other application in the world, ever, the second tab would be referenced as tab 2 of window 1, but in Terminal, it’s tab 1 of window 2. Similarly, the third physical tab is tab 1 of window 3.

It’s been like this at least since High Sierra. In fact, the first change I’ve noticed to this referencing situation is in Monterey, where the number of window references is one greater than the number of physical tabs that are open. I’m not in Monterey right this minute, but if I recall, I think it’s window 2 that usually turns out to be a dummy. Thus, if you have one physical window with four tabs, your references become tab 1 of window 1, tab 1 of window 3, tab 1 of window 4, and tab 1 of window 5. So not at all confusing, or anything.

#30

Thank you so much. And, yes, very confusing :slight_smile: When I explored Terminal to do my thing I could not figure out how all that was working… Btw,how do you get to know all that? Is it documented somewhere?

#31

It’s documented by me, but I’ve not seen any others. I’ve done a fair amount of introspection with most of the common AppleScriptable apps, and this was one example that stood out when enumerating all open windows and tabs of Terminal (Chrome was another one for a short time, where their window id numbers were hideous 32-bit signed integers all less than zero, but perfectly valid. They’ve since reverted them back to regular 8-bit unsigned values).

tell app "Terminal" to get every tab of every window (with a number of open tabs and windows) reveals the odd tab-window relationship in Terminal: your first reaction is that it’s returned too many windows, but then you’ll notice that they all have a single tab 1, and none has a tab 2, and a bit of experimentation confirms these references are true, if a bit peculiar. The more recent quirk I tried to describe regarding the anomalous additional window references that appear during enumeration is something I’m actually still looking into.

I haven’t been using Monterey for that long, and I typically like to do a quick screen of applications between major macOS version changes to identify significant changes on top of anything I’ve already been made aware of. This one isn’t unique by any means, as other apps have reported objects during enumeration that seemingly aren’t there, but this occurrence in Terminal seems inconsistent at first glance. So I just need to isolate the situations that cause anomalous window objects to appear in the list returned of all Terminal windows. I have a feeling it’s to do with attempts by AppleScript to instantiate a new window class object that successfully performed most of what it needs to for this operation, only to then fail at the moment before the physical window ever gets to materialise. I’ll play around with it. I’m actually an iTerm and kitty user myself.