问题
In Git Bash on Windows 7, I occasionally have something happen that causes the color coding to fail when running cucumber scenarios or rspec specs.
Occasionally, it is randomly fixed (where randomly == I don't know what I did to cause it to be fixed).
So when I run:
$ bundle exec cucumber features
Or
$ bundle exec rspec spec
instead of seeing this in color:
......
3 scenarios (3 passed)
6 steps (6 passed)
I see something like:
[32m.[0m[32m.[0m[32m.[0m[32m.[0m[32m.[0m[32m.[0m
3 scenarios ([32m3 passed[0m)
6 steps ([32m6 passed[0m)
I know these are the code representations of the colors, but I don't know why it stops displaying the colors nor do I know how to fix it. What am I missing?
Output from git config --list:
core.symlinks=false
core.autocrlf=true
color.diff=auto
pack.packsizelimit=2g
help.format=html
http.sslcainfo=/bin/curl-ca-bundle.crt
sendemail.smtpserver=/bin/msmtp.exe
user.name=John Uhri
user.email= *****
color.branch=auto
color.diff=auto
color.interactive=auto
color.status=auto
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master
回答1:
On windows, git Bash uses the built in terminal which is rolled into the cmd prompt. If you install cygwin you can use the mintty terminal emulator (Installed on the start menu as "Cygwin Terminal").
Why is this important? Because the windows cmd prompt term does not interpret ANSI escape sequences. It uses M$ color control scheme instead. If the program you are using does not switch to this scheme on windows, or go through a filter, then you will see the raw escape characters. Cygwin's mintty console has full support for these codes.
If the colors usually work, this is a bug in cucumber/rspec from porting. Somebody missed a check for windows when printing the colors or something. Until this gets fixed, a work around is the following python script:
#!/usr/bin/env python
# Filter ANSI escapes from stdin to stdout
from __future__ import print_function
from colorama import init
import sys
init()
for line in sys.stdin.readlines():
print(line)
You will need to install the colorama library for this. Then just pipe your output through the script:
$ bundle exec rspec spec | colorFilter.py
回答2:
After a number of fruitless attempts to get some colors on my Windows 7 bash terminals (msysgit with console2), I stumbled on Jason Karns blog 'ANSI color in Windows Shells'.
All I had to do was unzip ansicon.exe to a permanent folder and run via cmd in that folder:
ansicon.exe -i
All bash logs now have colors instead of the [32m or [0m tags, woo!
回答3:
I use @aslakhellesoy's "wac" project. It's a little annoying because you have to remember to pipe your commands through it. But it's the only thing I've seen work.
https://github.com/aslakhellesoy/wac
回答4:
I fixed this with Git For Windows (V2.5.3) running Git within PowerShell (in Window's normal console) by setting three environment variables:
TERM=msysPAGER='"C:\Program Files\Git\usr\bin\less.exe"'(note the double quotes need to be part of the value).- Including
--RAW-CONTROL-CHARSinLESSs value (so with my other preferences:--LONG-PROMPT --no-init --quit-if-one-screen --RAW-CONTROL-CHARS).
回答5:
I have had the same pb, it seems that if you unset the TERM environment variable it works again.
回答6:
Try installing the win32console gem.
gem install win32console
回答7:
Richard's suggestions, even in cmd.exe (not PowerShell), worked for me.
I'm running: Windows 7 (64-bit) and Git-Bash: GNU bash, version 3.1.23(6)-release (i686-pc-msys)
I had to change the PAGER location to match my system.
export PAGER='"C:\Program Files (x86)\Git\bin\less.exe"'
来源：https://stackoverflow.com/questions/5921556/in-git-bash-on-windows-7-colors-display-as-code-when-running-cucumber-or-rspec