bug#64773: grep 3.11 -r on 100000+ files fails with "Operation not supported"

On Fri, Jul 21, 2023 at 4:38 PM Paul Eggert wrote: > To fix just this bug (as opposed to the other Gnulib-related bugs that > may be lurking) try applying the attached Gnulib patch to a grep 3.11 > tarball. > > Closing the debbugs.gnu.org bug report, as the bug has been fixed upstream. Thanks for

bug#64235: patch: Ensure that makeinfo ≥ 6.8 checks the @menu structure

On Thu, Jun 22, 2023 at 4:28 PM Bruno Haible wrote: > Makeinfo versions < 6.7 detected mistakes in the @menu structure of TeXinfo > input. Makeinfo versions ≥ 6.8 don't do this any more by default. They need > an extra option, for this validation to happen. See >

bug#63780: Reversing the grep message output type matching binary files (without the -a option added) changed from stdout to stderr

tags 63780 notabug close 63780 On Sun, May 28, 2023 at 9:56 PM 2773414454 via Bug reports for GNU grep wrote: > Between grep3.4 and grep3.5, the grep message output type matching binary > files (without the -a option added) changed from stdout to stderr. This > results in the inability to pip

bug#63533: test-mbrlen5.sh failure

On Thu, May 18, 2023 at 2:44 PM Carlo Marcelo Arenas Belón wrote: > On Wed, May 17, 2023 at 09:09:02PM -0400, Caleb Zulawski wrote: > > > > Isn’t this test too strict, then? > > It shouldn't had been included with the release; the attached patch > should help with that for future releases. Thanks

bug#63533: test-mbrlen5.sh failure

tags 63533 notabug close 63533 done On Tue, May 16, 2023 at 1:34 PM Carlo Arenas wrote: > That is a test for a bug that your system image has but that is not > relevant to grep (mbrlen doesn't correctly handle a call with a len of > 0). Thanks for responding. This reply (via the above) marks thi

bug#63419: Spelling patch

On Wed, May 10, 2023 at 3:49 PM Josh Soref wrote: > Some projects seem very attached to historical typos, I haven't > checked carefully to determine if this is such a project. Do note that > `Alain Magloire`'s is among the things that was historically > misspelled (see 2001-02-17). > > There are a

bug#62983: workaround PCRE2 bug affecting at least \D and \W

On Sun, Apr 30, 2023 at 3:15 AM Paul Eggert wrote: > > On 2023-04-28 23:54, Jim Meyering wrote: > > I've made some small adjustments and tidied up the ChangeLog in the > > attached. > > One question about that patch (both original and as revised). Why do we >

bug#63146: Document that -f takes "-" on Info and man page?

On Fri, Apr 28, 2023 at 3:26 PM Sebastian Carlos wrote: > Currently the documentation for the -f flag in both man page and info > are not very clear about the possibility of passing "-" to read from stdin. Thanks for pointing that out. I've addressed that with this just-pushed commit: grep-doc-

bug#62983: workaround PCRE2 bug affecting at least \D and \W

On Fri, Apr 21, 2023 at 10:22 PM Carlo Marcelo Arenas Belón wrote: > On Fri, Apr 21, 2023 at 11:42:50AM -0700, Paul Eggert wrote: > > On 2023-04-20 19:04, Carlo Marcelo Arenas Belón wrote: > > > All versions of PCRE2 that include PCRE2_MATCH_INVALID_UTF had a bug on > > > its JIT implementation th

bug#63016: make it easier to build with development versions of PCRE2

On Sat, Apr 22, 2023 at 6:08 PM Carlo Marcelo Arenas Belón wrote: > Building against a different version of PCRE2 that the one that is provided > with the system is complicated by the fact that unlike what is advertised, > if a pkg-config module for libpcre2-8 is found, it will override the values

bug#63030: correction

tags 63030 notabug done On Sun, Apr 23, 2023 at 5:05 AM Sebastian Carlos wrote: > On second thought, I think the documentation is fine. I just misread it. It > has two sentences: "Skip any COMMAND-LINE file with..." and "When searching > recursively, skip any SUBFILE whose...". So both cases are

bug#62983: workaround PCRE2 bug affecting at least \D and \W

On Thu, Apr 20, 2023 at 7:33 PM Jim Meyering wrote: > > On Thu, Apr 20, 2023 at 7:05 PM Carlo Marcelo Arenas Belón > wrote: > > All versions of PCRE2 that include PCRE2_MATCH_INVALID_UTF had a bug on > > its JIT implementation that results in failure to match for the nega

bug#62983: workaround PCRE2 bug affecting at least \D and \W

On Thu, Apr 20, 2023 at 7:05 PM Carlo Marcelo Arenas Belón wrote: > All versions of PCRE2 that include PCRE2_MATCH_INVALID_UTF had a bug on > its JIT implementation that results in failure to match for the negative > perl classes, and seems to be easier to replicate when the matching > character i

bug#60690: -P '\d' in GNU and git grep

On Wed, Apr 5, 2023 at 11:33 AM Paul Eggert wrote: > On 2023-04-04 12:31, Junio C Hamano wrote: > > My personal inclination is to let Perl folks decide > > and follow them (even though I am skeptical about the wisdom of > > letting '\d' match anything other than [0-9]) > > I looked into what pcre2

bug#60690: -P '\d' in GNU and git grep

On Mon, Apr 3, 2023 at 11:47 PM Paul Eggert wrote: > On 2023-04-03 20:30, Jim Meyering wrote: > > have you seen justification > > (other than for compatibility with some other tool or language) for > > allowing \d to match non-ASCII by default, in spite of the risks? &g

bug#60690: -P '\d' in GNU and git grep

On Mon, Apr 3, 2023 at 2:39 PM Paul Eggert wrote: > I've recently done some bug-report maintenance about a set of GNU grep > bug reports related to whether whether "grep -P '\d'" should match > non-ASCII digits, and have some thoughts about coordinating GNU grep > with git grep in this department.

bug#62647: [INSTALL] grep: re-fix Y2038 bug on glibc 2.34+ x86, ARM

On Mon, Apr 3, 2023 at 11:20 AM Paul Eggert wrote: > On 2023-04-03 10:52, Jim Meyering wrote: > > I wanted to see how this would make grep fail, but don't > > have convenient access to such hosts. Would this trigger the failure? > > > >touch -t 20390101

bug#62647: [INSTALL] grep: re-fix Y2038 bug on glibc 2.34+ x86, ARM

On Mon, Apr 3, 2023 at 10:34 AM Paul Eggert wrote: > The meaning of AC_SYS_LARGEFILE has changed to no longer even try > to use wider time_t if available. So use AC_SYS_YEAR2038 as well. > A more-aggressive change would be to use the next Autoconf’s > AC_SYS_YEAR2038_REQUIRED but at least let’s r

bug#62483: echo a | grep -E -w '((()|a)|())*' # does not terminate

On Sun, Apr 2, 2023 at 1:25 PM Carlo Arenas wrote: > On Sun, Apr 2, 2023 at 11:30 AM Paul Eggert wrote: > > > > Also, GNU grep -w passes the following more-complicated regexp to dfaparse: > > but AFAIK `-w` is not necessary to trigger it, as the following also > infloops in Fedora Rawhide > > $

bug#62483: echo a | grep -E -w '((()|a)|())*' # does not terminate

On Mon, Mar 27, 2023 at 6:15 AM Koen Claessen wrote: > Running the command: > > echo a | grep -E -w '((()|a)|())*' > > does not terminate, and uses a LOT of processor time, for all versions of > grep I have tried. > > This is the smallest case that could be found; simplifying anything in the > i

bug#62272: Erroneous claim in grep man page

tags notabug 62272 stop On Sun, Mar 19, 2023 at 5:47 AM David Kra wrote: > This is a request and further endorsement of a report from 2008, ending > with https://lists.gnu.org/archive/html/bug-grep/2008-08/msg2.html > > Request: Either add four words to the manpage or delete the entire > sent

bug#62267: grep-3.9 bug: \d matches multibyte digits

On Sun, Mar 19, 2023 at 4:12 PM Paul Eggert wrote: > On 2023-03-19 13:44, Jim Meyering wrote: > > I've pushed your change along with the attached. > > I'll probably create another snapshot today. > > Thanks. I also installed a minor dfa.c change in Gnulib yeste

bug#62267: grep-3.9 bug: \d matches multibyte digits

On Sun, Mar 19, 2023 at 9:54 AM Jim Meyering wrote: > On Sun, Mar 19, 2023 at 1:55 AM Paul Eggert wrote: > > > > On 2023-03-19 01:28, Paul Eggert wrote: > > > Looking at the source code again, how about if we move the PCRE-specific > > > changes from src/grep.c t

bug#62267: grep-3.9 bug: \d matches multibyte digits

On Sun, Mar 19, 2023 at 1:55 AM Paul Eggert wrote: > > On 2023-03-19 01:28, Paul Eggert wrote: > > Looking at the source code again, how about if we move the PCRE-specific > > changes from src/grep.c to src/pcresearch.c which is where it really > > belongs, and more importantly use the bleeding-ed

bug#62267: grep-3.9 bug: \d matches multibyte digits

On Sat, Mar 18, 2023 at 10:54 PM Jim Meyering wrote: > On Sat, Mar 18, 2023 at 5:39 PM Paul Eggert wrote: > > Thanks for looking into this. A couple of questions. > > > > First, some documentation issues. Why is PCRE2 incompatible with Perl on > > this issue? Are ther

bug#62267: grep-3.9 bug: \d matches multibyte digits

On Sat, Mar 18, 2023 at 5:39 PM Paul Eggert wrote: > Thanks for looking into this. A couple of questions. > > First, some documentation issues. Why is PCRE2 incompatible with Perl on > this issue? Are there other areas where the two are incompatible? To be honest, I was not too concerned about ke

bug#62267: grep-3.9 bug: \d matches multibyte digits

n_US.UTF-8 python3 \ -c "import re; print(re.match(r'\d+', '٠١٢٣٤٥٦٧٨٩', flags=re.ASCII))" None This is cause for a new snapshot today and soon thereafter, the release of grep-3.10. >From 0daefc8c5659e79149a650d97ca12b49ad5e6548 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sat, 18 Mar 2

bug#62052: _N_GNU_nonoption_argv_flags_ is no longer supported

On Wed, Mar 8, 2023 at 7:39 AM Emanuele Torre wrote: > I have noticed the _N_GNU_nonoption_argv_flags_ (where N is the pid of > grep) environment variable mentioned in the documentation. I tried to > play with it, but it does not seem to work: > > bash-5.1$ (declare -x _"$BASHPID"_GNU_nonoption_a

bug#60697: GNU grep mishandles \b near encoding errors

On Mon, Jan 9, 2023 at 10:16 PM Paul Eggert wrote: > Here's a shell session illustrating the problem on Fedora 37, which has > GNU grep 3.7. The same bug is still in bleeding-edge GNU grep. > >$ export LC_ALL=en_US.utf8 >$ printf '\300\n' | grep '\b' >grep: (standard input): binary fil

bug#60708: pcre: improve support for linking with a library without unicode

On Tue, Jan 10, 2023 at 3:19 AM Carlo Arenas wrote: > Noticed while testing the previous patch, and which resulted in tests > being skipped for the wrong reason. Thanks for catching that. I'll push the following tomorrow. It has a tiny change that moves the declaration of "unicode" down to just b

bug#60618: unicode characters are not identified as such for \w and \b with -P

On Fri, Jan 6, 2023 at 11:37 PM Jim Meyering wrote: > On Fri, Jan 6, 2023 at 11:28 PM Jim Meyering wrote: > > On Fri, Jan 6, 2023 at 7:49 PM Carlo Arenas wrote: > > > Reported to PCRE[1] with mention of GNU grep being also affected. > > > > > > [1] https://

bug#60618: unicode characters are not identified as such for \w and \b with -P

On Fri, Jan 6, 2023 at 11:28 PM Jim Meyering wrote: > On Fri, Jan 6, 2023 at 7:49 PM Carlo Arenas wrote: > > Reported to PCRE[1] with mention of GNU grep being also affected. > > > > [1] https://github.com/PCRE2Project/pcre2/issues/185 > > Yikes. This is a big deal. &g

bug#60618: unicode characters are not identified as such for \w and \b with -P

On Fri, Jan 6, 2023 at 7:49 PM Carlo Arenas wrote: > Reported to PCRE[1] with mention of GNU grep being also affected. > > [1] https://github.com/PCRE2Project/pcre2/issues/185 Yikes. This is a big deal. Thank you for the patch and added test. I made a tiny comment tweak and this test logic change

bug#60038: grep 2.20 - invalid option with search pattern "-/"

tags 60038 notabug thanks On Tue, Dec 13, 2022 at 10:04 AM Daniel Schättgen wrote: > When searching for a pattern that includes "-/", the pattern is interpreted > as option: > > [dsg@db01]# grep "-" example.txt > --/-- > [dsg@db01]# grep "/" example.txt > --/-- > [dsg@db01]# grep "-/" example.tx

bug#57604: [ef]grep usage -> POSIXLY_CORRECT?

On Fri, Sep 16, 2022 at 8:12 AM Simon Josefsson wrote: > Jim Meyering writes: > > > This would be an envvar for which we do not commit to any level of > > support in future releases. > > Would the envvar be documented? Would it be a deprecated feature, with > a remova

bug#57604: [ef]grep usage -> POSIXLY_CORRECT?

On Thu, Sep 15, 2022 at 9:28 PM Guillem Jover wrote: > On Fri, 2022-09-09 at 11:41:49 -0500, Paul Eggert wrote: > > On 9/9/22 07:16, Guillem Jover wrote: > > > There are now packages that fail to work such as > > > apt-file (https://bugs.debian.org/1019329), > > > > From what I can see, that bug r

bug#57604: [ef]grep usage -> POSIXLY_CORRECT?

On Thu, Sep 8, 2022 at 4:01 PM Karl Berry wrote: > Hi Jim, > > Some must care about portability, > > Certainly agreed. Even I do, sometimes :). But that does not mean > everyone needs to, in every situation. As I said, I fail to understand > the benefit of making the warning unconditional. >

bug#57604: [ef]grep usage -> POSIXLY_CORRECT?

Hi Karl, Sorry to cause you grief, but... On Wed, Sep 7, 2022 at 7:49 PM Karl Berry wrote: > > [ef]grep > > I guess my basic issue is that I don't understand the benefit of the new > warning. It causes a lot of trouble. What is the countervailing > positive benefit? Some must care about p

bug#56888: 'echo message | grep []' is affected by files in local directory when using bracket

tags 56888 + notabug close 56888 stop On Tue, Aug 2, 2022 at 9:08 AM Carlo Arenas wrote: > > This behaviour is expected and described in the manual (albeit it > might be a good candidate for a FAQ) : > > https://www.gnu.org/software/grep/manual/grep.html#Usage > > Even before grep gets to see t

bug#56697: v. 3.7: Typo in man page

On Fri, Jul 22, 2022 at 3:02 AM Andrea Greselin wrote: > Hi, there's a minor bug in grep's man page (at least in Fedora 36's version > of GNU grep 3.7). In the description of the flag '-P' there's written > Interpret I as… > with the markup instruction visible, instead of "PATTERNS" being in

bug#55641: Using colours with grep

On Sat, May 28, 2022 at 5:18 PM Paul Eggert wrote: > On 5/28/22 11:19, goncholden wrote: > > I agree on removing GREP_COLOR entirely. > > Sounds good to me too. Proposed patch attached. I haven't installed > this, as I'd like Jim's opinion (we're reasonably close to a release I > think). Thanks f

bug#39678: POSIXLY_CORRECT removal, and oddball regex doc

On Sat, May 21, 2022 at 3:05 AM Paul Eggert wrote: > Looking again at grep bug 39678 I noticed > that the bug occurs even when grep is not coloring: > > echo a | grep -oi --color=never '\a' > > This outputs nothing and exits with status 0, which is clearly wrong. Wron

bug#54043: Simple regexp bug [contains spoiler for today's wordle]

On Thu, Feb 17, 2022 at 7:46 AM Matthew Wilcox wrote: > I noticed this one while doing: > > $ grep sha[^s]e five-letter-words > share > > which doesn't fit with: > > $ grep sha.e five-letter-words > shade > shake > shale > shame > shape > share > shave > > A reproducer is easy: > > $ echo shame |g

bug#54006: Duplicate test

On Mon, Feb 14, 2022 at 8:42 PM Ulrich Eckhardt wrote: > there's a duplicate test in tests/empty, see attached patch. > > I'm working on a few other improvements, so please provide feedback if > there's anything I should do differently in the future. Thank you. I've applied that, edited the commi

bug#52679: Errors in grep man pages

On Mon, Dec 20, 2021 at 8:23 AM Helge Kreutzmann wrote: > > Dear grep maintainer, > the manpage-l10n project maintains a large number of translations of > man pages both from a large variety of sources (including grep) as > well for a large variety of target languages. > > During their work transl

bug#47264: [PATCH] pcre: migrate to pcre2

Thanks Carlos for working on that and Paul for the speedy feedback! I won't be able to spend time on this for the next couple of weeks.

bug#51231: disregard patch

tags 51231 notabug stop On Sat, Oct 16, 2021 at 12:29 AM Carlo Arenas wrote: > And of course it has side effects (as shown by the test suite), and > would only help (if fixed) when the needle is a fixed string, which is > 3x slower than doing -F, -G or -E. > > Apologies for the distraction. Mark

bug#46227:

On Thu, Oct 14, 2021 at 12:03 AM Sam James wrote: > I'm sorry for missing your earlier question -- yes, it's working great in 3.7, > and I really appreciate the help from you both. Thanks for confirming it's resolved. Closing this ticket.

bug#50093: djb2 correction

On Tue, Aug 17, 2021 at 11:04 PM Paul Eggert wrote: > On 8/17/21 3:32 AM, Jim Meyering wrote: > > - size_t h = 0; > > + size_t h = 5381; > > I expect DJB chose that number because of the primeth recurrence > sequence <https://oeis.org/A007097>: > > 2 is 1st

bug#50093: djb2 correction

Alex Murray noticed that my djb2 implementation mistakenly initialized to 0, rather than to 5381. Corrected with this: >From 54590ca833dba62041af045e7bc7c09b90b54b71 Mon Sep 17 00:00:00 2001 From: Alex Murray Date: Tue, 17 Aug 2021 03:24:37 -0700 Subject: [PATCH] grep: correct DJB2 initialization

bug#49996: egrep and fgrep?

On Sun, Aug 15, 2021 at 8:11 PM Paul Eggert wrote: > > On 8/15/21 7:25 AM, arn...@skeeve.com wrote: > > I'm willing to bet that the majority of grep/egrep/fgrep invocations > > come from the command line rather than from scripts. > > That's not true for me, as I almost always invoke 'grep' via a s

bug#46227: Test failure on SPARC (stack-overflow)

On Tue, Aug 10, 2021 at 6:53 AM Paul Eggert wrote: > The stack-overflow bug you reported appears > to be fixed on SPARC Solaris 10. Could you please try again on SPARC > Gentoo? You can use the new grep snapshot, announced here: > > https://lists.gnu.org/r/grep-devel/2

bug#49983: grep-3.6.27-20b4 tests fail on Cygwin

On Wed, Aug 11, 2021 at 9:36 AM Paul Eggert wrote: > > On 8/11/21 12:20 AM, Gary Johnson wrote: > > The > > main thing I'm lacking is time. > > I *quite* understand. > > Unfortunately I don't use Cygwin so can't help much on Cygwin-specific > stuff. Thanks for reporting and investigating. While

bug#49996: egrep and fgrep?

On Wed, Aug 11, 2021 at 9:35 AM Paul Eggert wrote: > On 8/11/21 12:22 AM, Simon Josefsson via Bug reports for GNU grep wrote: > > I think the main reason for deprecating > > them was that POSIX dropped a requirement for them? > > As I recall, it was because they were kinda useless cruft. Portable

bug#47649: grep bug report - improper handling of file symlinks with -r option

On Sat, Aug 7, 2021 at 4:43 AM Chris Drake wrote: > Looks like the -r and -R got mixed up? > > What is now the "-R" behaves the same way as the original "-r", and now the > new "-r" behaves differently. > > For backwards-compatibility, the original behaviour should have been > preserved, and the

bug#45849: Autoconf options and dependencies

On Thu, Jan 14, 2021 at 8:36 AM Jim Meyering wrote: > On Thu, Jan 14, 2021 at 6:29 AM Jeffrey Walton wrote: > > I noticed Grep offers these two autoconf options (and friends): > > > > --with-libiconv-prefix > > --with-libintl-prefix > > > > Configu

bug#47834: grep: Document --group-separator/--no-group-separator

On Fri, Apr 16, 2021 at 5:15 PM Kevin Locke wrote: > It would be great if the grep.1 man page and --help usage information > included the --group-separator and --no-group-separator options (which > are already documented in grep.texi). I've attached patches to do that. Thank you. I've applied th

bug#47649: grep bug report - improper handling of file symlinks with -r option

tags 47649 notabug close 47649 done On Wed, Apr 7, 2021 at 7:21 PM Chris Drake wrote: > *This is the original working grep behaviour - it found text inside files > that were symlinks:-* > (Note the output: "*./folder/testfile1:this is my test file*") > > [root@ir2 ~]# grep --version > grep (GNU g

bug#46179: Tweak to man page

On Fri, Jan 29, 2021 at 11:51 AM Robert Bruntz wrote: > I would like to recommend a minor tweak to the man page for GNU grep. > (The version I'm looking at is 2.20, but I doubt that matters.) > I would recommend changing the description of the -l and -L options from > this: > The scanning will

bug#45849: Autoconf options and dependencies

On Thu, Jan 14, 2021 at 6:29 AM Jeffrey Walton wrote: > I noticed Grep offers these two autoconf options (and friends): > > --with-libiconv-prefix > --with-libintl-prefix > > Configure does not complain when they are used. > > However, when I check link dependencies with ldd: > > $ ldd

bug#45432: Use both --include and --exclude at the same time

tags 45432 moreinfo stop On Fri, Dec 25, 2020 at 8:57 AM Fred .Flintstone wrote: > It seems --exclude does nothing when --include is used. It would be useful > to be able to use both together, in order to do things such as recusively > grepping files of a certain file extension while excluding ce

bug#45353: Errors in man pages

On Wed, Dec 23, 2020 at 10:03 AM Helge Kreutzmann wrote: > > Hello Jim, > On Wed, Dec 23, 2020 at 09:14:20AM -0800, Jim Meyering wrote: > > On Wed, Dec 23, 2020 at 8:46 AM Jim Meyering wrote: > > > On Mon, Dec 21, 2020 at 8:12 AM Helge Kreutzmann > > &g

bug#45353: Errors in man pages

On Wed, Dec 23, 2020 at 8:46 AM Jim Meyering wrote: > > On Mon, Dec 21, 2020 at 8:12 AM Helge Kreutzmann wrote: > ... > > Thank you for the suggestions. > > > Man page: grep.1 > > Issue: The option was mentioned above! > > > > "Suppress normal outp

bug#45353: Errors in man pages

On Mon, Dec 21, 2020 at 8:12 AM Helge Kreutzmann wrote: ... Thank you for the suggestions. > Man page: grep.1 > Issue: The option was mentioned above! > > "Suppress normal output; instead print a count of matching lines for each " > "input file. With the B<-v>, B<-\\^-invert-match> option (see

bug#44888: [minor] [french translation] Help mentions "NONBRE" -- should be "NOMBRE"

> I fixed this bug and the last translation is available on the > Translation Project for developers. Merci, Stéphane.

bug#44888: [minor] [french translation] Help mentions "NONBRE" -- should be "NOMBRE"

On Thu, Nov 26, 2020 at 11:19 AM Jim Meyering wrote: > On Thu, Nov 26, 2020 at 5:17 AM Niols wrote: > > Using GNU grep version 3.6 on Archlinux. > > > > The french translation of --help message contains: > > > > -NONBRE identique à --context=NON

bug#44754: Extreme performance degradation in GNU grep 3.4 / 3.6

On Thu, Dec 3, 2020 at 12:26 AM Norihiro Tanaka wrote: > On Thu, 26 Nov 2020 21:41:20 -1000 > Jim Meyering wrote: > > > On Thu, Nov 26, 2020 at 9:03 AM Jim Meyering wrote: > > > > > > On Wed, Nov 25, 2020 at 3:12 PM Jim Meyering wrote: > > > > T

bug#44754: Extreme performance degradation in GNU grep 3.4 / 3.6

On Thu, Nov 26, 2020 at 9:03 AM Jim Meyering wrote: > > On Wed, Nov 25, 2020 at 3:12 PM Jim Meyering wrote: > > Thank you for the fine bug report. > > The grep-3.6 bug you've exposed is due to the fact that your input > > triggers excessive hash collisions when

bug#44888: [minor] [french translation] Help mentions "NONBRE" -- should be "NOMBRE"

On Thu, Nov 26, 2020 at 5:17 AM Niols wrote: > Using GNU grep version 3.6 on Archlinux. > > The french translation of --help message contains: > > -NONBRE identique à --context=NONBRE > > as the translation of: > > -NUM same as --context=NUM > > in the "Context control" se

bug#44754: Extreme performance degradation in GNU grep 3.4 / 3.6

On Wed, Nov 25, 2020 at 3:12 PM Jim Meyering wrote: > Thank you for the fine bug report. > The grep-3.6 bug you've exposed is due to the fact that your input > triggers excessive hash collisions when using the code modeled after > gnulib/lib/hash-pjw.c. That made the new patt

bug#44754: Extreme performance degradation in GNU grep 3.4 / 3.6

On Thu, Nov 19, 2020 at 7:32 PM Frank Heckenbach wrote: > I have a use case where I run grep with a large number of search > patterns on a large text file. It works well with grep-3.3, but with > grep-3.4 it quickly burned through GBs of memory and almost locked > up my system due to swapping. > >

bug#44535: grep-3.6 released [stable]

On Thu, Nov 12, 2020 at 11:40 PM Paul Eggert wrote: > On 11/9/20 8:12 AM, Andreas Schwab wrote: > > grep 3.6 fails to build: > > > > test-nl_langinfo-mt.c: In function 'threadN_func': > > test-nl_langinfo-mt.c:185:1: error: no return statement in function > > returning non-void [-Werror=return-ty

bug#44535: grep-3.6 released [stable]

On Mon, Nov 9, 2020 at 8:14 AM Andreas Schwab wrote: > grep 3.6 fails to build: > > test-nl_langinfo-mt.c: In function 'threadN_func': > test-nl_langinfo-mt.c:185:1: error: no return statement in function returning > non-void [-Werror=return-type] > 185 | } > | ^ > cc1: some warnings bein

bug#43862: [PATCH] grep: set RE_NO_SUB for calling regex only to check syntax

On Mon, Oct 12, 2020 at 4:08 PM Jim Meyering wrote: > On Thu, Oct 8, 2020 at 2:41 AM Norihiro Tanaka wrote: > > > > We can set RE_NO_SUB for calling regex only to check syntax. It brings > > performance gains in cases to have a lot of enormous epsilon nodes. > > >

bug#44351: Bug in grep v3.2 onwards in regular expression matching

On Sun, Nov 1, 2020 at 10:03 AM Paul Eggert wrote: > Thanks to all for the bug report and quick fix. Closing the bug report. Thanks for closing that. I've pushed the gnulib changes and am about to push those for grep, too.

bug#44351: Bug in grep v3.2 onwards in regular expression matching

On Sun, Nov 1, 2020 at 8:05 AM Jim Meyering wrote: > On Sun, Nov 1, 2020 at 8:02 AM Jim Meyering wrote: > > > > On Sun, Nov 1, 2020 at 7:31 AM Norihiro Tanaka wrote: > > > Hi, > > > By the way, I was wondering whether to add the test to ere.tests or > >

bug#44351: Bug in grep v3.2 onwards in regular expression matching

On Sun, Nov 1, 2020 at 8:02 AM Jim Meyering wrote: > > On Sun, Nov 1, 2020 at 7:31 AM Norihiro Tanaka wrote: > > Hi, > > By the way, I was wondering whether to add the test to ere.tests or > > spencer1.tests or to a new file. How should they be used properly? > >

bug#44351: Bug in grep v3.2 onwards in regular expression matching

On Sun, Nov 1, 2020 at 7:31 AM Norihiro Tanaka wrote: > Hi, > By the way, I was wondering whether to add the test to ere.tests or > spencer1.tests or to a new file. How should they be used properly? Adding the new test in either place is fine, but there should be a comment. Also, we need a NEWS

bug#44351: Bug in grep v3.2 onwards in regular expression matching

On Sun, Nov 1, 2020 at 7:19 AM Jim Meyering wrote: > > On Sun, Nov 1, 2020 at 12:42 AM Norihiro Tanaka wrote: > > Example, > > > > a+a+a > > 1 2 3 > > > > position 1 has a repetition of "a" and other transition with "a". >

bug#44351: Bug in grep v3.2 onwards in regular expression matching

On Sun, Nov 1, 2020 at 12:42 AM Norihiro Tanaka wrote: > Example, > > a+a+a > 1 2 3 > > position 1 has a repetition of "a" and other transition with "a". > position 2 has a repetition of "a" and other transition with "a", too. > Then DFA was merging the two nodes, but it is wrong. > > Now simi

bug#44352: Incorrect matches for some ERE

On Sat, Oct 31, 2020 at 9:18 AM Gonzalo Padrino wrote: > While using GNU grep v3.4 in an Ubuntu 20.04 userspace running on top of > Win10 WSL (yeah, i know... but also checked in other envs) i discovered > what seems like an obvious bug (if i'm not mistaken). > > The bug: > - > me@host:~$

bug#44351: Bug in grep v3.2 onwards in regular expression matching

On Sat, Oct 31, 2020 at 9:17 AM Gonzalo Padrino wrote: > While using GNU grep v3.4 in an Ubuntu 20.04 userspace running on top of > Win10 WSL (yeah, i know... but also checked in other envs) i discovered > what seems like an obvious bug (if i'm not mistaken). > The bug: > - > me@host:~$ ech

bug#43862: [PATCH] grep: set RE_NO_SUB for calling regex only to check syntax

On Thu, Oct 8, 2020 at 2:41 AM Norihiro Tanaka wrote: > > We can set RE_NO_SUB for calling regex only to check syntax. It brings > performance gains in cases to have a lot of enormous epsilon nodes. > > > $ printf '(%02d)\n' | sed 's/0/|/g' >pat > > (before) > $ time -p env LC_ALL=C src/grep

bug#43527: [PATCH] grep: avoid unneeded compilation of regex

On Tue, Sep 22, 2020 at 8:04 PM Norihiro Tanaka wrote: > On Tue, 22 Sep 2020 16:25:06 -0700 > Jim Meyering wrote: > > > Oh! Good timing. I was about to make a new snapshot. > > Do you happen to have a test case handy that demonstrates the failure? > > I added test cas

bug#43527: [PATCH] grep: avoid unneeded compilation of regex

On Wed, Sep 23, 2020 at 8:16 PM Paul Eggert wrote: > On 9/23/20 8:00 PM, Jim Meyering wrote: > > Thank you, I expect to push it shortly, along with a gnulib-sync diff, > > to pull in Paul's regex fixes. > > Ouch, it looks like we had dueling commits prepared, as I re

bug#43527: [PATCH] grep: avoid unneeded compilation of regex

On Tue, Sep 22, 2020 at 8:04 PM Norihiro Tanaka wrote: > On Tue, 22 Sep 2020 16:25:06 -0700 > Jim Meyering wrote: > > > Oh! Good timing. I was about to make a new snapshot. > > Do you happen to have a test case handy that demonstrates the failure? > > I added test cas

bug#43577: wrong result for grep -io in turkish locale

On Wed, Sep 23, 2020 at 6:24 AM Norihiro Tanaka wrote: > > In turkish locale, upper and lower case are mapped as following. > > U0049 <-> U0131 > U0069 <-> U0130 > > It's expected that both following test cases returns U0130, but later > returns nothing. > > $ printf '\304\260\n' >I # U0130 >

bug#43527: [PATCH] grep: avoid unneeded compilation of regex

On Tue, Sep 22, 2020 at 3:57 PM Norihiro Tanaka wrote: > On Tue, 22 Sep 2020 08:50:03 -0700 > Jim Meyering wrote: > > > On Tue, Sep 22, 2020 at 7:54 AM Norihiro Tanaka wrote: > > > On Mon, 21 Sep 2020 17:33:25 -0700 > > > Jim Meyering wrote: > > ... >

bug#43527: [PATCH] grep: avoid unneeded compilation of regex

On Tue, Sep 22, 2020 at 7:54 AM Norihiro Tanaka wrote: > On Mon, 21 Sep 2020 17:33:25 -0700 > Jim Meyering wrote: ... > > Here are the two patches (tested on top of a third that updates to > > latest gnulib). I'll await an 'ok' from Norihiro Tanaka before >

bug#43527: [PATCH] grep: avoid unneeded compilation of regex

On Sun, Sep 20, 2020 at 6:34 PM Jim Meyering wrote: > > On Sun, Sep 20, 2020 at 12:17 AM Norihiro Tanaka wrote: > > Hi, > > Performace for as following case is fixed in bug#43040. > > > > $ yes 0 | head -10 | sed '$s/././' >pat > > $ grep

bug#43527: [PATCH] grep: avoid unneeded compilation of regex

On Sun, Sep 20, 2020 at 12:17 AM Norihiro Tanaka wrote: > Hi, > Performace for as following case is fixed in bug#43040. > > $ yes 0 | head -10 | sed '$s/././' >pat > $ grep -vf pat /dev/null > > However, still slow and a lot of memory wasted for the following cases. > > $ grep -vf /usr/s

bug#33552: bug#29668: grep patches for "Binary file FOO matches" glitches

On Thu, Sep 17, 2020 at 7:59 PM Paul Eggert wrote: > On 9/17/20 3:03 PM, Jim Meyering wrote: > > The alternative is to change that "B" to a "b", which should be fine, > > now that it's only emitted to stderr. > > Makes sense. > > NEWS should b

bug#33552: grep patches for "Binary file FOO matches" glitches

On Thu, Sep 17, 2020 at 11:46 AM Paul Eggert wrote: > Attached are two related 'grep' patches, one prompted by Bug#33552 "Possible > bug > with handling -I option" and the other by Bug#29668 "grep: Fatal problem with > (big) file". Although I'd normally install these on grep master, Jim has > st

bug#40634: Massive pattern list handling with -E format seems very slow since 2.28.

On Sun, Sep 13, 2020 at 7:03 PM Paul Eggert wrote: > On 9/11/20 11:41 PM, Jim Meyering wrote: > >> https://bugs.gnu.org/40634#32 > >> > >> I'll try to take a look at the later patch. > > > > Oh! Glad you spotted that. > > I took a look and the

bug#40634: Massive pattern list handling with -E format seems very slow since 2.28.

On Sat, Sep 12, 2020 at 1:01 AM Paul Eggert wrote: > > And here is the adjusted patch: > > Hold on, that looks like a cleanup of the April 18 patch posted here: > > https://bugs.gnu.org/40634#26 > > But there's a later patch dated April 19, which Norihiro Tanaka said should be > more correct and s

bug#40634: Massive pattern list handling with -E format seems very slow since 2.28.

On Fri, Sep 11, 2020 at 2:47 PM Jim Meyering wrote: > On Sun, Apr 19, 2020 at 4:10 AM Norihiro Tanaka wrote: > > On Sun, 19 Apr 2020 07:41:49 +0900 > > Norihiro Tanaka wrote: > > > On Sat, 18 Apr 2020 00:22:26 +0900 > > > Norihiro Tanaka wrote: > > >

bug#40634: Massive pattern list handling with -E format seems very slow since 2.28.

On Sun, Apr 19, 2020 at 4:10 AM Norihiro Tanaka wrote: > On Sun, 19 Apr 2020 07:41:49 +0900 > Norihiro Tanaka wrote: > > On Sat, 18 Apr 2020 00:22:26 +0900 > > Norihiro Tanaka wrote: > > > > > > > > On Fri, 17 Apr 2020 10:24:42 +0900 > > > Norihiro Tanaka wrote: > > > > > > > > > > > On Fri, 17

bug#18406: O_NOATIME patch

On Tue, Sep 1, 2020 at 4:22 AM Paul Eggert wrote: > On 9/11/14 1:13 PM, Paul Eggert wrote: > > Thanks, but there's no need for that; just have 'grep' complain if the > > option is > > used and O_NOATIME == 0. > > On looking into this more today, O_NOATIME seems to be just a best-effort > thing >

bug#41004: Documentation:enhancement - search for hexvalue

On Sun, May 10, 2020 at 10:00 AM Stephane Chazelas wrote: > > 2020-05-01 19:05:28 +0200, radisso...@web.de: > [...] > > problem: grep for a character where only the hexcode in known. > > > > solution:use $'\xNN' > > then shell expands this to the required code > > > >

bug#41004: Documentation:enhancement - search for hexvalue

On Fri, May 1, 2020 at 10:07 AM wrote: > Hi, > i had the problem of searching for a non-printable character in a long > list of strings. I found nothing the documentation and but several discussion > how to do that where either complicated or did not fit for my case, maybe i > was unlucky, ntl i f

  1   2   3   4   5   6   7   8   9   10   >