From owner-svn-src-head@freebsd.org Tue Apr 4 13:19:22 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 90CA2D2D4E3 for ; Tue, 4 Apr 2017 13:19:22 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f67.google.com (mail-lf0-f67.google.com [209.85.215.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2C020CCD for ; Tue, 4 Apr 2017 13:19:22 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f67.google.com with SMTP id r36so15545535lfi.0 for ; Tue, 04 Apr 2017 06:19:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=SF3xAWBJrZ4A/35OH7O+OIj8Niz6w81xFybrAu0Yi4U=; b=uYyc46WMsDQu4tK8gLohqleZbdcl0g32EplMgIfYhcHIcq93Erru2hOtfP9ckRTBPM hlfkId0+TM5qYsvd7YZqaqH1eetFf3b8pcZ5SU0WfbkU/SGy9LjVDIKVuPK6Bc2CLFXn ZeQZyvTNOyHrGgjhFtEFxdJlNirsTJBJXu6qwfKC6vJZ8Hf+IhKyIPo1T2OMJXZ6Eed3 LLTTcChVGpj8glHaorAQSHjjBWotuCIrZ773Kt6WEZgNUG0MCOBt6kVAB8hG0Z2Vi03H kZeCF/zR8GJiii7U73uaFhusYjhap1Zt+6j1uz8dLDHUyCLEYOtT2Kz6xUyL1Ft++14T 1UlA== X-Gm-Message-State: AFeK/H2d1lOll3Fo1QBwi29REzLW2sp460uWRar8lgSYtjRQ2z4FDzV9Uuhqw4VLBe+Dww== X-Received: by 10.25.44.16 with SMTP id s16mr7429404lfs.6.1491311959507; Tue, 04 Apr 2017 06:19:19 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id 191sm3120019lfz.44.2017.04.04.06.19.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 06:19:19 -0700 (PDT) Subject: Re: svn commit: r316477 - head/usr.bin/grep To: Kyle Evans References: <201704032316.v33NGpbo037305@repo.freebsd.org> <4ceb1a18-3a72-c0e3-b2e2-f71d687cd153@freebsd.org> <9018c8db-2a89-c8b2-750b-fe11ac08333f@freebsd.org> Cc: Ed Maste , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org From: Andrey Chernov Message-ID: Date: Tue, 4 Apr 2017 16:19:18 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 13:19:22 -0000 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 > 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).