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
$ winpty -Xallow-non-tty -Xplain <command-line>
Outputs properly; just don’t trust its return code.
Hi there!
We had problems with the unit tests that the output to the console was mangled, lines would miss and the order of the output was not kept properly.
We found that the problem is related to using Python and git-bash in combination. Some users in Stackoverflow also indicate problems with php and git-bash.
The solution (workaround) is to use winpty, but with some special undocumented flags, because git-bash is not a windows console.
We describe the problem/solution as this:
I leave h…
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