From: Emily Shaffer <emilyshaffer@google.com>
Date: Thu, 13 Feb 2020 22:02:06 GMT
Subject: Re: [PATCH v6 10/15] bugreport: add config values from safelist
Message-ID: <20200213220206.GH190927@google.com>
In-Reply-To: <87zhdue3ye.fsf@igel.home>

On Fri, Feb 07, 2020 at 05:51:05PM +0100, Andreas Schwab wrote:
> On Feb 07 2020, Eric Sunshine wrote:
> 
> > On Fri, Feb 7, 2020 at 10:09 AM SZEDER Gábor <szeder.dev@gmail.com> wrote:
> >> macOS 'sed', that's what I was missing :)
> >>
> >>   sed -n 's/^\(.*\) \+annotate:bugreport\[include\].* ::$/  "\1",/p' | sort
> >>
> >> and the 'sed' included in macOS apparently interprets that '\+'
> >> differently than GNU 'sed', and as a result won't match anything.
> >
> > More generally, this would be a problem with any 'sed' of BSD lineage.
> >
> >> FWIW, that '\+' doesn't seem to be necessary, though, and after
> >> removing it the resulting generated array looked good to me [...]
> >
> > A reasonable replacement for "<SP>\+" would be "<SP><SP>*" (where <SP>
> > represents 'space').
> 
> Another problem with that regexp is that it contains two adjacent
> repetitions matching the same character.  When there are two or more
> spaces before "annotate:" all but the last of them can be matched by
> either '\(.*\)' or ' \+'.  To fix that '\(.*\)' needs to be modified to
> not match a trailing space.

Hum. I had assumed since the capture group was not greedy, it would not
capture any trailing spaces that could be captured by ' \+'. I don't see
a problem in making it non-explicit, though.

I'll hack on this some more. I do find myself pretty annoyed at the
matcher difference between 'sed' and 'also sed', though, and don't see
in the manpage a way to guarantee which matcher 'sed' should use (a la
'grep -[EFGP]'). :)

 - Emily