Date: Tue, 4 Apr 2017 08:41:26 -0500 From: Kyle Evans <kevans91@ksu.edu> To: Andrey Chernov <ache@freebsd.org> Cc: <svn-src-head@freebsd.org>, <svn-src-all@freebsd.org>, <src-committers@freebsd.org>, Ed Maste <emaste@freebsd.org> Subject: Re: svn commit: r316477 - head/usr.bin/grep Message-ID: <CACNAnaF1zNecNv=arRHU5GyrsMZb0dXdAJF8V3Ked7mFyPyhRQ@mail.gmail.com> In-Reply-To: <fad8a2a2-b534-f040-8a1b-c94501937ead@freebsd.org> References: <201704032316.v33NGpbo037305@repo.freebsd.org> <4ceb1a18-3a72-c0e3-b2e2-f71d687cd153@freebsd.org> <CACNAnaGMv0WGO0MjnJwrYTdZhutoU7qPbzkiCS2zi2wnCKV=ZQ@mail.gmail.com> <9018c8db-2a89-c8b2-750b-fe11ac08333f@freebsd.org> <CACNAnaH3LQZZ03gDE6DDAGrKQSmbWo3m=e5h247LpxmbkB74TQ@mail.gmail.com> <fad8a2a2-b534-f040-8a1b-c94501937ead@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 4, 2017 at 8:19 AM, Andrey Chernov <ache@freebsd.org> wrote: > 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. I'm omitting a response to this due to the previously mentioned "letting others weigh in," but I do see where you're coming from. =) 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). I agree that this sounds like an artificially conceived situation. On the other hand, we've seen a lot of people make *a lot* of bad assumptions biased towards Linux over in ports. I would hope that the probability of one relying on this exact output to be really really really really close to 0%. Upon further review, newer versions of GNU grep(1) drop the explicit '00' and add the \33[K dropped in this commit a few lines above the mentioned one. In that case, we might as well revert those two lines and consider this an improvement. I guess it depends on the overall outlook of the tests, though -- should we introduce more tests that fail by default as they go in, or adapt similar (not strictly buggy, but not ideal) behavior to start with and then improve after we can grant bsdgrep(1) replacement status?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaF1zNecNv=arRHU5GyrsMZb0dXdAJF8V3Ked7mFyPyhRQ>