Do you have CLE enabled? Do you normally use CLE? Or readline?
An error that I made below is that I said the command is that the ESC [
pl;pc R command sets the cursor position. That is wrong. It reports
the cursor position in response to ESC [ 6 n get cursor command.
CLE uses the get cursor command (apps/system/cle/cle.c):
#define VT100_SETCURSOR {ASCII_ESC, '[', '?', '1', 'l'} /* Set
cursor key to cursor */
It is should be the host responding with the cursor position report:
#define VT100_CURSORPOSAT {ASCII_ESC, '[', (v), ';', (h), 'R'}
/* Response: cursor is at v,h */
I don't know why this is showing up on the NSH console. It should be
invisible. That is a bug.
On 2/10/2023 2:42 PM, Gregory Nutt wrote:
On 2/10/2023 2:24 PM, Nathan Hartman wrote:
I think so. I'm using Konsole and I'm pretty sure this worked before.
What's surprising is that the board boots fine, finds its IP address
through DHCP, prints the NSH title and prompt... only then does it get
messed up. ...
That is the point in time when the first VT100 commands: ^[[62;6R.
NOTE that NSH reports "
Escape character is '^]'.
which is incorrect. Escape is ^[. So ^[[ is Escape-'[' as it is for
all VT100 commands.
The particular VT100 command you are looking sets the cursor to like
62 column 6 (column 6 is just after the five character "nsh> "):
ESC [ pl;pc R report - cursor at line pl, & column pc
... It consistently printed the same junk except once, when it
printed ^[[7;6R instead. ...
This sets the cursor to like 7 column 6.
... If I were using a serial connection I'd look into
the baud rate and line settings but this is using the network, which
appears to be working. I don't know what's going on but I wonder if it's
corruption from something unrelated in the firmware or perhaps a recently
introduced bug.
I don't believe that there is any problem with NSH or the
communication. It all looks fine to me.
I still think the problem is on your host side. Perhaps Konsole does
not have VT100 enabled? Or perhaps it is echoing the VT100 command input?
