Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Colorama not working with Git Bash (mintty): colors should not be stripped #224

Open
Delgan opened this issue Jun 14, 2019 · 12 comments · May be fixed by #226
Open

Colorama not working with Git Bash (mintty): colors should not be stripped #224

Delgan opened this issue Jun 14, 2019 · 12 comments · May be fixed by #226

Comments

@Delgan
Copy link
Contributor

Delgan commented Jun 14, 2019

Hi.

Did you noticed that colorama was not working on Git Bash for Windows?

Steps to reproduce is quite straightfoward: on Windows, run get-bash.exe, start the Python interpreter with python -i, import colorama and then call init(), finally you will see that print("\033[31m" "some text" "\033[0m") strip ansi codes but doesn't color text.

This is related to mintty not supporting WinAPI calls. Ansi code are well supported in this terminal emulator and should not be replaced.

Do you think there is a way to automaically detect such environment?

@Delgan Delgan changed the title Colorama not working with Git Bash (mintty): colors should not be stripped Colorama not working with Git Bash (mintty): colors should not be strip Jun 14, 2019
@Delgan Delgan changed the title Colorama not working with Git Bash (mintty): colors should not be strip Colorama not working with Git Bash (mintty): colors should not be stripped Jun 14, 2019
@SSE4 SSE4 linked a pull request Aug 5, 2019 that will close this issue
@eine
Copy link

eine commented Sep 10, 2019

Hi @Delgan! I tried to reproduce this issue, but it seems to be working fine here:

# pip3 list | grep colorama
colorama                      0.4.1

# python -i
Python 3.7.4 (default, Jul 11 2019, 09:35:14)
[GCC 9.1.0] on msys
Type "help", "copyright", "credits" or "license" for more information.
>>> from colorama import init
>>> init()
>>> print("\033[31m" "some text" "\033[0m")
some text
>>>

# uname -a
MSYS_NT-10.0-18362 DESKTOP 3.0.7-338.x86_64 2019-07-11 10:58 UTC x86_64 Msys

some text is red.

@Delgan
Copy link
Contributor Author

Delgan commented Sep 11, 2019

Hey @1138-4eb. :)

Could this be because I'm using the full "MINGW" emulator, while you are using the minimalist "MSYS"? I'm not sure of why your git-bash.exe and mine are different. 😕

1568240212-image2

@eine
Copy link

eine commented Sep 12, 2019

I'd say that both of us are using the same MSYS/MINGW shell (no matter MSYS, MINGW64 or MINGW32). I installed it with http://repo.msys2.org/distrib/x86_64/msys2-x86_64-20190524.exe. However, environments are not exactly the same:

  • Your version is 2.11.2 2018-11-10. Mine is 3.0.7 2019-07-11. This is probably because you didn't execute pacman -Syu recently. It should not be relevant, tho.
  • I installed Python through pacman. I think you installed it with binaries/tarballs from https://www.python.org/downloads/release/python-374/. That's why mine says on msys and yours on win32.

FTR, I tried the snippet on cmd and powershell. Both of them use Python from C:\msys64\usr\bin, because it is available in the PATH. On both of them colours are properly shown.

Therefore, I think that this might be an issue when Python is installed 'natively'. Did you try with cmd and/or powerhsell?

@Delgan
Copy link
Contributor Author

Delgan commented Sep 13, 2019

You are correct, I installed Python using the binaries on python.org. colorama works fine with bash and powershell. As discussed, it only fails when invoked from git-bash.exe which I downloaded as a PortableGit: https://git-scm.com/download/win. I do not have access to the pacman command. 😕

I think you are right, it works fine for you because MINGW64 uses its own Python installation, while in my case it uses the one from Windows.

@eine
Copy link

eine commented Sep 13, 2019

colorama works fine with bash and powershell.

I wonder where is that bash coming from. Is it an alias provided by powershell? Is it WSL? It can't be git-bash.exe, and you don't have MSYS2 neither.

As discussed, it only fails when invoked from git-bash.exe which I downloaded as a PortableGit: https://git-scm.com/download/win. I do not have access to the pacman command. 😕

You don't have pacman because git-bash.exe is an stripped down distribution which is expected to run git only. See https://stackoverflow.com/questions/25019057/how-are-msys-msys2-and-msysgit-related-to-each-other

If you switch from 'Git for Windows' to MSYS2, you can install pacman -S git and you will feel little to no difference. MSYS2 is quite heavier, tho. My C:\msys64 takes 9GB (I have Python, gcc, etc. installed there).

I think you are right, it works fine for you because MINGW64 uses its own Python installation, while in my case it uses the one from Windows.

I think that the last cases to try are the command prompt and MSYS2 with a non-mingw Python installation. Did you try the former?

Ref VUnit/vunit#539

@Delgan
Copy link
Contributor Author

Delgan commented Sep 13, 2019

@1138-4eb Oups, sorry, you wrote "bash" but my brain read "cmd". Of course, I could not and I did not test with bash.

So, I tried to run my Windows Python from MSYS2 and the result was the same, no colors:

1568379159-image

@Delgan
Copy link
Contributor Author

Delgan commented Dec 1, 2019

@1138-4eb Both solutions work! I think one may solve this by checking for the "TERM" environment variable in addition to "PYCHARM_HOSTED".

@charlesbaynham
Copy link

#226 worked for me too!

@jyotsnarupaliya
Copy link

What did you set the value of the environment variable "TERM" to be?
What is the value of the variable "PYCHARM_HOSTED"?

@Delgan
Copy link
Contributor Author

Delgan commented Jul 31, 2021

@jyotsnarupaliya At the time I tried, "PYCHARM_HOSTED" was probably not set as I was testing from the command line. But it can be set to "1" as a workaround to enable colors:

if 'PYCHARM_HOSTED' in os.environ:
if stream is not None and (stream is sys.__stdout__ or stream is sys.__stderr__):
return True

The "TERM" environment variable is not checked by colorama, but it could have been used to detect bash-like tools that support ansi codes on Windows (like git-bash.exe).

@louiscaron
Copy link

I stumbled accross this issue as well, is there a long term solution planned?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants