Repository navigation
Nodejs STILL sends ANSI escape sequences to dumb terminals. #26187
Description
Activity
As a workaround, I've created a C program to filter out the escape sequences. After compiling, you can invoke the Node REPL like this:
node | noesc#include <stdio.h> #include <ctype.h> void throw_away() { for(int ch = fgetc(stdin); !feof(stdin) && !isalpha(ch); ch = fgetc(stdin)); } main() { setbuf(stdin, NULL); setbuf(stdout, NULL); while(!feof(stdin)) { int ch = fgetc(stdin); if(ch == '\033') throw_away(); else fputc(ch, stdout); } }I can't duplicate this. If the output is a pipe or
TERM=dumbis set, then REPL output is unstyled.What is your stdout connected to? The escape sequences I'm seeing are for positioning the cursor, not styling the text, and they move the cursor to where it already is (just as seen in the original bug report), so if your stdout is a terminal that supports escape sequences there would be no visible effect. The REPL output would look unstyled.
Do you have a reproducible example, preferably without 3rd party modules?
I reproduced the behaviour, it's present when node is running in TTY
.isTTY=truewithTERM='dumb'.There are missing checks in
consoleandrepl. And no direct support for dumb terminals inreadline.I made fix for the issue, with tests for each subsystem.
I added explicit support for dumb terminals in readline(use
_ttyWriteDumb).
WhenTERM='dumb':- it doesn't use any ANSI escape codes for movement and output
- it doesn't use color
- it ignores all special keys except:
escape,returnandctrl-c
My PR: #26261
About supported features of the dumb terminals:
infocmp dumb
wiki:Computer_terminal#Dumb_terminals- added 3 commits that reference this issue
on Mar 5, 2019 - added 3 commits that reference this issue
on Mar 21, 2019
Version:
v12.0.0-nightly201902173fbf55a87c
Platform:
Linux pop-os 4.18.0-14-generic domain: add arguments for the function in domain.run() #15~18.04.1-Ubuntu SMP Mon Jan 14 11:09:26 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Subsystem:
My problem is described here: nodejs/node-v0.x-archive#5344
The only difference is I'm running the latest version of Node in 2019, presumably after patches have been applied that were supposed to have fixed the problem.
I'm running the REPL from the command line in an Emacs
*shell*buffer. I have$NODE_DISABLE_COLORSset to 1, which doesn't matter because the�[3Gescape sequence isn't a color code (those end inm).#2712 doesn't look like it fixes the problem. That seems to just be the implementation of the
$NODE_DISABLE_COLORSoption.