Output from rebar3 eunit is garbled

[nixxquality]

Environment

Rebar3 report
 version 3.9.1
 generated at 2019-04-02T12:27:34+00:00
=================
Please submit this along with your issue at https://github.com/erlang/rebar3/issues (and feel free to edit out private information, if any)
-----------------
Task: eunit
Entered as:
  eunit
-----------------
Operating System: win32
ERTS: Erlang/OTP 21 [erts-10.3] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1]
Root Directory: c:/Program Files/erl10.3
Library directory: c:/Program Files/erl10.3/lib
-----------------
Loaded Applications:
bbmustache: 1.6.0
certifi: 2.3.1
cf: 0.2.2
common_test: 1.17
compiler: 7.3.2
crypto: 4.4.1
cth_readable: 1.4.3
dialyzer: 3.3.2
edoc: 0.10
erlware_commons: 1.3.1
eunit: 2.3.7
eunit_formatters: 0.5.0
getopt: 1.0.1
hipe: 3.18.3
inets: 7.0.6
kernel: 6.3
providers: 1.7.0
public_key: 1.6.5
relx: 3.29.0
sasl: 3.3
snmp: 5.2.12
ssl_verify_fun: 1.1.3
stdlib: 3.8
syntax_tools: 2.1.7
tools: 3.1

-----------------
Escript path: d:/Programs/bin/rebar3
Providers:
  app_discovery as clean compile compile cover ct deps dialyzer do edoc escriptize eunit get-deps help install install_deps list lock new path pkgs release relup report repos shell state tar tree unlock update upgrade upgrade upgrade version xref 

This problem seems to happen in every rebar3 project I try.

Current behaviour

I am running rebar3 eunit in a PowerShell terminal inside VS Code, but it happens even when running in a flat cmd.exe. Here it is running with DEBUG=1:

===> Expanded command sequence to be run: [{default,app_discovery},
                                           {default,install_deps},
                                           {default,lock},
                                           {default,eunit}]
===> Provider: {default,app_discovery}
===> Provider: {default,install_deps}
===> Verifying dependencies...
===> Provider: {default,lock}
===> Provider: {default,eunit}
===> run_hooks("c:/Users/Linus/Documents/Code/discord", pre_hooks, compile) -> no hooks defined

===> sh info:
    cwd: "c:/Users/Linus/Documents/Code/discord"
    cmd: cmd /c mklink /j "c:\\Users\\Linus\\Documents\\Code\\discord\\_build\\test\\lib\\discord\\src" "c:\\Users\\Linus\\Documents\\Code\\discord\\src"

===>    opts: [{use_stdout,false},return_on_error]

===> Port Cmd: cmd /q /c cmd /c mklink /j "c:\\Users\\Linus\\Documents\\Code\\discord\\_build\\test\\lib\\discord\\src" "c:\\Users\\Linus\\Documents\\Code\\discord\\src"
Port Opts: [exit_status,{line,16384},use_stdio,stderr_to_stdout,hide,eof]

===> Compiling discord
===> run_hooks("c:/Users/Linus/Documents/Code/discord", pre_hooks, compile) -> no hooks defined

===> run_hooks("c:/Users/Linus/Documents/Code/discord", pre_hooks, erlc_compile) -> no hooks defined

===> erlopts [{d,'EUNIT'},debug_info,{d,'TEST'}]
===> files to compile ["c:/Users/Linus/Documents/Code/discord/src/handler.erl",
                       "c:/Users/Linus/Documents/Code/discord/src/discord_sup.erl",
                       "c:/Users/Linus/Documents/Code/discord/src/discord_app.erl"]
===> erlopts [{i,"c:/Users/Linus/Documents/Code/discord/src"},
              {d,'EUNIT'},
              debug_info,
              {d,'TEST'}]
===> files to compile ["c:/Users/Linus/Documents/Code/discord/test/handler_test.erl"]
===> run_hooks("c:/Users/Linus/Documents/Code/discord", post_hooks, erlc_compile) -> no hooks defined

===> run_hooks("c:/Users/Linus/Documents/Code/discord", pre_hooks, app_compile) -> no hooks defined

===> run_hooks("c:/Users/Linus/Documents/Code/discord", post_hooks, app_compile) -> no hooks defined

===> run_hooks("c:/Users/Linus/Documents/Code/discord", post_hooks, compile) -> no hooks defined

===> run_hooks("c:/Users/Linus/Documents/Code/discord", post_hooks, compile) -> no hooks defined

===> Performing EUnit tests...
===> run_hooks("c:/Users/Linus/Documents/Code/discord", pre_hooks, eunit) -> no hooks defined

===> run_hooks("c:/Users/Linus/Documents/Code/discord", pre_hooks, eunit) -> no hooks defined

===> eunit_tests [{application,discord},{module,handler_test}]
===> eunit_opts  [no_tty,{report,{eunit_progress,[colored,profile]}}]
.....................

Top 10 slowest tests (0.000 seconds, 0.0% of total time):
  handler_test:simple/1:49
    0.000 seconds
  handler_test:custom_timeout_kill/1:140
    0.000 seconds
  handler_test:unregister/1:225
    0.000 seconds
  handler_test:nonce/1:75
    0.000 seconds
  handler_test:timeout_kill/1:116
    0.000 seconds
  handler_test:continue/1:185
    0.000 seconds
  handler_test:interrupt/1:161
    0.000 seconds
  handler_test:custom_timeout_kill/1:141
    0.000 seconds
  handler_test:multiple_events/1:206
    0.000 seconds
  handler_test:continue/1:186
    0.000 seconds

Finished in 2.141 seconds
21 tests, 0 failures
===> run_hooks("c:/Users/Linus/Documents/Code/discord", post_hooks, eunit) -> no hooks defined

===> run_hooks("c:/Users/Linus/Documents/Code/discord", post_hooks, eunit) -> no hooks defined

Expected behaviour

None of the output from eunit seems to be handled properly, as all the tests are listed as taking 0.000 seconds. The output is also garbled up with those broken color codes (at least, that's what I assume they are).

[ferd]

a PR was just merged to drop the time output by default. The fix for color-coding needs to be brought in the eunit formatter library so that it can detect whether the shell supports color or not. Rebar3 does so, but not the eunit formatter it installs by default

[filmor]

I think this is a bug in Erlang that I haven't been able to pin down. It uses some hackery to interact with the Windows terminal, but nowadays that is not required (and actually broken). You can see this by running in a Git bash, configured to use conhost instead of the msys terminal. When executing ./rebar3 eunit the output will be garbled, even though conhost nowadays (on Windows 10) supports VT100 escapes, as Erlang seems to inject some broken characters. However, piping the output as ./rebar3 eunit | cat works.

[ferd]

We do some general detection to know if stuff requires to be output or not. It's possible that we properly realize that piping to cat won't support color but not for the rest. Otherwise, as you said, if it's supposed to support VT100 escapes and somehow can't then we have a weird problem where we might have to disable more color than we would otherwise :/

[filmor]

Oh no, piping through cat doesn't block the colours, they show in that case properly.

[ferd]

Oh okay, yeah there's something weird then.