GNU bug report logs - #23965
egrep should report line number when failing to parse a file (with -f)

Previous Next

Full log

View this message in rfc822 format

From: Jim Meyering <jim <at> meyering.net>
To: Santiago Ruano Rincón <santiagorr <at> riseup.net>
Cc: 23965 <at> debbugs.gnu.org
Subject: bug#23965: egrep should report line number when failing to parse a file (with -f)
Date: Sat, 23 Jul 2016 09:31:01 -0700

[Message part 1 (text/plain, inline)]

On Wed, Jul 20, 2016 at 2:58 PM, Jim Meyering <jim <at> meyering.net> wrote:
> On Wed, Jul 13, 2016 at 1:59 AM, Santiago Ruano Rincón
> <santiagorr <at> riseup.net> wrote:
>> Please find below yet another old-standing bug filed against debian.
>> grep's behaviour is still the same in 2.25.
>>
>> https://bugs.debian.org/525214
>>
>> Cheers,
>>
>> Santiago
>>
>> ----- Forwarded message from Gunnar Wolf <gwolf <at> gwolf.org> -----
>>
>> Date: Wed, 22 Apr 2009 18:06:28 -0500
>> From: Gunnar Wolf <gwolf <at> gwolf.org>
>> To: Debian Bug Tracking System <submit <at> bugs.debian.org>
>> Subject: egrep should report line number when failing to parse a file (with -f)
>> X-Mailer: reportbug 4.1
>>
>> [...]
>>
>> egrep -f takes its input from a file. This functionality is often used
>> i.e. with logcheck, which works basically off a directory full of
>> files which contain regexes representing log messages to be either
>> ignored or pushed up - However, when something goes bad and one of
>> those lines is not parsable, grep won't help in debugging. As an
>> example, I got loads of log messages such as:
>>
>>     From: Cron Daemon <root <at> iiec.unam.mx>
>>     To: root <at> iiec.unam.mx
>>     Date: Tue, 21 Apr 2009 23:02:02 -0500 (CDT)
>>     Subject: Cron <logcheck <at> lafa>    if [ -x /usr/sbin/logcheck ]; then nice -n10 /usr/sbin/logcheck; fi
>>
>>     egrep: Unmatched [ or [^
>>
>> Finding the file/line where I made this particular mistake was a
>> tedious job. Users deserve egrep to report the filename and line
>> number where this error happened.
>>
>> [...]
>
> Thank you for forwarding that.
> I've written a patch to address that. Will post it shortly.

Here are two patches.
The first adds coreutils' perl-based test harness to grep.
The second improves those diagnostics and adds a test using the new harness:

    grep: print "filename:lineno:" in invalid-regex diagnostic

    Determining the file name and line number is a little tricky because
    of the way the regular expressions are all concatenated onto a newline-
    separated list.  By the time grep would compiling regular expressions,
    the <filename,lineno> origin of each regexp was no longer available.
    This patch adds a list of filename,first_lineno pairs, one per input
    source, by which we can then map the ordinal regexp number to a
    filename,lineno pair for the diagnostic.

    * src/dfasearch.c (GEAcompile): When diagnosing an invalid regexp
    specified via -f FILE, include the "FILENAME:LINENO: " prefix.
    Also, when there are two or more lines with compilation failures,
    diagnose all of them, rather than stopping after the first.
    * src/grep.h (pattern_file_name): Declare it.
    * src/grep.c: (struct FL_pair): Define type.
    (fl_pair, n_fl_pair_slots, n_pattern_files, patfile_lineno):
    Define globals.
    (fl_add, pattern_file_name): Define functions.
    (main): Call fl_add for each type of the following: -e argument,
    -f argument, command-line-specified (without -e) regexp.
    * tests/filename-lineno.pl: New file.
    * tests/Makefile.am (TESTS): Add it.
    * NEWS (Improvements): Mention this.
    Initially reported by Gunnar Wolf in https://bugs.debian.org/525214
    Forwarded to grep's bug list by Santiago Ruano Rincón as
    http://debbugs.gnu.org/23965

[filename-lineno.diff (text/plain, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.