Re: [PATCH 4/5] grep: Colorize filename, line number, and separator

From: Michael Witten <mfwitten@gmail.com>
Date: Mar 2, 2010, 06:43 UTC
Message-ID: <4b8cb38b.870fcc0a.7ebc.1a83@mx.google.com>
In-Reply-To: <ca433831003011749h43293f80kd4ec18bd796dea7c@mail.gmail.com>

> Something like [1]?

Ah! Good!

Show 5 quoted lines

>> with `auto' as the default for a plain --color.
>
> By the way, the default should be 'always', not
> 'auto', to be consistent with GNU tools, and to be backwards
> compatible with the old --color behavior.

Well, I've got:

    GNU grep 2.5.4

and the default for a plain `--color' seems to be `auto', whereby colorization is turned on when stdout is attached to a tty capable of color, but turned off otherwise:

    echo t > t

    /bin/grep t t --color              # t is colored red
    /bin/grep t t --color        | cat # t is not colored
    /bin/grep t t --color=always | cat # t is colored

Let's see how the GNU grep source sets up colorization:

    case COLOR_OPTION:
        if(optarg) {
          if(!strcasecmp(optarg, "always") || !strcasecmp(optarg, "yes") ||
             !strcasecmp(optarg, "force"))
            color_option = 1;
          else if(!strcasecmp(optarg, "never") || !strcasecmp(optarg, "no") ||
                  !strcasecmp(optarg, "none"))
            color_option = 0;
          else if(!strcasecmp(optarg, "auto") || !strcasecmp(optarg, "tty") ||
                  !strcasecmp(optarg, "if-tty"))
            color_option = 2;
          else
            show_help = 1;
        } else
          color_option = 2;     /* <--------------- default           */
        /* the rest of this case statement (see below) */

Firstly, note that GNU understands a wide set of option arguments:

    1: always , yes , force
    0: never  , no  , none
    2: auto   , tty , if-tty

Secondly, note that the default mode is that which is selected by auto/tty/if-tty:

    color_option = 2;

However, there's a little code left that specially processes this 'auto' mode to transform it into either 'always' or 'never':

        if(color_option == 2) {
          if(isatty(STDOUT_FILENO) && getenv("TERM") &&
             strcmp(getenv("TERM"), "dumb"))
                  color_option = 1;
          else
            color_option = 0;
        }
        break;

Thus, if stdout is attached to a tty that understands color, then colorization is turned on; otherwise, colorization is turned off.

In my opinion, Git grep should follow GNU grep's conventions, not only to be consistent, but also because they are better.

Show 8 quoted lines

>> Of course, I bet you find colorizing the filenames a nuisance because
>> you don't care to pipe the relevant escape sequences to other
>> commands.
>
> I'm not quite sure what you mean here, but my reason has nothing to do
> with piping.  If the output is entirely in a single color, I would
> prefer that color to be my terminal's default.  The color adds no
> value.

Unfortunately, Git grep interprets a plain `--color' the same way that GNU grep interprets `--color=always', so that the color escape sequences get piped to everything.

    $ cd $clean_repo_for_git_source
    $ grep ':-)' -R . --exclude-dir=.git --color | cut -c 3- > smilies-gnu
    $ git grep --color ':-)' > smilies-git

    $ ls -l smilies*     # Note the size difference
    -rw-r--r-- 1 mfwitten mfwitten 813 Mar  1 05:43 smilies-git
    -rw-r--r-- 1 mfwitten mfwitten 717 Mar  1 05:43 smilies-gnu
    
    $ cat -t smilies-gnu
    Documentation/glossary-content.txt:^IThe list you get with "ls" :-)
    Documentation/technical/pack-heuristics.txt:        have to build up a certain level of gumption first :-)
    Documentation/technical/pack-heuristics.txt:       even realize how much I wasn't realizing :-)
    Documentation/technical/pack-heuristics.txt:        the cases where you might have to wander, don't do that :-)
    Documentation/technical/pack-heuristics.txt:        I'm getting lost in all these orders, let me re-read :-)
    Documentation/technical/pack-heuristics.txt:        can just read what you said there :-)
    Documentation/technical/pack-heuristics.txt:    <njs`> :-)
    Documentation/technical/pack-heuristics.txt:        details on git packs :-)
    
    $ cat -t smilies-git
    Documentation/glossary-content.txt:^IThe list you get with "ls" ^[[31m^[[1m:-)^[[m
    Documentation/technical/pack-heuristics.txt:        have to build up a certain level of gumption first ^[[31m^[[1m:-)^[[m
    Documentation/technical/pack-heuristics.txt:       even realize how much I wasn't realizing ^[[31m^[[1m:-)^[[m
    Documentation/technical/pack-heuristics.txt:        the cases where you might have to wander, don't do that ^[[31m^[[1m:-)^[[m
    Documentation/technical/pack-heuristics.txt:        I'm getting lost in all these orders, let me re-read ^[[31m^[[1m:-)^[[m
    Documentation/technical/pack-heuristics.txt:        can just read what you said there ^[[31m^[[1m:-)^[[m
    Documentation/technical/pack-heuristics.txt:    <njs`> ^[[31m^[[1m:-)^[[m
    Documentation/technical/pack-heuristics.txt:        details on git packs ^[[31m^[[1m:-)^[[m

If you just run a plain `cat smilies-git', your terminal should still render the colorization, as the escape sequences are preserved. This is generally a nuisance because normally it is desirable to lose that information when piping it to places other than the screen.

> If the output is entirely in a single color, I would prefer that
> color to be my terminal's default. The color adds no value.

I would prefer whatever color to which I've become accustomed; the color is also a quick indication of what you're viewing. I usually keep altering the search pattern until I get the right set of matches and THEN issue `--name-only' to get just the paths; when I do that, I expect the output to change just by cutting out the stuff to the right of the paths, but your suggestion would ALSO cause the color to change. In my opinion, that's jarring.

Moreover, with a plain `--color' being interpreted as `--color=auto', I would also have the benefit of piping the output anywhere else and never having to bother with `--no-color' or `--color=never' or just removing `--color'.

In short, I think the GNU strategy is the most intuitive and streamlined approach.

Show 15 quoted lines

>> As a compromise (and perhaps as an improvement), perhaps
>> only the basename of the filename should be colorized when
>> --name-only is used; that way, colorization is still being used
>> to differentiate different data, and the rest of the path is
>> usually not that interesting anyway. However, for consistency,
>> I would still think it wise to colorize the dirname portion
>> with `color.grep.filename', but color the basename portion with
>> `color.grep.match' (as though the basename portion is the text
>> being matched).
>
> Personally, I am not a fan of this, but if it is implemented, it
> should be an option, and should be turned off by default. Instead
> of highlighting the name, it may be better to simply highlight the
> slashes so the reader can more easily parse the path. But still, I
> don't think this is worth the trouble.

The basenames of paths are almost always the most important piece of data. Still, my suggestion is to leave the whole path colorized as usual when colorization is active.

Sincerely, Michael Witten