Closed acroz closed 6 years ago
After further investigation, I found that the culprit seems to be that the Control Sequence Introducer sent back is '\x9b'
instead of '\x1b['
(ESC + [). This Wikipedia paragraph suggests that for interoperability with Unicode, using the 7-bit compatible C0 sequence '\x1b['
will be more robust than the single character C1 code.
If I change CSI in pyte.control to '\x1b['
, my problem above goes away - both the device attributes and device status requests are sent back into the terminal successfully.
The above PR patches pyte to avoid this issue.
I've been working on adapting the webterm example to work with our terminado replacement, and am encountering an issue when using it with xterm. Below is a Python example which adapts the webterm example to just run
vim
and display the output:This generates the following output:
As you can see, some control characters get written into vim, causing it to enter replace mode and enter some text. These characters are written by pyte, which catches some control characters coming from the terminal output and calls
Screen.report_device_attributes
, which in turn sendsCSI + "?6c"
back into the terminal via thewrite_process_input
method.Comments in the code reference Linux's VT102 terminal emulation code, and indeed if I set
TERM='vt102'
, the problem goes away. Might it be the case that this code should only have an effect when the terminal process the screen is attached to is in a particular mode?For the moment I am avoiding this issue by simply removing the attachment of
write_process_input
back onto the terminal process, but it would be good if anyone can provide feedback on whether this is the right thing to do.Thanks, Andrew