I am debugging a show glitch that happens within the operation of Basta (Bash Standing Line) on macOS.
At any time when the interrupt arrives to refresh the clock show, the cursor column place doesn’t restore, solely the row place. I.e. the cursor jumps to the leftmost column. That occurs each 15 seconds, which is the replace interval.
When the person continues typing, every thing is okay; the cursor jumps again into the Bash command line on the appropriate spot.
Basta makes use of the ESC 7 and ESC 8 sequences to avoid wasting and restore the cursor place across the replace. This works on quite a few terminals, Gnome Terminal, PuTTY, Xterm, and others.
Sadly, the issue does not reproduce in a small check case comparable to this:
esc=$(printf " 33")
printf "cursor ought to be right here: ${esc}7 <---r${esc}8"
learn
On this check case, we print the <--- arrow after the cursor place after which navigate to the beginning of the road with a carriage return. Lo and behold, the cursor is restored to the anticipated place simply after the right here: and the scripts look ahead to return to be pressed:
Cursor ought to be right here: █<---
So that works high quality. Is there identified some bug in Terminal round this, and in that case, the place is it documented, and what are the circumstances underneath which it occurs and repro steps?
New data: Utilizing the script utility, I captured what’s going to the terminal. If I simply let it sit there, then what occurs each 15 seconds is that this:
...^[8^[[?2004l^M^[[?2004h^[7...
The ^[8 is the epilogue of the previous update, issued by the alarm handler in Basta: that’s the last thing it prints, to restore the cursor position. The ^[7 toward the end is the start of the next update, to save the cursor position. In between, we expect nothing. Yet, Bash does something: ^[[?2004l^M^[[?2004h. These two escape sequences are private ANSI extensions. ?2004l is “turn off bracketed paste mode”, and ?2004h is “turn off bracketed paste mode”. In between is the ^M carriage return that puts the cursor to the start of the line. Bash knows about this because when the user starts typing, some correct cursor movement commands are issued to move to the right spot.
Bottom line, Bash is doing this. But why? Why is Bash fiddling with bracketed paste enabling and disabling terminal escape sequences, just because it received a signal?
The Bash executable is the one from Homebrew, $BASH_VERSION is 5.2.37(1)-release.
More new info: I have confirmed that when Bash has an ALRM trap set and receives that signal, it prints garbage to the terminal. When no trap is set, nothing happens.
The simplest trap we can set which reproduces it is to connect the ALRM signal to the shell null command, which consists of a colon (:):
trap : ALRM
Then if I start a background process which repeatedly sends a SIGALRM to Bash, while Bash sits at the command prompt, Bash repeatedly prints these sequences:
^[[?2004l^M^[[?2004h^[[?2004l^M^[[?2004h^[[?2004l^M^[[?2004h^[[?2004l^M^[[?2004h^[[?2004l^M^[[?2004h^[[?2004l^M^[[?2004h^[[?2004l^M^[[?2004h^[[?2004l^M^[[?2004h^[[?2004l^M^[[?2004h^[[?2004l^M^[[?2004h^[[?2004l^M^[[?2004h^[[?2004l^M^[[?2004h^[[?2004l^M^[[?2004h^[[?2004l^M^[[?2004h^[[?2004l^M^[[?2004h^[[?2004l^M^[[?2004h^[[?2004l^M
If no trap is set for that signal, nothing is printed. But of course, the trap is just the : command which does nothing; the printing is coming from within Bash somewhere.
It likely has nothing to do with MacOS, except that I’ve not seen this before, and I’m seeing it on MacOS using the Homebrew build of Bash.