Change:
How to reproduce: That test () checks that rustc's behavior with options like is different depending on whether stdout is tty or not. That test uses as stdout and fails when run under MSYS2. cc
Cannot check the behavior on Linux right now, but if nobody complains about failing run-make tests, then is probably considered a tty there. UPD: Yep, is a tty on Linux and rustc refuses to into it.
Does it work with set in For msys2 without pseudoconsole support there's no way to really know if something is a tty or not so we use heuristics based on the pipe name, these may need updated. If msys2 is using the Windows pseudoconsole then it should just work as it should be detected as a normal Windows console handle (unless is special in some other way).
Does it work with set in No, it doesn't help. For msys2 without pseudoconsole support there's no way to really know if something is a tty or not so we use heuristics based on the pipe name, these may need updated I did assume it was some missing heuristic in .
Ah, actually the problem is this check: The trouble is even if is set (which it turns out it is by default now) is still a pipe instead of a pseduoconsole handle. So unless all std handles are redirected, it will return negative.
I created a fix in by simply removing the above code. This decreases the chances of a false negative at the cost of increasing the chances of a false positive. But I think simply inspecting the pipe name is overall the most reliable way to detect an msys2 tty.
Why is a pipe, can that be checked by environment variable?
You'd have to ask msys2 why that is. Maybe it's a bug or maybe there's some reason for it. I don't know. I don't think so.
maybe you know?
Unfortunately I don't know much about Cygwin's internals.
Unfortunately I am not familiar with Rust language. I assumed the rust code looks like following C code. That program prints 1 (TRUE) for all handles in msys2 environment with conpty enabled. With environment variable, that program prints 0 (FALSE) for all handles.
if that program is called then doing the following: prints:
may provide some information about that.
/dev/ptmx is a device for native msys2 (cygwin) programs. I guess you are using native windows rust compiler. In that case, the program built is also native windows program. /dev/ptmx is a tty for native msys2 program, however it is just a pipe for native windows program. So, the result is as the author reported. You can confirm the behaviour with the code: If you compile this using /usr/bin/gcc and run , the result is: however, with /mingw64/bin/gcc, the result is: I do not think there is much meaning to check behaviour with /dev/ptmx for native windows program, because it does not provide any meaningful functions for native windows program.
I am bit curious why a test for native Windows platform runs a command like . Should not that test be excluded in Windows?
Test file is here: On Windows our "run-make" tests use msys2 (or git bash, but same difference) so the Makefile is cross-platform, This particular test is testing that emitting binary data to a tty correctly fails. This is definitely something that should be tested on Windows. I'm not totally sure why is used for this but I'd assume it's so that the tty is independent of the one we're using for normal output (otherwise it would be annoying if the test fails and binary data is actually written to the tty). See also which introduced the test. cc
Yes, that's the purpose of adding such (failure) tests. If I remember correctly, in the test I initially tried but found that the tests would then fail, because stdout was already redirected in the test environment, so the expected error didn't happen. I used because that was the one that worked on all the platforms.

Discussion:
return true; } <del> // At this point, we *could* have a false negative. We can determine that this is a true // negative if we can detect the presence of a console on any of the standard I/O streams. If // another stream has a console, then we know we're in a Windows console and can therefore // trust the negative. for std_handle in [c::STD_INPUT_HANDLE, c::STD_OUTPUT_HANDLE, c::STD_ERROR_HANDLE] { let std_handle = c::GetStdHandle(std_handle); if !std_handle.is_null() && std_handle != handle && c::GetConsoleMode(std_handle, &mut out) != 0 { return false; } } </del> // Otherwise, we fall back to an msys hack to see if we can detect the presence of a pty. msys_tty_on(handle) }