is returns true on windows when stdout is piped about atty HOT 11 CLOSED

I just noticed the windows tests are failing. I'm looking into that now. Ill see if I can't figure that out before the end of the week

from atty.

ok. retested with opposite semantics for output streams for appveyor and published new version 0.2.1 which should incorporate the GetStdHandle changes. Thanks so much for your help @retep998 !

from atty.

This is because it is opening $CONOUT which is always the actual console buffer if there is a console attached. What this should do is GetStdHandle to get the current stdout handle and check that.

from atty.

It looks like @retep998's suggestion was implemented in this commit: fdabaef

from atty.

It looks like fdabaef hasn't been published to crates.io yet. @softprops Is there anything blocking updating crates.io?

from atty.

@retep998 I pushed a new version but unfortunately I had to rollback my GetStdHandle approach. So I'm going to leave this open.

Here's some findings

I'm relying soley on appveyor to run my unit tests against various windows targets and they all consistently fail with a 0 return value and a 6 ( invalid handle ) last_error. I ran some tests to compare GetStdHandle against the result of STD_INPUT_HANDLE, STD_OUTPUT_HANDLE, STD_ERROR_HANDLE against the INVALID_HANDLE constant and in all cases that seemed fine.

However when passing in that handle to GetConsoleMode, it would only seem to work for stdin. I did more research and read that GetConsoleScreenBufferInfo was more reliable than GetConsoleMode for output streams, but I still ended up getting a 0 return value with last_error value of 6 ( invalid handle ). This is a little frustrating because it's unclear how a handle that does not resolve to INVALID_HANDLE before being passed into GetConsoleXXX by last error reports it as being invalid. The only thing that I've been able to consistently get my tests to pass is the CONOUT$ approach.

I could use some win expertise here :) The only thing that I think I could be missing is if, for some reason, the appveyor test environment is actually piping its own output

In the mean time I want to leave this issue open until I can confirm the issue is resolved. I don't have an actual win env to test in myself outside of appveyor. I've provided a short testing/debuging guide in my readme https://github.com/softprops/atty#testing. If one of you gets a chance, can you give something similar to that a try and confirm that the output looks correct.

from atty.

Wanted to drop a pr that kept the GetStdHandle approach open to demonstrate my appveyor test failure #6

from atty.

I could use some win expertise here :) The only thing that I think I could be missing is if, for some reason, the appveyor test environment is actually piping its own output

Exactly this. Appveyor redirects all output to a pipe so that it can capture it. GetStdHandle returns a valid handle, but that handle is not a console, so is returning false is correct. If you really want to test is returning true you could probably do FreeConsole and AllocConsole which allocates a new console for the process and GetStdHandle should return handles to that new console.

from atty.

awesome. Thanks @retep998 I'll try and follow up on this tonight. I banged my head against this so hard this weekend I felt like I got a headache :) I wonder why appveyor differs in like that from travis which doesn't seem to do the same.

from atty.

@softprops Thank you for figuring this out!

from atty.

I wonder why appveyor differs in like that from travis which doesn't seem to do the same.

Probably because appveyor is on Windows and travis isn't, and console behavior is quite different between Windows and non-Windows.

from atty.