repl: strange behaviour in the last nightlies on Windows #18189

Activity

1. vsemozhetbyt

   added

   replIssues and PRs related to the REPL subsystem.Issues and PRs related to the REPL subsystem.

   windowsIssues and PRs related to the Windows platform.Issues and PRs related to the Windows platform.

   on Jan 16, 2018
2. apapirovski commented on Jan 16, 2018

   

   apapirovski

   on Jan 16, 2018

   Contributor

   More actions

   /cc @addaleax it seems very likely this is related to 8b751f7
3. addaleax commented on Jan 17, 2018

   

   addaleax

   on Jan 17, 2018

   Member

   More actions

   @vsemozhetbyt @apapirovski Thanks, I’ll take a look!
4. addaleax

   added

   fsIssues and PRs related to file-system APIs and the fs module.Issues and PRs related to file-system APIs and the fs module.

   ttyIssues and PRs related to the tty subsystem.Issues and PRs related to the tty subsystem.

   and removed

   replIssues and PRs related to the REPL subsystem.Issues and PRs related to the REPL subsystem.

   on Jan 17, 2018
5. addaleax commented on Jan 17, 2018

   

   addaleax

   on Jan 17, 2018

   Last edited by addaleax

   Member

   More actions

   Fwiw, I cannot reproduce the exact problem as described by you, but printing a simple non-ASCII string like '\xf6' seems to be enough to trigger this issue. :/

   But yes, it seems like this is being triggered by #18019, and in released versions of Node this also doesn't quite work the way I'd expect it to:

   > fs.writeSync(1, 'Ö\n')
   Ö
   3

   I guess that's happening because the default code page isn't expecting UTF-8?

   Thinking a bit harder about it, I think it's okay to just revert the changes to lib/tty.js from that PR. libuv supports blocking uv_try_write()s for TTYs across platforms, and even if that were not the case, nothing terribly bad actually happens. (I'll open a PR with that shortly.)

   ---

   As a side note: We currently actually recommend fs.writeSync(1, ...) in the async_hooks docs as a way to do synchronous logging. If that is broken on Windows we might want to re-think that recommendation and/or just expose process._rawDebug or some other fprintf(stderr, ...) thingy as public API. /cc @AndreasMadsen
6. addaleax

   added a commit that references this issue on Jan 17, 2018

   tty: fix console printing on Windows

   ...

   c2bb5ab
7. vsemozhetbyt commented on Jan 17, 2018

   

   vsemozhetbyt

   on Jan 17, 2018

   Last edited by vsemozhetbyt

   ContributorAuthor

   More actions

   FWIW, changing of a shell code page seems to not fix the issue:

   > chcp 65001
   Active code page: 65001
   
   > node.10.0.0.v8-6.3.20180116.nightly.exe
    [1G [0J>  [3G
   
   > chcp 1252
   Active code page: 1252
   
   > node.10.0.0.v8-6.3.20180116.nightly.exe
   �[1G�[0J> �[3G
   
   > chcp 850
   Active code page: 850
   
   > node.10.0.0.v8-6.3.20180116.nightly.exe
   ←[1G←[0J> ←[3G
   
8. addaleax commented on Jan 17, 2018

   

   addaleax

   on Jan 17, 2018

   Member

   More actions

   @vsemozhetbyt Can you try #18214 and see if you’re still seeing those issues?

   👍React with 👍1Reacted by Vse Mozhe Buty
9. BridgeAR

   added a commit that references this issue on Jan 19, 2018

   tty: fix console printing on Windows

   ...

   ea7400c
10. BridgeAR

    closed this as completedin ea7400con Jan 19, 2018
11. addaleax

    added 2 commits that reference this issue on Feb 26, 2018

    tty: fix console printing on Windows

    ...

    35b0936

    tty: fix console printing on Windows

    ...

    38fd790
12. MayaLekova

    added a commit that references this issue on May 8, 2018

    tty: fix console printing on Windows

    ...

    8221bad
13. MylesBorins

    added a commit that references this issue on Aug 17, 2018

    tty: fix console printing on Windows

    ...

    9fdba04