-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Broken output on Windows when using Windows Terminal #16526
Comments
Hmmm, is this a regression? |
Yes, it started to be like this from |
My guess is that this would be caused by #16080, but will double check. If so, it would mean that I'm seeing the same thing locally, so I will look more into it. |
This is weird, but the escape codes seem to be parsed if I change the session's codepage to UTF-8 (maybe because the default code page of 437 has a glyph for It's still buggy with the UTF-8 code page, though (the lines aren't cleared properly):
Some potential quick fixes until this is understood more fully:
|
…them is detected The particular escape code sequences used by the progress bar do not seem to get parsed if the code page is set to 437 (the default code page for a console session), and even if the escape sequences are parsed, the Windows implementation does not render them correctly (it only partially clears the line so the output just ends up mangled). Until this is more understood, we just force the Windows Console APIs to be used on Windows no matter what. See ziglang#16526
This actually seems to be EDIT: I can't seem to get a minimal reproduction outside of the |
Found what's causing it. Commenting out these lines: fixes the output. So, it seems like the spawned |
I see, but please note that on Linux output looks fine. |
Right, Windows has a lot of session-global state involved in its console sessions. Doing something like setting the code page ( Will test more to see if I can narrow down what's changed after EDIT: Seems to be related to running EDIT#2: Can reproduce it by running |
Looks to be a Git for Windows bug:
For whatever reason, it disables the Outputs:
( Because Zig gets the TTY config upfront once, it never realizes that You can workaround it in your pub extern "kernel32" fn SetConsoleMode(in_hConsoleHandle: std.os.windows.HANDLE, in_Mode: std.os.windows.DWORD) callconv(std.os.windows.WINAPI) std.os.windows.BOOL;
// ...
// before the spawnAndWait call
// `git submodule` fails to restore the console mode, so we need to do it manually
// This is a Git for Windows bug: https://github.com/git-for-windows/git/issues/1121#issuecomment-323047927
var stderr_mode: u32 = undefined;
_ = std.os.windows.kernel32.GetConsoleMode(std.io.getStdErr().handle, &stderr_mode);
var stdout_mode: u32 = undefined;
_ = std.os.windows.kernel32.GetConsoleMode(std.io.getStdOut().handle, &stdout_mode);
// ...
// after the spawnAndWait call
_ = SetConsoleMode(std.io.getStdErr().handle, stderr_mode);
_ = SetConsoleMode(std.io.getStdOut().handle, stdout_mode);
// ... EDIT: Another possible workaround is use to - var child = std.ChildProcess.init(&.{ "git", "submodule", "update", "--init", "--remote" }, b.allocator);
+ var child = std.ChildProcess.init(&.{ "cmd", "/c", "git", "submodule", "update", "--init", "--remote" }, b.allocator); |
@michal-z updating my git install to the latest version also seemed to fix this for me without any |
@squeek502 Great info, thanks! I will go with |
Zig Version
0.11.0-dev.4195+7f3fdd2ff
Steps to Reproduce and Observed Behavior
Compiler output looks broken, it prints a message for every step.
Expected Behavior
Output should look like on Linux.
The text was updated successfully, but these errors were encountered: