bug#16499: GNU grep-2.16-1.mga4 , grep-2.16 from sources and grep from git master HEAD get stuck during an LC_ALL=en_US.UTF-8 search inside a short binary file

libpthread.so.0 => /lib64/libpthread.so.0 (0x7f19ecd30000) /lib64/ld-linux-x86-64.so.2 (0x7f19ed568000) shlomif@telaviv1:~$ rpm -qf /lib64/libpcre.so.1 lib64pcre1-8.33-2.mga4 Regards, Shlomi Fish -- ---

bug#16499: GNU grep-2.16-1.mga4 , grep-2.16 from sources and grep from git master HEAD get stuck during an LC_ALL=en_US.UTF-8 search inside a short binary file

186 in grepdesc (desc=8, command_line=1) at main.c:1478 #7 0x00406e4c in grepfile (dirdesc=-100, name=0x7fffd94e "1.dat", follow=1, command_line=1) at main.c:1379 #8 0x00000040737a in grep_command_line_arg (arg=0x7fffd94e "1.dat") ---Type to continue, o

bug#16499: GNU grep-2.16-1.mga4 , grep-2.16 from sources and grep from git master HEAD get stuck during an LC_ALL=en_US.UTF-8 search inside a short binary file

ed here: http://bugs.exim.org/show_bug.cgi?id=1437 Thanks! — Shlomi Fish -- ----- Shlomi Fish http://www.shlomifish.org/ Best Introductory Programming Language - http://shlom.in/intro-lang “I simply hate, detest, loathe, despise, and ab

bug#18806: grep -rP getline crashes prematurely (without displaying all results) on invalid UTF-8 input with LC_ALL=en_US.UTF-8

grep-test/round_robin.t:while (my $line = $io->getline || $io->getlinegrep: internal PCRE error: -32 with the latest git grep. Regards, Shlomi Fish -- ----- Shlomi Fish http://www.shlomifish.org/ UNIX Fortun

bug#18806: grep -rP getline crashes prematurely (without displaying all results) on invalid UTF-8 input with LC_ALL=en_US.UTF-8

Hi Mr. Eggert, On Thu, 23 Oct 2014 14:06:32 -0700 Paul Eggert wrote: > On 10/23/2014 04:15 AM, Shlomi Fish wrote: > > internal PCRE error: -32 > > > > with the latest git grep. > > I am not seeing a problem with that test case on my platform. I am > running

bug#18806: grep -rP getline crashes prematurely (without displaying all results) on invalid UTF-8 input with LC_ALL=en_US.UTF-8

On Sat, 25 Oct 2014 01:45:42 +0900 Norihiro Tanaka wrote: > Shlomi Fish write: > > `which grep` --color -rP getline grep-test > > If -o or --color option is specified, may be line_end < validated in > longest exact match. As a result, a negative value is set to >

bug#18806: grep -rP getline crashes prematurely (without displaying all results) on invalid UTF-8 input with LC_ALL=en_US.UTF-8

e > effect in comparison with your patch, even if `execute' ran for each > character. > Thank you both for the fix. ♥! Regards, Shlomi Fish -- --------- Shlomi Fish http://www.shlomifish.org/ Optimising Code

bug#21670: surprising bug in grep -e with anchors

installing the attached further patch, to help prevent this bug from coming > back in a future version. thanks to greg, to greg's student, and to Paul for their contributions! Regards, Shlomi Fish -- - Shlomi Fish

bug#21700: new snapshot available: grep-2.21.78-7da30

this > announcement are any indication. Let's be optimistic and presume that > many have built and run the tests, but didn't bother to write in > because all of the test passed. How can I get the sources to this test sna

bug#21755: new snapshot available: grep-2.21.82-fbc5

AIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 ==== Regards, Shlomi Fish > > Changes in gnulib since 2.21.78-7da30: > > * gnulib 5513b40...956fa54 (50): > > stdalign: port to Sun C 5.9 > > autoupdate > > update from texinfo > > autoupdate > >

bug#22899: new snapshot available: grep-2.23.7-9e28

XPASS: 0 # ERROR: 0 on Mageia Linux x86-64 v6/Cauldron. Is there anything else that I can do for you? Regards, Shlomi Fish -- ----- Shlomi Fish http://www.s

bug#23185: GNU grep matching discrepancy between -a/--text and not.

atter. I'm on Mageia linux x86-64 v6 and have built GNU grep from the latest git commit ( c767ed70eca9a82d76f07dcdbcaafa21ec7f86d6 ) to test. Regards, Shlomi Fish P.S: it seems the build system uses gperf but configure does not verify that it exists i

bug#23844: broken: randomly detexts textf files as binary

try passing the --ascii flag, or using one of http://beyondgrep.com/ or http://beyondgrep.com/more-tools/ . Regards, Shlomi Fish > This is a critical issue that renders grep completely unusable. > It was said to be fixed upstream but then they say

[bug #13847] memchr() not checked on Pexecute() - leads to segfault

URL: Summary: memchr() not checked on Pexecute() - leads to segfault Project: grep Submitted by: shlomif Submitted on: Tue 07/19/2005 at 07:57 Category: None

bug#26904: Wishlist: Tell grep to stop when a line matches something else.

;bar', stop searching for 'foo'. It would > help me out a lot when searching for things in my perl modules where I > do not want my perl pod searched. > It may be out of the scope of GNU grep, but should be doable in perl -ln or sed. E.g (untested): perl -ln -E '/

bug#35077: grep bug?

am I doing > something wrong? > > thanks, > Todd Hoatson -- ----- Shlomi Fish http://www.shlomifish.org/ http://www.shlomifish.org/humour/bits/New-versions-of-the-GPL/ HP/UX is not a UNIX, and AIX is even less of it than that. — An Israeli Open So

bug#40868: Grep C library for multi-string pattern matching?

-sa). Furthermore, you may wish to look at FOSS grep-like tools: * https://wiki.freebsd.org/BSDgrep * https://github.com/ggreer/the_silver_searcher * https://beyondgrep.com/more-tools/ > Thanks in advance. > > > -- Shlomi Fish https://www.shlomifish.org/ Let’s ta

bug#41262: Weird behavior with grep regex

age and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. Thank you. > Ahem :( -- Shlomi Fish https://www.shlomifish.org/ https://www.shlomifish.org/humour/Summerschool-at-the-NSA/ Knuth is not God! Typing

bug#42762: GREP does not support Unicode

1:39:47 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux shlomif[homepage]:$trunk$ » note that "שלום" is the hebrew spelling of https://en.wikipedia.org/wiki/Shalom . Regards, Shlomi Fish > I am using version Git for Windows v2.25.0 > > Kind regards > > > > >

bug#42762: GREP does not support Unicode

options or tweak the https://en.wikipedia.org/wiki/Environment_variable -s. Also see https://beyondgrep.com/ . > Kind regards > > -Original Message- > From: Shlomi Fish > Sent: Saturday, August 8, 2020 17:16 > To: ca...@kwpg.info > Cc: 42...@debbugs.gnu.org >

bug#43040: grep 3.4: memory leak

in 216,158 blocks > ==156624== possibly lost: 25,830 bytes in 13 blocks > ==156624==still reachable: 3,751,973,767 bytes in 43,402 blocks > ==156624== of which reachable via heuristic: > ==156624== newarray : 112 bytes in 1 >

bug#43040: grep 3.4: memory leak

ase. The first patch is a bit of a hack > but does the real work; the rest are merely cleanups or very minor > performance improvements. Thanks, Paul! I can confirm that the latest git master version of gnu grep (which incorporates the patches) is faster than 3.4. -- Shlomi Fish

bug#43863: [PATCH] grep: remove unusable code

re > removed in commit 016e590a8198009bce0e1078f6d4c7e037e2df3c. Do you mean the code is "unusable" (= "cannot be used"; https://en.wiktionary.org/wiki/unusable ) or is it "unused" (= "not being used": https://en.wiktionary.org/wiki/unused )? -- Shlom

bug#43863: [PATCH] grep: remove unusable code

Hi! On Sat, 10 Oct 2020 16:02:53 +0900 Norihiro Tanaka wrote: > On Fri, 9 Oct 2020 12:53:47 +0300 > Shlomi Fish wrote: > > > Hi Norihiro Tanaka! > > > > On Thu, 08 Oct 2020 18:55:50 +0900 > > Norihiro Tanaka wrote: > > Thanks, not 'unusable&#x

bug#58502: We should not deprecate egrep and fgrep

lear that in reality, nobody actually realised it was "obsolescent" > and in fact actively using it in new scripts. > > Really, speaking from my perspective, distribution maintainers have > got enough going on with various fires (Clang 16, OpenSSL 3, > time64 migration, .

bug#58502: We should not deprecate egrep and fgrep

, as suggested earlier, just make it a non-POSIX GNU extension, > even though POSIX itself points out that egrep and fgrep are around to > not break old scripts. grep -P, with PCRE support, isn't POSIX either, > so there's precedent to extend GNU grep beyond what POSIX mandates. >