svn commit: r316477 - head/usr.bin/grep

[Andrey Chernov]

On 04.04.2017 16:09, Kyle Evans wrote:
> 
> First, apologies, I must rewind: what did you  mean initially by "We
> don't need to handle internally [...]"
>  -- the second half I understand, but it occurs to me that we should
> already be internally handling \33[m = \33[00m as defined by ANSI.

Of course we must handle (and already handle) both according to ANSI,
but few CPU cycles here, then in another place, yet another, etc. making
big time in sum when CPU does nothing useful but resource eating.

> On Tue, Apr 4, 2017 at 7:37 AM, Andrey Chernov <ache at freebsd.org
> <mailto:ache at freebsd.org>> wrote:
> 
>     IMHO everyday usage by everyone weights much more than occasional
>     regression tests run which can be fixed instead of this place. F.e. we
>     already do a lot of local fixes in the NetBSD regression tests instead
>     of pretending to mimic NetBSD in 100% in the system itself.
> 
> 
> This is where it gets kind of finnicky, and I'll step out and let others
> weigh in -- the test I refer to was specifically written by me
> (https://reviews.freebsd.org/D10112), and it's entirely to make it
> easier for me to check and quantify to others where we're actually
> regressing or improving as I continue fixing things in bsdgrep(1). This
> is easier to do so when we don't have trivial failures due to minor
> formatting differences when they should ultimately be interpreted
> equivalently either way, such as in this case. I expect to be find other
> quirky bugs in gnugrep(1) while reviewing the remaining PRs in Bugzilla,
> and thus expect this to be more important in the months to come.

I see another problem, but it sounds a bit artificially. What if someone
decides to parse grep-colored output and assumes gnu grep only (which is
usual in Linux). I can't determine probability of such situation.
Usually people use generic ANSI parser which understand both cases (f.e.
to convert it to HTML).