This repository has been archived by the owner. It is now read-only.
Browse files

Default the TERM environment variable suitable for use with less.

By default on windows the TERM environment variable is configured as
'winansi' in git unless previously set. This is not accepted by the default
pager (less) which produces an error message:
 "WARNING: terminal is not fully functional"
Under git-bash TERM is configured by the shell as cygwin which less accepts
and here we configure it as "msys" which also is acceptable to less.

Signed-off-by: Theo Niessink <>
Signed-off-by: Johannes Schindelin <>
Signed-off-by: Pat Thoyts <>
  • Loading branch information...
1 parent eb87085 commit 4d0911dceccf1524a2d6aeb15bc25d9cdb1eb75d Theo Niessink committed with patthoyts Apr 11, 2012
Showing with 1 addition and 0 deletions.
  1. +1 −0 cmd/git.cmd
@@ -10,6 +10,7 @@
@if not exist "%HOME%" @set HOME=%USERPROFILE%
+@if not defined TERM set TERM=msys
@if "%1"=="gui" @goto gui

8 comments on commit 4d0911d

epu replied May 21, 2012

If term is set to dumb, like from strawberry perl install which just broke me, should git also override that? after line 13 where TERM is set.
@if "%TERM%" equ "dumb" set TERM=msys

The .cmd wrappers currently use setlocal, so it shouldn't impact things outside of the scope of the call to this batch.


hvoigt replied May 21, 2012

Could you please describe the reason why you need to have TERM=msys for perl further? You are calling git.cmd from perl? So it seems to be correct if perl is only providing a "dumb" terminal? Please feel free to post a pull request with the commit explaining everything and containing a Signed-off-by line.

epu replied May 21, 2012

I'm not using it from perl, but the windows cmd.exe. An unfortunate side-effect of an application that decided to set TERM globally, is that it broke msysgit's normal behavior. I don't know if this fix is worth it, but I'll write it up.


dscho replied May 22, 2012

@epu from your description it is not at all clear to me 1) what exactly the symptoms of the problem are, 2) how it is happening and 3) how you fixed it. it appears to me that the use of 'less' is inappropriate when started from cmd.exe (which implies git.cmd), so I fail to see how the bug can be triggered. Can you clarify, please?


kblees replied May 22, 2012

@dscho the Strawberry Perl setup sets TERM=dumb globally, which disables color in git.

TERM indicates the capabilities of the current terminal window. We can set this in git bash and cmd because we know that git.exe and all MSYS progs have decent terminal emulation, but setting it globally doesn't make much sense to me.

Additionally, beeing able to set TERM=dumb per window to disable color may come in handy, e.g. when remote controlling git via a dumb ssh/telnet/rsh client. So IMO we shouldn't touch TERM if it is already set by the user.

epu replied May 22, 2012


  1. Worst symtom is that git command line usage stops working smoothly when user does a commit. For example, when TERM is set to 'dumb', EDITOR becomes unset, so committing is difficult without specifying '-m "commit message"' on the command line. The interactive VIM editor is disabled. Other symptoms include other normal git commands printing frequent warnings.

  2. It's happening, like @kblees states. I can undefine TERM manually, but not before having wasted hours figuring out what happened. Other users have run into this, see

  3. I fix it by forcing the git.cmd wrapper to set TERM to something that makes the git command lines work interactively, because it is a windows batch file that can reasonably expect to set TERM to a known state. It already sets TERM to something when it's not defined (instead of detecting it, or assuming the worst possible case of dumb). I could unset it or change it in my windows environment. Apparently that would break Strawberry perl at some point, which I also care about. We could equally point the finger at SB perl authors, and ask them to wrap perl correctly and set TERM privately there. There are links in the google code issue which point to them equally not wanting to handle the issue.

Regarding your comment about the use of less being inappropriate, several git subcommands like 'git log' may elect to use the less pager. For 'git log' it is the default behavior on windows, from the windows cmd.exe shell. I use 'git log' and 'git commit' from the windows cmd.exe shell frequently, so the setting of TERM to something other than 'dumb' when 'dumb' is detected could help other users save time. Even a simple echo statement saying 'TERM is set to dumb' would have saved me hours of time.

@kblees I'm suggesting overriding 'dumb' here, in the cmd wrapper, because we know that msys defaults have reasonable behavior in a dos (cmd.exe) prompt or git bash. We're already setting it for the user and assuming that's what they want, because it makes their life easier. There's a certain amount of ease of use expected. Everything works ok out of the box, and that's why I choose msysgit. It works, and nicely.

Is there a better way to resolve this for windows users, so they're not surprised like I was, when their install breaks because of a 3rd party program?


hvoigt replied May 22, 2012

I think issuing a warning that TERM is set to 'dumb' when starting git.cmd like @epu suggested sounds like a sane solution. Then the user can figure out what he/she wants to do with that information and is not so much surprised. What do other think? @epu how about a patch/pull request for that?

epu replied May 22, 2012

@hvoight That sounds like a safe solution that informs the user, without modifying behavior. I'll find the guidelines for patch/pull and put a request together.

Please sign in to comment.