`printf "\e[6n"` command causes nushell prompt to output `^[[<row>;<col>R` every time enter is pressed

[emmabastas]

Describe the bug

EDIT: Initially I described this bug in terms of nushell behaviour. In a later comment (what I presume to be) the same bug is exhibited using only reedline

Here is a recording.

I can reproduced this bug in the three terminals I've tested:

1. st 0.9.2 (with some patches)
2. xterm (xterm -version gives XTerm(394))
3. rrxvt-unicode (urxvt) v9.31 - released: 2023-01-02

The bug appears to be independent of terminal used, and is not present with the bash I'm using, so I imagine it's a bug in nushell. If I'm not wrong nushell itself sends \e[6n to the terminal (3 times?) when printing the default prompt. Maybe Nushell expects to receive \e[6n strings from the terminal at very specific times and so when this happens unexpectedly the internal state get's mixed up :thinking: That's just my backseat debugging though..

To me this looks similar to this issue https://github.com/nushell/nushell/issues/13570

Please let me know if you'd like me to try and reproduce with other setups! :-) Or if there is something else I can do to help.

How to reproduce

1. Open terminal
2. Type printf "\e[6n"
3. Press enter
4. Observe that the string ^[[<row>;<col>R flashes on every subsequent enter

Expected behavior

1. Open terminal
2. Type printf "\e[6n"
3. Press enter
4. Observe that ^[[<row>;<col>R has been printed to the terminal by nushell

This is almost the behaviour I get with bash. With bash I get

[myprompt]$ printf "\e[6n"
^[[<n>;<n>R
[myprompt]$ ;1R

i.e. after having pressed enter the shell prints ^[[<n>;<n>R to the terminal but my prompt ends up having the characters ;1R, so if I press enter immediately I get bash: syntax error near unexpected token ';'

Configuration

key	value
version	0.98.0
major	0
minor	98
patch	0
branch
commit_hash
build_os	linux-x86_64
build_target	x86_64-unknown-linux-gnu
rust_version	rustc 1.81.0 (eeb90cda1 2024-09-04) (built from a source tarball)
cargo_version	cargo 1.81.0 (2dbb1af80 2024-08-20)
build_time	1980-01-01 00:00:00 +00:00
build_rust_channel	release
allocator	mimalloc
features	default, sqlite, trash
installed_plugins

[fdncred]

On Windows, I get the response from the terminal. Then I can clear the line and type other commands, hitting enter after each one, without issue. Have you tried on version 100?

[emmabastas]

Huh, I tried to reproduce using version 100 and the bug is still there for me (see screenshot)

I also tested again with xterm and urxvt and it's the same buggy behavior there.

Idk how to proceed.. Wonder if someone else who's also on linux can try recreating?

[emmabastas]

Of note is that when I perform a "Query Device Code" and "Query Device Status" (see https://www2.ccs.neu.edu/research/gpc/VonaUtils/vona/terminal/vtansi.htm), i.e. I type printf "\e[c" and printf "\e[5n" respectively then my terminal (st) reports back and nushell continues operating normally.

[fdncred]

If you're going to query the terminal you should use the new term query command. It's specifically built for this type of thing. However, it's not published yet but you can try a nightly build or clone and build the latest main branch.

❯ term query (ansi size) --terminator 'R' --prefix "\e["
Length: 6 (0x6) bytes | printable whitespace ascii_other non_ascii
00000000:   35 31 3b 32  30 39                                   51;209
❯ term query "\e[c" --terminator 'c' --prefix "\e[" --keep
Length: 34 (0x22) bytes | printable whitespace ascii_other non_ascii
00000000:   1b 5b 3f 36  31 3b 36 3b  37 3b 31 34  3b 32 31 3b   •[?61;6;7;14;21;
00000010:   32 32 3b 32  33 3b 32 34  3b 32 38 3b  33 32 3b 34   22;23;24;28;32;4
00000020:   32 63                                                2c
❯ term query "\e[5n" --prefix "\e[" --terminator 'n' --keep
Length: 4 (0x4) bytes | printable whitespace ascii_other non_ascii
00000000:   1b 5b 30 6e                                          •[0n

[emmabastas]

term query looks neat!

For context I stumbled across this behaviour of nushell when working on my own terminal emulator that I'm writing as a side project. I got this bug simply by running ls using my terminal, which is how I discovered it. Assuming that the ls bug stems from my terminal then this issue we're discussing in this thread is not really a problem for me personally.

[davidsircoin]

Could replicate, with nushell v.100 and gnome terminal version GNOME Terminal 3.44.0 using VTE 0.68.0 +BIDI +GNUTLS +ICU +SYSTEMD

[emmabastas]

I dug around a little more and I managed to produce a similar behavior in the reedline repo. I would guess that the bug observed in nushell stems from reedline, what do you think, should I open an issue in readline and close this issue? (I don't really know how the nushell project is structured)

Details

Steps to reproduce (For unix/linux, not Windows)

1. Figure out which tty the terminal emulator is using by running tty. Outputs something like /dev/pts/<number>
2. Be inside reedline repo with rustc, cargo, etc.
3. carg3o run --example basisc
4. Observe expected behaviour
5. From another terminal do printf "\e[6n" >> /dev/pts/<number>
6. Observe "unexpected behavior" (see recording)

The recording is from when I was testing on st and the "unexpected behaviour" is that I expect that when enter is pressed I get

~/projects/reedline〉
We processed:
~/projects/reedline〉

but instead I get

~/projects/reedline〉
~/projects/reedline〉

i.e. the We processed: string stops showing up. When the prompt is at the botom of the screen it's a new unexpected behaviour, I mostly get

~/projects/reedline〉

We processed:
~/projects/reedline〉

i.e. there's an extra newline, and occasionally I get

~/projects/reedline〉
^[[<n>;<m>R
We processed:
~/projects/reedline〉

I tested with xterm too and it's largely the same but the newline to ^[[<n>;<m>R ratio is different.

[fdncred]

I moved it here to reedline.