Instant triggers appear to overfire on previous lines of terminal output
Thanks for filing an issue! Please answer the questions below so I can help you.
- iTerm2 version: 3.2.9
- OS version: MacOS Mojave 10.14.4
- Attach ~/Library/Preferences/com.googlecode.iterm2.plist here (drag-drop from finder into this window) com.googlecode.iterm2.plist
- Attach a debug log, if possible. Instructions at https://iterm2.com/debuglog[debuglog.txt](/uploads/68128df07183a9cdab2e765d3c0636ec/debuglog.txt)
- I have also attached a video capture of the issue, at bottom.
Are you reporting a performance issue, excessive CPU usage, or a hang? Please attach a sample. Instructions at https://gitlab.com/gnachman/iterm2/wikis/HowToSample Are you reporting a crash? Please attach the crash log. Instructions at https://gitlab.com/gnachman/iterm2/wikis/crash-logs Are you reporting excessive memory usage? Please attach a heap analysis: https://gitlab.com/gnachman/iterm2/wikis/heapshot
Detailed steps to reproduce the problem:
- Create trigger:
Report user & host,
- Set up profile triggers: profile1:
- Log into an AWS ec2 instance (specifically I used elastic beanstalk
eb ssh, which may affect the username or prompt) OR simply change your prompt to trigger:
PS1=[ec2-user@0-0-0-0](Note: behavior is slightly different using the second method but the same issue occurs)
- Log out (or change PS1 back to something like
PS1='> '), interact with the terminal
What happened: profile2 correctly triggers when ssh'ing into the host. On disconnect, profile1 correctly triggers, but about 0.4s later profile2 re-triggers. This occurs repeatedly with each new terminal line. I have tried to change the "number of screen lines to match" setting to 1; no difference.
Note: profile2 does not re-trigger if "instant" is unchecked. However, the profile does not trigger when logging in until after the first interactive command is processed, which is not ideal and not the desired behavior.
If the PS1 method is used instead of logging into a different host, then the behavior is slightly different. Specifically, while the prompt contains the trigger match, profile1 will immediately trigger after each command (due to shell integration on the local machine), but the trigger match will override this a split second later and profile2 will re-trigger. This is fine as it still demonstrates the issue when changing the prompt back to something non-triggering.
What should have happened: Upon logging out of the ec2 instance, profile1 should trigger and profile2 should not re-trigger.