Repository navigation
regression with tty detection #1459
Description
Activity
I cannot reproduce, what is your terminal emulator, shell, etc.
no-color.org is flawed in that
NO_COLOR=does not operate the same as the variable missing so I have rejected implementing it. there'sPRE_COMMIT_COLORwhich works nearly identical and is documented but that's off topicI can't reproduce in zsh either
The terminal is irrelevant (same with iTerm or native Terminal) but the shell type and configuration is relevant: it will reproduce with zsh only if you add the mentioned script for colorizing the stderr console. That snippet is a subset of https://github.com/cehoffman/dotfiles/blob/master/zsh/config#L171-L193 which I adopted long time ago.
If the
ANSIoutput is to be produced onstdout, clearly the app needs to checksys.stdout.isatty()and not other stream. Same applies to stderr.A simple test of ``pre-commit 1>/dev/null` demonstrates that default stream is stdout, so we cannot really blame stderr stream for breaking stdout output.
In fact there is an even easier way to reproduce wrong assumption:
python3 -c "import sys; print(sys.stderr.isatty())" 2>/dev/nullOnce you redirect stderr to a file, it looses the tty properly, which is fine. Still, what is not fine is that the app stops producing ANSI only stdout.
well we can't pick stdout because it breaks windows, stderr works fine without your configuration so I'd say that's a your-configuration problem
I (effectively) beg to differ as this can easily happen with redirection anywhere. At the same time I do understand that you do no want to break the Windows hack too, so I will try to investigate the subject more in order too see how others sorted the issue.
could maybe use one on one and one on the other?
I've created an issue on git-for-windows: git-for-windows/git#2914
that looks like file output which wouldn't be in color anyway
Reacted by Mateusz A.Is there any way to get the output from pre-commit written to the terminal or somewhere that would preserve the coloration? It's a shame that all the colorization of the output gets lost if committing with the GUI rather than on the command line
pre-commit can't control how external tools render things -- perhaps report your bug against them?
Ah shoot, I was just following a chain of github issues and didn't notice I'd slipped out of VSCode repos and into the pre-commit repo. I'm not quite sure where to mention this but I'll find a better place. Thanks for all your work on pre-commit! It's a fantastic tool.


A recent regression was introduced via #1382 which broke detection on various conditions.
For example, on my MacOS host, only
stdoutandstdinreport True onisatty()whilestderrreports False, even if in reality there is no problem with sending ANSI to stderr.Probably we should rely solely on
stdoutfor the test or to assure that we respect it for each tty.This issue is not happening with lots of people because only few of them use a method to colorize stderr, which apparently is what has a side-effect of marking it as a non tty.
Example of zsh snippet from
~/.zshrcthat does this:Once this runs you no longer gave a tty-enabled stderr.
Vast majority of CLI tools I know are using
sys.stdout.isatty(), the only other exception I know ismypy. https://bixense.com/clicolors/ seems to support that approach too.Regarding the never-ending struggle to control ANSI on/off behavior where each tool invented its own implementation and variables to configure behavior, it seems that someone realized that maybe is time to do something about it https://no-color.org/ :)