GNU grep: use --color=auto by default

[arrowd]

Summary

GNU grep defaults to --color=auto when --color is passed, but if no flag is given, no coloring applied.
Recent GNU grep in Ubuntu colorises its output by default, so we are following the behaviour there.

Test Plan

grep foo file_with_foo now highlights found substrings.

[arrowd]

[0mp]

gnu/usr.bin/grep/grep.c

1721

You've got style(9) issues.

[0mp]

gnu/usr.bin/grep/grep.c

1721

Actually, this is not really style(9)-compliant file as I look at it now...

Why this if statement had to be moved to a different place?

[arrowd]

That if(color_option == 2) block checks terminal features and enables/disables output coloring based on that.

The problem is that this check is currently located inside command-line handling loop while ((opt = get_nondigit_option (argc, argv, &default_context)) != -1). Thus, it only gets executed if you actually pass --color=something. So, I just moved it out of the loop, so it would be always be executed.

[0mp]

LGTM.

It would be great to update the manual page at the same time.

[arrowd]

In D19888#435371, @0mp wrote:

LGTM.

I don't have src commit bit.

It would be great to update the manual page at the same time.

What should be updated, exactly? The --color option is already documented.

[0mp]

In D19888#436288, @arrowd wrote:

In D19888#435371, @0mp wrote:

It would be great to update the manual page at the same time.

What should be updated, exactly? The --color option is already documented.

The default behavior of --color flag. I am not sure if that's necessary at this point.

Also, I forgot that we are talking about the GNU grep here.

[arrowd]

Then your D20253 was perfectly sensible, why did you discarded it?

[arrowd]

What needs to be done to get this in?

[arrowd]

[arrowd]

Another bump.

[lwhsu]

I think this is good, as we also have --color=auto default in ls(1)

[arrowd]

Does that mean I can commit this myself, despite having commit bit for ports only?

[lwhsu]

In D19888#461338, @arrowd wrote:

Does that mean I can commit this myself, despite having commit bit for ports only?

Sorry for being misunderstanding. I don't things I have enough experience with these codes and I'd like to have more comments. How about asking on -arch or -current list?

[lwhsu]

@kevans I know it's gnugrep not bsdgrep, but could you provide some comments?

[kevans]

In D19888#461345, @lwhsu wrote:

@kevans I know it's gnugrep not bsdgrep, but could you provide some comments?

Hi,

Sorry... admittedly, I've avoided this because color default is a really sensitive topic and I'm still recovering from enabling them by default in ls(1), which isn't fair to @arrowd. I'm again making progress on replacing gnugrep with bsdgrep, and I'd be inclined to ask that we not do this with gnugrep in base and instead flip this switch in bsdgrep. My reasoning here is that I don't trust that the color behavior in base gnugrep (in general buggy as all get-out) is compatible with either ports gnugrep or base bsdgrep, where-as I've put plenty of work into making sure that bsdgrep behavior matches ports gnugrep behavior here. Since I can't enable bsdgrep-as-default in earlier branches due to the regex nightmare, I'd strongly prefer not to go "uncolored in earlier versions of earlier branches" -> "potentially buggy color output in earlier branches" -> "closer color output in newer branches" -> "ports gnugrep color output"

[arrowd]

Just out of curiosity, what's the status of bsdgrep?

[kevans]

In D19888#543583, @arrowd wrote:

Just out of curiosity, what's the status of bsdgrep?

I am sorry that I left you hanging here -- I had planned to push it through right after you asked, but got distracted by shiny objects. To close the loop on this, bsdgrep is now the default in -CURRENT and gnugrep has been removed as of last week.