From owner-svn-src-all@freebsd.org Tue Apr 4 13:19:22 2017 Return-Path: Delivered-To: svn-src-all@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 94DDED2D4E4 for ; Tue, 4 Apr 2017 13:19:22 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f68.google.com (mail-lf0-f68.google.com [209.85.215.68]) (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 435F7CCF for ; Tue, 4 Apr 2017 13:19:22 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f68.google.com with SMTP id n78so15493214lfi.3 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=HMRvaxJiHCnYL6+n2trz1F605xRz+t3jhES9grN9BBZCCjEuT0RaKAn/i/aDM4eTNW BcpkY0QT+n0fBPt5ficXgv4da4XzzTSQH6P3IKi1KJqJPenQp63B5jilltflNvb0tx0a LFS+9TYjgFrVVHd+vObFDTOS0gQ3bRl9GpyiUKtJZyAdJU5TIv2/N7fvTQsfUq5dbPps 9jwTUgGcUTlVW4MESYiHEVzxess+t2p1pPke92xub1XM6jqvOTo1kClTQa8++TCKzsQl 5MtTl9+SXvK19mopbJksqXNS49ufi8EdoGOpTqogDxgoAtRHFvOYjFbMW8gDoRrUqDoT STbg== X-Gm-Message-State: AFeK/H3Q7WUaJ3b8U46J+QnWF+n4J1Syh2w430URfvc0Ah/7xzrdpDLnkGAE8swKOaIvlw== 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-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" 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).