Repository navigation
Newlines missing carriage returns in REPL, util.inspect() output #7954
Description
Activity
Userland is encouraged to use
os.EOLinstead of hardcoded\nor\r\nfor improved portability.Why not use that in Node.js core libraries?
console,repl,utiletc.Well as I said, for some reason
\nis not enough for Linux with my custom stream (soos.EOLwould not help), I'm not sure why and I haven't really dug into the issue to find out why. Local REPLs work just fine though.AFAIK using
\r\neverywhere should not be a problem, even on non-Windows platforms, and it ensures that the output is displayed correctly.I will resolve this issue :)
Reacted by James M Snell and Anna HenningsenI'm not sure why and I haven't really dug into the issue to find out why.
So, changing core lib to use
\r\nmasks the real issue. Maybe test case could be created?AFAIK using \r\n everywhere should not be a problem, even on non-Windows platforms, and it ensures that the output is displayed correctly.
I agree with that. I use
\r\nuniversally just to be sure.I'm not sure how you could create a test case to check for visual layout. I think about the best you could do is just to have a test that checks that only
\r\nexists in the output and not just\n.Yep, I will create a pull request ASAP 😄
- added a commit that references this issue
on Aug 15, 2016
I noticed that the
replmodule andutil.inspect()only write\nand not\r\nin their output.readlinehowever consistently writes\r\nto its output.This seemingly causes output problems with custom REPLs with custom output streams. I'm not exactly sure why this is a problem though, since the output streams eventually reach a (Linux) terminal. The current workaround I have is to create a newline conversion stream (that inserts carriage returns) that then pipes to my actual output stream. However, I'd prefer not to have to use this workaround forever.
This should just be a matter of changing the relevant instances of
\nto\r\ninlib/repl.jsandlib/util.js.