0

Question

I want git to automatically colorize the output when it is going to a device that can handle color and not colorize it when it cannot. How would one do this?

Background

I sometimes develop code for older machines using the machines themselves. Some of them can handle ANSI color and some of them cannot. On UNIX systems we used to have a database called TERMINFO which listed capabilities of each terminal. It was easy to tell if a terminal supported color by checking the colors capability. If it was -1, then a program should definitely not send ANSI color sequences.

$ tput colors
-1

Ideally, git would use TERMINFO to automatically detect if ANSI color sequences are appropriate. But it doesn't and checks only isatty(). I suspect it is not a high priority for the git developers to add TERMINFO support, so I'm looking for any workaround that will give the same functionality.

I already know how to disable git color using git config and that is not what I'm asking. I want it to only be disabled when I log in from a terminal that does not support ANSI colors, such as a Digital VT340.

I also have already seen the GIT_CONFIG_PARAMETERS="'color.ui=never'" environment variable, but according to @bk2204 and @torek, that variable is going to disappear soon.

Matt
  • 12,848
  • 2
  • 31
  • 53
hackerb9
  • 1,545
  • 13
  • 14
  • 1
    I saw, on the mailing list, that someone was looking into using terminfo from Git. Not sure what *status* that had. Note that the thing that's going away is the `GIT_CONFIG_PARAMETERS` knob, not the `color.ui` knob, but manually tweaking the `color.ui` knob every time you log in might be annoying. You can probably automatically tweak it. – torek Nov 09 '21 at 08:10
  • Thanks, @torek, I sure hope git someday is able to use terminfo. `GIT_CONFIG_PARAMETERS` may be a kludge, but git does not seem to provide any other way to set parameters per _process_ rather than per user. – hackerb9 Nov 10 '21 at 22:21

1 Answers1

1

Variant 1: a shell function in your ~/.bashrc:

if [ `tput colors` -lt 2 ]; then
    git() {command git -c color.ui=never "$@"; }
fi

The disadvantage is it cannot be used in shell scripts. I.e. if you run a shell script git will try to use colors anyway. So Variant 2: a shell script:

#! /bin/sh
if [ `tput colors` -ge 2 ]; then
    exec /usr/bin/git "$@"
else
    exec /usr/bin/git -c color.ui=never "$@"
fi

Name the script git, make it executable and put in a directory that precede /usr/bin in $PATH. For example I have PATH that starts with $HOME/bin:$HOME/.local/bin:/usr/local/bin:/usr/bin:…; I put personal scripts into $HOME/bin and system-wide scripts into /usr/local/bin

To make things simpler you could name the script something like gitc, remove /usr/bin/ and train your fingers to type gitc instead of git. Then you can put the script anywhere.

phd
  • 82,685
  • 13
  • 120
  • 165
  • Good idea, but it doesn't quite work. `if TERM=vt100 tput colors; then echo yup; fi` prints "-1" and "yup". Also, wouldn't an alias be cleaner? Maybe something like `[[ $(tput colors) -le 0 ]] && alias git="git -c color.ui=never"` – hackerb9 Nov 10 '21 at 22:32
  • @hackerb9 Shell aliases and shell functions do not propagate to subprocesses, i.e. shell scripts. – phd Nov 10 '21 at 22:36
  • (I mean, an alias would be simpler than Option 1, a shell function. Of course, if one were scripting `git`, one would still need to use Option 2, a shell script, ) – hackerb9 Nov 10 '21 at 22:37
  • 2
    Looks like `tput colors` just prints the `Co#` / `colors` numeric value, which is -1 when unset, so you need to test the output rather than the status. (Oddly, on my FreeBSD box, I can't get it not to claim 80. I wonder if it's using columns instead of colors...? Aha, yes, it is: `tput Co` prints the `Co#` value.) – torek Nov 10 '21 at 23:20