Can you confirm that your cmd.exe shell doesn't have the envvar %TERM% set to anything?

Actually, even with TERM set, I'm still getting colors in both cmd.exe and `git bash`. I'm on windows 10... maybe cmd.exe is different now?

Confirmed - no TERM.

Note also that on my Windows 8 machine I saw it go from working to not working without anything changing except that I ran "gclient" a couple of times in a separate command window.

I have seen this behavior (control characters) on four different Windows machines from three different developers.

actually I take that back: I only see colors in cmd.exe right now (looks like a bug)

I'm seeing the same behavior on Windows 7, 8.1, and 10.

Try running "gclient" a few times and see if it stops working? Dunno.

I've been running gclient all day :D. I'll try running it a bunch of times in the same prompt, but it sounds like voodoo to me.

Voodoo works whether you believe in it or not, just like science.

Here's what I see after running gclient 10 times in a cmd shell :/

Deleted: Capture.PNG 31.1 KB

	Capture.PNG 31.1 KB View Download

git version: 2.7.4.windows.1
depot_tools version: crrev.com/ecd95be01fc6276036287c289c4232d1a9596fa6

What version of depot_tools are you on?

ecd95be01fc6276036287c289c4232d1a9596fa6, https://codereview.chromium.org/1847283003, from Apr 1 22:43:39

Ok, so I think what's happening is that colorama has decided that it should be emitting ANSI color codes. These SHOULD work on windows 10 OOTB (since cmd.exe now supports some ANSI escape codes), but colorama's fallback of using the windows native coloring routines doesn't seem to be kicking in.

If you edit the line in git_cl.py which looks like `colorama.init(...)` to be just `colorama.init()` does that cause coloring to work again?

Wait, you saw this behavior on win10? Now I'm really confused... are you /sure/?

Heh, I think I actually figured this out. Even though cmd doesn't set $TERM, msysgit's bash.exe does... and when you do `git something`, it's running inside of bash. I think I know how to fix this though.

Turns out there's a bunch of madness :)

CL: https://chromiumcodereview.appspot.com/1851283002

So the reason this happened is because I attempted to enable color output for msys bash (aka `git bash`). I figured since TERM isn't defined for cmd, we can just use that as a signal that we're running in a non-cmd terminal emulator. However, when you run `git command` (like `git cl`) it runs `bash /path/to/git-command`, and bash sets TERM in the environment.

I think the CL above detects all the cases.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/tools/depot_tools.git/+/596cd5c95d2a85df1598a72cd211104beb7cf19f

commit 596cd5c95d2a85df1598a72cd211104beb7cf19f
Author: iannucci@chromium.org <iannucci@chromium.org>
Date: Mon Apr 04 21:34:39 2016

Fix coloring madness in depot_tools.

'setup_color' now contains logic to correctly detect:
  * cmd
  * cmd pipe
  * msys bash
  * msys pipe
  * cmd running inside msys bash (git-command)
  * cmd pipe running inside msys bash (git-command > outfile)

R=brucedawson@chromium.org, dnj@chromium.org
BUG= 600049 

Review URL: https://codereview.chromium.org/1851283002

git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@299682 0039d316-1c4b-4281-b951-d872f2087c98

[modify] https://crrev.com/596cd5c95d2a85df1598a72cd211104beb7cf19f/depot-tools-auth.py
[modify] https://crrev.com/596cd5c95d2a85df1598a72cd211104beb7cf19f/gclient.py
[modify] https://crrev.com/596cd5c95d2a85df1598a72cd211104beb7cf19f/git_cl.py
[modify] https://crrev.com/596cd5c95d2a85df1598a72cd211104beb7cf19f/git_common.py
[modify] https://crrev.com/596cd5c95d2a85df1598a72cd211104beb7cf19f/git_map_branches.py
[add] https://crrev.com/596cd5c95d2a85df1598a72cd211104beb7cf19f/setup_color.py

I think this one's in the bag. Going to work on the crash next.