sql shell: confused cursor positioning when editing a long input that spans multiple terminal lines

[knz]

reported by @petermattis

Describe the problem

When interactively editing a sql query that spans multiple terminal lines, the cursor positioning gets confused.

To Reproduce

TERM=xterm or TERM=xterm-256color using macOS terminal or iterm:

Expected behavior

positioning is correct.

Additional data / screenshots

• the problem does not occur when using a linux terminal e.g. st.
• the problem does not occur on macOS when setting TERM to vt100
• the problem still occurs when logging in from the macOS terminal into a remote linux system
• the problem still occurs when running through tmux
• the problem still occurs when running through mosh

Environment:

crdb 21.2

Jira issue: CRDB-10442

Epic CRDB-22182

[petermattis]

I did some debugging of this today because it still frustrates me. Seems like libedit is just doing something strange. Just before the corruption occurs the line looks like:

root@localhost:26257/management_console_test> select organ from invites where accepted_at is NULL and revoked_at is NULL
 group by

Notice that the first line is exactly 120 characters wide which is exactly the terminal width. I then type an i. In response libedit emits "\r\x1b[59G\x1b[1@i\x1b[120GL \x1b[K\r\x1b[1@L \x1b[A\x1b[60G". Let's break down what these escape codes are doing:

• \r: this moves the cursor back to the start of the line.
• \x1b[59G: this is the column_address terminfo command. It moves the cursor to column 59 on the current line which is where the i will be inserted.
• \x1b[1@i: this is the parm_ich terminfo command which inserts 1 i at the current cursor position, shifting the remainder of the line over by 1. At this point, the screen looks like:

root@localhost:26257/management_console_test> select organi from invites where accepted_at is NULL and revoked_at is NUL
 group by

• \x1b[120G: another column_address command to move the cursor to the last column on the line.
• L : insert L and a space at the current cursor position. This has the effect of overwriting the last L on the line, moving the cursor to the next line, and overwriting the space at the beginning of the line. At this point, the screen looks identical to its previous contents:

root@localhost:26257/management_console_test> select organi from invites where accepted_at is NULL and revoked_at is NUL
 group by

• \x1b[K: This is the clr_eol terminfo command, which clears from the current cursor position to the end of the line. But because we're on the next line at this point, this is what wipes out the line.

root@localhost:26257/management_console_test> select organi from invites where accepted_at is NULL and revoked_at is NUL
 

• \r\x1b[1@L : move the cursor to the beginning of the line (line 2) and insert an L, followed by a space.
• \x1b[A: this is the cursor_up terminfo command, which moves the cursor back up to line 1.
• \x1b[60G: move the cursor to column 60 (of line 2).

I'm not sure what is going on with my terminal or terminfo which is causing this badness. Libedit seems to think that inserting characters at the end of a line won't cause the cursor to move to the next line. It also isn't clear to me why it is trying to insert characters at the end of the line.

I've poked around in the libedit sources to try and understand what is going on. If you want to be scared of some code, take a look at the code in refresh.c:re_update_line.

[petermattis]

Disabling parm_ich, parm_dch, enter_insert_mode, and exit_insert_mode in my terminfo "fixes" the problem by disabling all of the insert-mode intelligence in libedit. This likely makes various term display somewhat slower as entire lines have to be redrawn, yet at least the display is accurate.

Recording this for posterity:

~ infocmp -1L -A /Applications/iTerm\ 2.app/Contents/Resources/terminfo | grep -Ev 'parm_dch|parm_ich|enter_insert_mode|exit_insert_mode' > xterm-256color
~ tic -s xterm-256color
1 entries written to /Users/pmattis/.terminfo