Force "git status" to output color on the terminal (inside a script)

EDIT:

I would like to make a recommendation that parsing colors is a generally ill-conceived idea.

Part of why i wanted it was so I can both parse it and pass it along in my own script output. This is... okay, but it would probably be saner to use porcelain or some such and re-build the colored parts myself!

Original question follows.

I like to see color because my scripting is robust enough (so far) to handle the color codes. It does seem like I'm going against the grain here, but I honestly don't see what the big deal is about having to parse stuff like escape codes in scripts. If colors help for interactive use, why wouldn't they help in script use where I might be aggregating data and crunching even more data than I would manually? Wouldn't colors be even more important?

Anyway, I have a neat little shell script I wrote that munges git status output, and i'm just looking to make this script keep the colors intact. My global git config is set so that the lists of changed and untracked files show up in color in the git status. Unfortunately unlike git diff there is no option for forcing color for git status that I can find.

To be abundantly clear, this is the issue: 

$ git status

produces perfect output, but (excerpt from my script follows)

git status | sed "s/^#/\x1b[34m#[0m/"

produces no colored git status output, and you can even see here that I'm explicitly converting the leading hash-characters to blue because it helps highlight the different regions of output from my script.

Does anyone know how to get it to put out the colors? Is there maybe a standard program I can use that can be used as a "fake terminal" STDIN/STDOUT pipe? I am in fact also working on a pty pseudoterminal tool so I could certainly make use of that for this purpose, but it's a rather heavy-handed solution (and not ready for use yet as I haven't finished building it).

17054 次浏览
小开

EDIT:

I would like to make a strong recommendation that parsing colors is a generally ill-conceived idea.

Part of why i wanted it was so I can both parse it and pass it along in my own script output. This is... okay, but it would probably be saner to use porcelain or some such and re-build the colored parts myself!

Original answer follows.

I keep finding answers really quickly after asking questions. Something to do with thinking about a problem long enough to write it out that you formulate better approaches for solving it. Anyway, the solution to this is just 

git config color.status always

I imagine that a general purpose solution involves expect or something pty related to force any programs that require it into thinking they are on a terminal.

小开
最佳答案

To avoid changing your git config, you can enable colour just for the current command by passing a config variable with -c.

For the status command, the variable is color.status:

    git -c color.status=always status | less -REX

For diff, show, log and grep commands, the variable is color.ui:

    git -c color.ui=always diff | less -REX

Note that -c must come before the status or diff argument, and not after.

Alternatively, for diff, show, log and grep commands, you can use --color=always after the command:

    git diff --color=always | less -REX

Note: As Steven said, if you are trying to extract meaningful data, then instead of parsing colours to extract meaning, you can use --porcelain to get more parser-friendly output.

    git status --porcelain | awk ...

Then if you wanted, you could reintroduce colours later.

To get the user's configured colours, you can use git config --get-colour:

    reset_color="$(tput sgr0)"
remote_branch_color="$(git config --get-color color.branch.remote white)"


echo "Pushing to ${remote_branch_color}${branch_name}${reset_color}"

Some more examples here.

小开

I had this same issue when using a git alias that executes a shell command. Apparently the git shell doesn't inherit from the current environment, so it knows nothing about my coloring settings.

In addition to adding the global git color ui setting, I fixed this by making my alias look like below, its the secondary command that requires being told to use colors, as git will by default as of whatever 1.8.x version people have mentioned.

[alias]
ignored = !git ls-files -v|grep --color '^h'

This produces equivalent colorized output now when run as the alias the same as if I just ran the command.

For sed, this other answer appears to work more reliably, use tput. https://unix.stackexchange.com/a/45954


提交答案