Travis output not a TTY on Windows builders

Hello,

I am trying to run some tests on a command-line tool which decides whether to show color or not based on the environment it’s running in (when the output is being piped or is generally not a TTY - colors are omitted).

What did you expect?
Running commands under cmd / ps they be recognized as TTYs

What happened?
The tests detect stdout as a non-TTY stream.

Additional information

1 Like

Checking this locally in Git Bash gives the same result:

MINGW64 ~
$ python -c 'import sys,os; print os.isatty(sys.stdout.fileno())'
False

So this is Git Bash’s (or rather, the underlying MinGW64’s) problem.

https://stackoverflow.com/questions/40912072/git-for-windows-mintty-sys-stdout-isatty-returns-false suggests that this can be worked around by running the command via winpty:

MINGW64 ~
$ winpty python -c 'import sys,os; print os.isatty(sys.stdout.fileno())'
True
1 Like

I tried a bunch of different stuff (see CI file) but I could not get winpty to work on the CI server (works fine locally).

This is an issue with winpty. It requires stdin to be a terminal. There’s no fix as of this writing.

There’s a pull request that claims to add a “pipe mode”. Maybe it could be used.

1 Like

:bulb: $ winpty -Xallow-non-tty -Xplain <command-line>

Outputs properly; just don’t trust its return code.

1 Like

Thank you very much, @veganaiZe!

The flags enable a proper TTY (as seen in the tests and the CI).

Marking the thread as RESOLVED.

1 Like