iTerm/Applescript Behavioral Differences - Current Work-Arounds - BugReport
-
iTerm2 version:
3.0.3 -> 3.3.9 -> 3.3.10beta1
-
OS version:
10.15.4 Beta (19E242d)
-
Attach ~/Library/Preferences/com.googlecode.iterm2.plist here (drag-drop from finder into this window)
-
Attach a debug log, if possible.
N/A
-
Are you reporting a performance issue, excessive CPU usage, or a hang?
Unexpected Iterm2/Applescript behavioral differences .... (see below )
-
Are you reporting a crash?
NO
-
Are you reporting excessive memory usage?
NO
Detailed steps to reproduce the problem:
* I have a script - ABashScript - which when run in -StartEnv mode, determines how many copies of itself it needs to run concurrently (each instantiation having a different set of arguments). It generates an Applescript to cause each instantiation to run with their associated arguments in their own tabs. It feeds that generated script to osascript and then exits. For purposes of this report, the number of instantiations and the argument list for each does not change. This was done so as to minimize any challenges that might otherwise arise from such changes.
* Under all scenarios described below, I don't see any errors being reported by osascript.
* Now, consider the following machine generated Applescript (hand edited to protect the innocent).
tell application "iTerm2"
set w to current window
set t to current tab of current window
tell current window
write current session of (create tab with default profile) text "ABashScript [ Argument Set 1 ..... ]
delay 1
write current session of (create tab with default profile) text "ABashScript [ Argument Set 2 ..... ]
delay 1
write current session of (create tab with default profile) text "ABashScript [ Argument Set 3 ..... ]
delay 1
write current session of (create tab with default profile) text "ABashScript [ Argument Set 4 ..... ]
delay 1
write current session of (create tab with default profile) text "ABashScript [ Argument Set 5 ..... ]
delay 1
write current session of (create tab with default profile) text "ABashScript [ Argument Set 6 ..... ]
delay 1
write current session of (create tab with default profile) text "ABashScript [ Argument Set 7 ..... ]
delay 1
write current session of (create tab with default profile) text "ABashScript [ Argument Set 8 ..... ]
delay 1
write current session of (create tab with default profile) text "ABashScript [ Argument Set 9 ..... ]
end tell
tell t
select
end tell
activate
end tell
What happened:
-
In the 3 versions of iTerm under discussion (3.0.3, 3.3.9 and 3.3.10beta1) , all tabs are created - all the time ....
-
In iTerm 3.0.3 both with and without the intervening "delay 1" commands in the script, as each tab opens I observe the ABashScript associated with its tab echoed. Since these tabs open fairly rapidly, I don't actually see the ABashScript start but when I get back to looking at any of the tabs, the script has successfully started in all tabs.
-
In iTerm 3.3.9 (a) without the intervening "delay 1" commands the associated AbashScript is not always echoed and in the case where it is not echoed the ABashScript does not run. Clearing away the tabs and re-running the unmodified (without delay 1 commands ) Applescript several times in a row produces unpredictable results; that is to say, which tabs are initiated with their associated ABBashScript and which aren't - changes unpredictably. It appears to be hit or miss and nothing I've attempted causes the same hit/miss scenario. The good news, in the case where a tab receives its associated ABashScript command, it is receiving the correct command; that is to say, I've not seen a case where, say, tab 4 received tab 3's ABashScript command. (b) When the intervening "delay 1" commands are included in the Applescript, all tabs are initiated with their appropriate ABashScript commands; that is to say, the Applescript above without the "delay 1" commands running in iTerm 3.0.3 and with the "delay 1" commands under 3.3.9 appear to work flawlessly, predictably, and exactly in the same manner.
-
In iTerm 3.3.10beta1 things get much worse. First, whether I include the "delay 1" commands or not, the number of tabs that receive the appropriate ABashScript numbers only - wait for it - ONE (1) - most of the time. It appears to be the case that the first or last tab receives the ABashScript to run. The exception to the aforementioned is when none of the tabs receive their ABashScript to initiate. I've not observed a case where the intervening tabs receive a command to run. Good news, as with 3.3.9, if its the first tab to receive the command to initiate, its always the proper first command. If it's the last tab to receive the command to initiate, it's the correct command. Hereto then, the commands to initiate are not getting lost in the shuffle amongst the tabs.
What should have happened:
IMHO, no matter the version of iTerm, the "delay 1" commands should not be needed, they weren't in 3.0.3 iTerm at any rate. The only reason I even tried intervening "delay 1" commands at all is that when running my environment using Terminal instead of iTerm, the only way the environment comes up properly is to include "delay 1" commands liberally. It was the unpredictable nature using Terminal that caused me to check-out and default to iTerm two years ago. NB: Obviously, the Applescript to drive the "Terminal" environment isn't exactly the same as that above, used for iTerm. The "Terminal" script is more complex, involving key strokes feeding through System Events, etc., etc. Once I got the iTerm model working I've never really looked back - except - when it stopped working and where I looked at the Terminal model for clues as to what to try. My environment is fairly complex and potentially difficult to duplicate. I'd be more than happy to test new version(s) of the iTerm codebase as needed. I only ask that you provide clear instructions on how to configure the tests beyond what I've done above to give you the best, or at least desired, results possible.