Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
emmabastas opened this issue Dec 5, 2024 · 8 comments

Comments

@emmabastas
Copy link

emmabastas commented Dec 5, 2024

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.
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 🤔 That's just my backseat debugging though..

To me this looks similar to this issue nushell/nushell#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
Copy link
Collaborator

fdncred commented Dec 5, 2024

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
Copy link
Author

emmabastas commented Dec 5, 2024

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

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
Copy link
Author

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
Copy link
Collaborator

fdncred commented Dec 5, 2024

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
Copy link
Author

emmabastas commented Dec 5, 2024

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
Copy link

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
Copy link
Author

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)

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 fdncred transferred this issue from nushell/nushell Dec 7, 2024
@fdncred
Copy link
Collaborator

fdncred commented Dec 7, 2024

I moved it here to reedline.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants