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.
Details
- Reviewers
0mp kevans avg - Group Reviewers
Contributor Reviews (src) Src Committers
grep foo file_with_foo now highlights found substrings.
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 23642 Build 22624: arc lint + arc unit
Event Timeline
gnu/usr.bin/grep/grep.c | ||
---|---|---|
1721 | You've got style(9) issues. |
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? |
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.
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.
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.
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?
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"
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.