On Mon, Nov 4, 2013 at 11:38 AM, Dave Reisner <[email protected]> wrote: > On Sat, Nov 02, 2013 at 04:05:52PM -0700, Jim Meyering wrote: >> On Thu, Oct 31, 2013 at 8:26 AM, Jim Meyering <[email protected]> wrote: >> ... >> > With this and the nit about --version output being wrong, I now have >> > two reasons to make a new release. >> >> Thanks again for the report, Dave. >> Here's the fix I expect to push: > > Thanks Jim. > > Apologies for not responding to this sooner. I tested your patch and can > confirm that the behavior is better, but the new behavior still seems > like a regression. Take, for example, the simple instance of grep'ing > grep's own git repo. > > # with grep 2.14 > $ grep -rPw GNULIB > gnulib/m4/bison.m4:dnl Declaring YACC & YFLAGS precious will not be necessary > after GNULIB > gnulib/lib/glob.c: HAVE_STRUCT_DIRENT_D_TYPE plays the same role in GNULIB. > */ > gnulib/lib/netdb.in.h: GNULIB getaddrinfo() replacement, so are not yet > needed. > gnulib/lib/argp.h:/* GNULIB makes sure both program_invocation_name and > > # with grep built from HEAD > $ ./src/grep -rPw GNULIB > ./src/grep: invalid UTF-8 byte sequence in input > > I would expect that the invalid UTF-8 wouldn't stop grep cold, but > continue on, ignoring the non-matching data, just as grep without the -P > flag does.
Hi Dave, I agree, and so does pcregrep. There are a few other problems with grep's PCRE driver code: for example, a problem (no matter how serious) in one file should not cause the entire grep run to exit; grep should continue processing remaining files. And when grep reports the problem, it should include at least the file name in the diagnostic. I will fix those before the upcoming snapshot. Thanks, Jim
