


The second part feels rather mysterious to me, since in that case termcolor should have been able to correctly set the console mode and have output colored, but it fails somehow? So there is at least another source of problem in the regeneration process somehow. some configure files are changed, as I do during the experiment), and the backend regeneration happens before cargo build, the color disappears as well, even if Popen is used. On the other hand, if the backend is dirty as well (i.e.
#Msys2 ripgrep code#
The code in mozprocess is rather complicated and I failed to follow how the output is handled at all. So it seems clear that, one source of the problem is mozprocess, which somehow invalidate everything. Also, if I forcefully make pass_thru=True in n_process, there is also colored output. If I invoke "mozmake -j8 -s -C objdir binaries" via a simply invoking Popen, on a build where only rust part is dirty, it indeed has the expected colored output. So, cargo, or specifically, termcolor, will change the console mode and make it able to output color.
#Msys2 ripgrep windows 10#
Running this program on my Windows 10 machine prints the colors properly. Stdout = (STD_OUTPUT_HANDLE)Ĭ(stdout, ENABLE_PROCESSED_OUTPUT | ENABLE_VIRTUAL_TERMINAL_PROCESSING) Trying that out I can make it work by calling SetConsoleMode:ĮNABLE_VIRTUAL_TERMINAL_PROCESSING = 0x0004 target(s) in 0.0 secsĪ bit of googling revealed this WSL issue comment: > o,e = subprocess.Popen(, stdout=subprocess.PIPE, stderr=subprocess.PIPE).communicate() I can reproduce this with this little bit of Python: In any event, mach is somehow mangling the escape sequences. If I pipe those through `cat` I get color in 1.20 and no color in 1.19. This seems to have changed in the Rust 1.20 release: We run cargo with `-color=always` when mach's output is a terminal, and it looks like cargo has started outputting ANSI escape codes on Windows now. I think this might be caused by a change in cargo. > VM, which has an older cmd.exe terminal. > As a matter of fact, I just figured it also happens on my old Windows 2012 (In reply to Mike Hommey from comment #1)
