bug#78891: Option to make grep always exit with 0

On 2025-06-24 22:28, Thomas Güttler Mailinglisten wrote: During the last months I wrote a lot of Bash code, and often I needed to handle the non-zero exit code of grep. It would be handy to have an option to make grep always return zero (except "file not found" or similar errors). I dunno, t

bug#78439: Accent insensitive grep

On 2025-05-14 22:49, Avid Seeker via Bug reports for GNU grep wrote: are equivalence classes the right tool to approach this? They're supposed to be, yes ... I see that they depend on LC_COLLATE, in which case it would be possible to setup a custom locale that matches digraphs. ... though

bug#78276: grep on file with 0xF3 byte in utf-8 locale

On 2025-05-06 00:37, Arkadiusz Miśkiewicz via Bug reports for GNU grep wrote: Is that expected behavior, no binary file warning and no matching with utf-8 locale, even with -a? It's allowed behavior, as '.' need not match encoding errors.[1] Also, 'grep' need not diagnose encoding errors that

bug#77828: LTO build fails with grep 3.12

ib to pacify GCC, and I'm closing the grep bug report.From 60d9b4134f8661dc25134dbe54be15f6138718c8 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 15 Apr 2025 13:50:32 -0700 Subject: [PATCH] dfa: pacify gcc -Wstringop-overflow Problem reported by Christian Hesse in: https://bugs.gnu

bug#77800: grep-3.12: write-error-msg test failure on fedora rawhide (f43)

Oh, sorry, I hadn't seen the email between you and Jim. I am suspicious that rawhide gettext doesn't preserve errno. Could you please run the built grep under gdb as follows and say what happens to errno? The following transcript is on Fedora 41 where things work as expected (ENOSPC == 28):

bug#77800: grep-3.12: write-error-msg test failure on fedora rawhide (f43)

Thanks for the bug report. What is the output of the following command on Fedora rawhide? LC_ALL=C strace src/grep -q --help >/dev/full On my Fedora 41 x86-64 host, the output of the above command ends as follows; what's different on your platform? sigaltstack({ss_sp=0x429f40, ss_flags=0, ss

bug#36148: grep backreference bug fixed in 3.9 upstream

On 2025-03-23 13:50, Thorsten Glaser wrote: Upstream might want to close the corresponding bug as well? As explained in , bug #36148 was originally about a different backreference bug that has not been fixed, so we shouldn't close that bug report.

bug#77301: Is this a bug?

On 3/29/25 11:06, David G. Pickett wrote: Maybe put the compiler errors and warnings in a log and use a script to grep out the not previously identified worthless ones? We typically do better than that, by telling the compiler to not generate the false alarms. Anyway this is is moot for this

bug#77301: Is this a bug?

On 3/28/25 11:14, David G. Pickett via Bug reports for GNU grep wrote: there was a specific clause in the C standard for that case, saying that it was OK That clause is still there, and so the code is valid C code. However, GCC warns about it anyway. We've changed grep (in savannah master) so

bug#77301: Is this a bug?

It's not a bug in grep. We pacified GCC's false alarm in grep commit 08c4ce064b7f42acc023a9b28d1076a81feb6143.

bug#77000: grep.in.1: use the macro '.B' for one argument

On 3/13/25 14:17, Bjarni Ingi Gislaosn wrote: -.BR ) +.B ) Thanks, I installed that.

bug#74502: grep.in.1: Some remarks about this man page

On 11/23/24 18:17, Paul Eggert wrote: that's a recently-introduced groff bug. I reported it here: https://savannah.gnu.org/bugs/index.php?66481 From the followup to that groff bug report, it appears that the groff maintainers don't consider this to be a bug, though they do s

bug#77012: Documentation problem: odd characters in ASCII text format manual

Thanks for the further investigation. I solved the problem for grep by installing the following patch, and am closing the bug report. https://web.cvs.savannah.gnu.org/viewvc/grep/grep/.htaccess?r1=1.1&r2=1.2 Presumably GNU project web pages should routinely have .htaccess files that say someth

bug#77012: Documentation problem: odd characters in ASCII text format manual

On 2025-03-14 02:22, Giacomo De Bello wrote: Greetings, the manual file in ASCII text format is filled with odd characters, and maybe this is a character conversion problem during the file generation. In example, you can see the problem in the third line of the plain text manual online https:/

bug#75806: Trailing spaces; pattern "\s" before "[[:cntrl:]]" faulty

On 2025-01-24 05:27, Andreas BROCKMANN via Bug reports for GNU grep wrote: The 1st command below correctly reports trailing spaces, for Unix and Windows format files. The 2nd one incorrectly reports all lines. grep -sHn -i " [[:cntrl:]]*$" *.vhd grep -sHn -i "\s[[:cntrl:]]*$" *.vhd I do

bug#75582: GNU grep 3.4 — enhancing manual

On 2025-01-16 20:51, jack...@fastmail.fm wrote: Clearly my previous paragraph fails the "keep word count parsimonious" mandate for man pages. Yup.

bug#75582: GNU grep 3.4 — enhancing manual

On 2025-01-15 02:51, Anton Samokat wrote: Please, make it more simple and straightforward, remove possible ambiguity Unfortunately these are competing goals. Perhaps this would be better: If no FILE is given read standard input, but if -r is given recursively search the working directory ins

bug#75197: [Feature Request] Support 'grep -A' without number to show all lines after match

On 2024-12-30 03:37, KMRH via Bug reports for GNU grep wrote: Allow the command 'grep -A' (without specifying a number) to default to showing all lines after a match We couldn't do that as-is, as 'grep -A 1' is equivalent to 'grep -A1' and people rely on that. 'grep -A 9

bug#63334: [PATCH] Add hurd-amd64 support

Re : Thanks for the bug report. That bug was fixed in Gnulib and the fix folded into grep. Closing the report.

bug#66002: [PATCH] build: suppress suggest-attribute=cold warnings

On 9/16/23 15:28, Gleb Fotengauer-Malinovskiy wrote: I'm not insisting that this needs to be addressed, but I do believe that someone else might encounter this issue. If it becomes a problem I suppose we could disable --suggest-attribute=cold, as it's not that useful for coreutils. In the mea

bug#74788: Incorrect return value for SIGPIPE case

On 2024-12-11 04:59, Sachin T wrote: Could you suggest the preferred solution for handling this situation on the z/OS platform? Since this problem afflicts many applications (not just grep), the preferred solution would be to fix z/OS so that a process terminated by a signal has the exit stat

bug#74699: need valid explanation / weird 'grep -q' behaviour

On 2024-12-04 15:43, Frank Reppin wrote: Some claim that this is due to 'set -o pipefail' beeing used in the script... but this does not really explain why it only _sometimes_ happens. I don't see why not. Pipe buffering is an "it all depends" situation. Anyway, I tried your script on bleeding

bug#74502: grep.in.1: Some remarks about this man page

Thanks, but that's a recently-introduced groff bug. I reported it here: https://savannah.gnu.org/bugs/index.php?66481

bug#74205: man: dots and closing bracket in wrong order

t nicer if grep matches similar GNU apps (regardless of what POSIX does) so I installed the attached patch to try to do that. Thanks for mentioning the issue.From 24deafb92fd8249be46f0f8f8358c604cd5476db Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 4 Nov 2024 13:52:00 -0800 Subject: [PATCH

bug#74159: Unexpected exit code of 0 when -q is set and close_stdout fails

ised if other software breaks because of this issue. So I suggest also reporting a bug to whoever maintains the NFS client code that you're using. I'm boldly closing this bug report; we can reopen it if the patch doesn't work for you.From fce28c4a5eac89e13a992fb54ce4c0e7502f4415 Mon

bug#73721: grep perf docs barely mention mem usage

On 2024-10-09 14:12, mark.yagnatin...@barclays.com wrote: With mmap(), the kernel just needs to set up a bit of book-keeping Yes, I'm sure than in some cases mmap would be a win. However, all in all it was found not to be, and I expect that the hassle of maintaining the mmap variant wasn't wo

bug#73721: grep perf docs barely mention mem usage

On 2024-10-09 10:01, mark.yagnatinsky--- via Bug reports for GNU grep wrote: After a bit of research, it seems that once upon a time, grep used mmap where possible, but it no longer does this. Thus, peak memory usage will be proportional to the length of the longest line in the file. Thus, if u

bug#73360: Error when a long list is provided to grep with "--binary-files=without-match" option

On 2024-09-20 22:41, Paul Eggert wrote: I have the sneaking suspicion that the script is assuming properties of 'grep' that are not documented and that are not guaranteed. In looking into the code a bit more, I can see some places where that is what is happening. A couple of thin

bug#73360: Error when a long list is provided to grep with "--binary-files=without-match" option

On 2024-09-20 07:22, Rodrigo Jorge wrote: Can I run those 2 grep commands with some sort of debug flag and send them back for analysis? The file list is exactly the same, just changing the file order. Unfortunately there's no debug flag. Of course you can run grep under GDB but it will require

bug#73360: Error when a long list is provided to grep with "--binary-files=without-match" option

I suggest using xargs -t to see how 'grep' is actually being invoked. Then run the individual 'grep' commands that xargs -t reports, and see which one misbehaves (or possibly you'll find that none of the individual 'grep' commands are misbehaving, and the problem lies elsewhere).

bug#72524: how does grep determine locale if no LC environment variables are set

On 2024-08-09 15:08, mark.yagnatin...@barclays.com wrote: I don't suppose you have a Windows machine with git installed conveniently lying around by any chance? (I have one lying around, but not conveniently.) Nope, don't do MS-Windows.

bug#72524: how does grep determine locale if no LC environment variables are set

On 2024-08-09 14:59, mark.yagnatin...@barclays.com wrote: Re: debugger: will that work if grep wasn't built with debug symbols? Only if you're reasonably experienced with machine code. It's not fun, but it's doable. You could write your own little test program that simply does 'setlocale (L

bug#72524: how does grep determine locale if no LC environment variables are set

On 2024-08-08 12:24, mark.yagnatin...@barclays.com wrote: Re: how am I doing that ... via bash, just like the way you suggested I run "locale" the second time: LC_CTYPE=C.UTF-8 grep -P needle haystack.txt # just CTYPE seems to be enough, no need for ALL As an aside, I wouldn't mess with LC_C

bug#72524: how does grep determine locale if no LC environment variables are set

On 2024-08-08 05:53, mark.yagnatinsky--- via Bug reports for GNU grep wrote: I ran into an odd issue... the workaround is easy enough but the issue is weird. In case this relevant, my grep coms from git bash. (which I think is mostly Cygwin? (or maybe msys2??)) Anyway, grep -P doesn't work if n

bug#72246: Possible PCRE bug in grep 3.11

On 2024-07-22 11:25, Glenn Golden wrote: str=$(printf "begin\xe2\x80\x99end") # # grep 3.11 using PCRE '[\x80-\xFF]' doesn't find any of them, # and exits with 1, indicating no match. # printf"Using grep 3.11:\n" printf "${str}\n" | grep --color=auto -P -e '[\x80-\xFF]' This asks 'grep' to out

bug#71995: fmbtest unnecessarily skipped on FreeBSD

Thanks, I installed that.

bug#42501: feature request: exclude-vcs option

On 7/6/24 22:20, Collin Funk wrote: I was basing it off the behavior of GNU tar. Doesn't --exclude-vcs there ignore .gitignore, etc? If so, maybe tar should change too.

bug#42501: feature request: exclude-vcs option

On 7/6/24 11:10, Collin Funk wrote: But I haven't used those version control systems so I am unsure which ones are directories or not. Yes, it's a bit of a puzzle. But for Git shouldn't we exclude only .git, and not .gitignore, .gitattributes, and .gitmodules? Normally these files are under G

bug#71470: test failure on CentOS 7

Thanks for the report and fixes. Close call, but since CentOS 7 is still officially alive I installed the 2nd patch. (A plus is that 'configure' is a bit faster)

bug#71087: grep.in.1: some remarks and editorial changes for this man page

Thanks, I installed the attached.From 53b889155f5ee53404a9873f48300fe5b50321d9 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 21 May 2024 09:50:43 -0700 Subject: [PATCH] doc: fix troff typos * doc/grep.in.1: Fix troff typos found by mandoc and groff. Problem reported by Bjarni Ingi

bug#71079: bug#71013: Bug Report: Unexpected Termination of grep Process

On 2024-05-17 05:52, Joseph Joshua wrote: 1. Run the following command as part of a build process: grep -r 'pattern' /path/to/directory Please give us a way to reproduce the bug; including the actual pattern that you're using. Otherwise we won't be able to help. Also, please reply to <71...@

bug#68989: grep -m[2+] > /dev/null

On 2024-05-12 22:26, Grisha Levit wrote: Just noticed that with this patch grep has extra output when -m is used with -[lLq]: $ echo x | grep -l -m1 . x (standard input) $ echo x | grep -q -m1 . x Thanks for letting us know; I've reopened the bug report.

bug#70540: grep -c -r | grep -v ':0$'

On 4/25/24 13:10, Dale R. Worley wrote: One further thing, I haven't written any updates to the manual page or .texi. Does anyone have suggestions for a good way to do that? If you have time, just edit those two files and include the edits as part of your patch. If not, I can write that part

bug#70540: grep -c -r | grep -v ':0$'

On 4/23/24 11:32 AM, Dale R. Worley wrote: However, it seems "natural" to me that "grep -c -l", that is, "grep --count --files-with-matches", should give me this result. Yes, that sounds reasonable. Is your patch a trivial one (10 lines or less)? If so, please send it in. If not, please send i

bug#70511: Option to grep into compressed files

Thanks for the suggestion. You're right, this would be better than zgrep etc. I have some qualms though, as the new option would increase the attack surface for 'grep', in that you could then execute arbitrary code by passing certain options to 'grep'. Is there some safer way to get what you

bug#15444: One character can be lost if colors are enabled

On 3/27/24 02:15, Egmont Koblinger wrote: The problem is that if you're at the bottom of the screen and autowrapping occurs, the entire new line is added with the currently active background color, which might not be the terminal's default background color. If that new line isn't filled with text

bug#15444: One character can be lost if colors are enabled

On 3/25/24 08:49, Vincent Lefevre wrote: This works fine in Xterm, giving on a 80-column terminal: ... However, this triggers the bug in GNOME Terminal (and other libvte-based terminals): That's not good. Is there some escape sequence that will work on both xterm and libvte? I assume the s

bug#69929: Can grep -q report matches in incomplete lines?

On 2024-03-24 23:47, Gary Johnson wrote: grep is small enough in concept that it shouldn't require the user to read anything outside of the man page. Maybe grep's concept is simple, but the program itself is not that simple. For example, the grep man page doesn't document all the ins and outs

bug#69929: Can grep -q report matches in incomplete lines?

On 2024-03-24 06:06, David G. Pickett wrote: Perhaps the man page should warn users that such last lines are ignored. They aren't ignored. And the documentation already covers this issue, on its very first page: https://www.gnu.org/software/grep/manual/html_node/Introduction.html This say

bug#69929: Can grep -q report matches in incomplete lines?

On 3/22/24 12:25, Dennis Clarke via Bug reports for GNU grep wrote: Old Solaris 8, once fully patched, was definately compliant with SUSv2 which is all of POSIX.1b-1993, POSIX.1c-1996 POSIX does not specify the behavior of grep when the input is not a text file, and a file that ends in a non-n

bug#69929: Can grep -q report matches in incomplete lines?

On 3/21/24 06:57, Niels Möller wrote: I'm having grep -q read input from a pipe. I would like grep to exit successfully as soon as a match occurs, without requiring the line to be terminated by newline or EOF (unless the grep pattern includes '$', that is). Grep used to behave almost that way.

bug#68989: grep -m[2+] > /dev/null

Thanks for the bug report. I installed the attached patch; please give it a try.From b9a8047099d2388c15e6ad39e7b8c91c6633096c Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 9 Feb 2024 01:06:49 -0800 Subject: [PATCH] =?UTF-8?q?grep:=20fix=20=E2=80=98grep=20-m2=20pattern=20/dev/null=E2=80

bug#68776: bug with escape characters in pattern

On 2024-01-27 16:00, Brendan Richardson wrote: If you use input egrep "[^\\n\\t]" file and the file contains a line with only n or t on it, those lines are also This is the correct behavior. The command you mention is equivalent to grep -E '[^nt\]' file and this outputs all lines containing

bug#68666: warning if --exclude-dir arg contains /?

On 2024-01-22 15:48, Karl Berry wrote: Would it be crazy for grep --exclude-dir=foo/bar to give a warning? Since, as I understand it, any non-trailing / in the arg can never match since the arg is matched against the basename. That's not quite true, as it can match command-line arguments. Fo

bug#68592: Grep 3.1 does not recognize regex beginning-of-line and end-of-line anchors (^ and $). on RHEL 8.9

On 2024-01-19 17:22, Sam James wrote: If you cannot reproduce this with the latest release of GNU grep (3.11), please report it to RHEL instead. It works OK for me with 3.11. For what it works, it also works for me with grep 3.1 running on RHEL 8.5, in the C locale. One possibility is that

bug#66582: annoying, needless warning messages from [fe]grep

On 2023-10-16 20:28, Sam James wrote: grep is not from coreutils. As for the issue you discuss, it's being brought up on the grep mailing lists already I moved this new bug report to the grep package and merged it with the grep mailing list discussions, which already pretty much eliminated usi

bug#66289: localeinfo.c:33:39: error: macro "static_assert" requires 2 arguments, but only 1 given

On 10/4/23 13:09, Dennis Clarke via Bug reports for GNU grep wrote: /opt/bw/build/grep-3.11_netbsd_9.3_sparcv9.002/src/dfasearch.c:159: undefined reference to `re_set_syntax' So, you didn't build the regex library that came with grep ... --without-included-regex ... and this is your probl

bug#66289: localeinfo.c:33:39: error: macro "static_assert" requires 2 arguments, but only 1 given

On 2023-09-30 20:30, Dennis Clarke via Bug reports for GNU grep wrote: I was trying to build GNU grep on a NetBSD 9.3 machine when I saw this nasty bit of business : I just now built grep 3.11 on NetBSD 9.3 x86-64, and didn't run into any problems. /usr/pkg/gcc10/bin/gcc The default GCC

bug#66002: [PATCH] build: suppress suggest-attribute=cold warnings

On 9/15/23 08:45, Gleb Fotengauer-Malinovskiy wrote: Following the glibc commit glibc-2.38~298 ("Mark various cold functions as __COLD"), GNU grep build with -flto flag triggers a GCC warning: sigsegv.c: In function ‘stackoverflow_deinstall_handler.part.0’: sigsegv.c:1441:1: error: function migh

bug#65724: intel-platform-vsec-dkms IN UBUNTU

On 2023-09-03 01:49, Clemen Hajian wrote: Please how to fix intel-platform-vsec-dkms IN UBUNTU via Terminal Sorry, but I don't see what Intel's vendor-specific extended capability has to do with GNU grep. Perhaps you sent the email to the wrong email address? For now, I'm closing the bug r

bug#65722: Bug in your grep tool

On 2023-09-03 21:51, Seth David Schoen wrote: You submitted this bug to the GNU grep project, but based on your man page excerpt, the version of grep on your system is not actually GNU grep, but rather some form of BSD grep (a different implementation with a different code base). Thanks for fol

bug#65416: Feature request: include first line of file in output

On 8/21/23 13:37, arn...@skeeve.com wrote: it solves your problem NOW, instead of waiting for a feature that the grep developers aren't likely to add. Yes, Grep already has a lot of features that in hindsight would have better addressed by saying "Use Awk".

bug#65238: grep can not using *.bat file pattern

On 2023-08-12 15:27, Dimitry Andric wrote: However, in most cases it is easier to use Cygwin or MinGW, which provide Unix-like shells and all the familiar tools, including a working grep! :-) Thanks for explaining. Closing the bug report.

bug#65238: grep can not using *.bat file pattern

On 2023-08-12 00:50, moonhk wrote: I am using choco to install grep on Windows 10. As I don't know what choco is, I can't be of much help. I suggest writing to the choco folks, whoever they are, as it's the MS-Windows port that is the problem. Upstream maintainers like me don't know MS-Wind

bug#65238: grep can not using *.bat file pattern

On 2023-08-11 17:44, moonhk wrote: F:\shell grep -i call *.bat grep.exe: *.bat: Invalid argument Please consult whoever did your MS-Windows port. It's not a problem that occurs on GNU/Linux.

bug#65046: Error in the "grep" documentation, section "2.1.7 Other Options": "--"

Thanks for reporting that. I installed the attached patch.From 13fd8279e5fdd15ba711cf6e5eadeece89e85909 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 5 Aug 2023 14:58:09 -0700 Subject: [PATCH] doc: clarify -- role This should fix bug#65046 reported by Helmut Waltzmann. --- doc/grep.in

bug#64887: grep build for windows `grep.exe` not working.

On 2023-07-26 18:28, Sajjad Ali wrote: Is there a different way to build GNU softwares for windows. WSL 2 should be much less painful. With MSYS2 you have several options and could try some of the other options. Again, I'm the wrong person to ask about this. You'll need some expertise in the

bug#64879: Error: obstack.c: In function '_obstack_allocated_p':

On 2023-07-26 11:15, Sajjad Ali wrote: no error while ./bootstrap​ and ./configure​. when running make​ after a while it throws error: Try './configure --disable-gcc-warnings', since you're getting false alarms. PS. ./bootstrap requires some expertise. If you use it you need to know the qui

bug#64848: /usr/bin/autopoint: line 505: /usr/share/gettext/archive.dir.tar.xz: No such file or directory

On 2023-07-25 02:49, Sajjad Ali wrote: /usr/bin/autopoint: line 505: /usr/share/gettext/archive.dir.tar.xz: No such file or directory You need to install development packages, not just end-user packages. So for gettext you need 'gettext-devel' or something like that. Here's what I see on Fed

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

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.From d4d8abb39eb02c555f062b1f83ffcfac999c582f Mon Sep 17 00:00:00 2001

bug#64277: [feature request] handle files encoded in utf-16le

On 2023-06-24 14:23, Jeremy Hetzler wrote: I would like to request a feature to be added to grep which would enable it to transparently decode UTF16-LE files so they can be conveniently searched. Not sure it's worth the effort as this format is not that common for GNU grep, it'd be a pain to a

bug#63965: grep-3.11: 'make check' fails with glibc-2.37.9000

On 2023-06-09 02:14, Carlo Arenas wrote: upgrading to diffutils 3.10 should address that. Thanks, closing the bug report.

bug#63962: possible error in the grep program

On 6/8/23 04:27, Василий Алексеенко wrote: 1) The initial list of IP addresses in the file is formed start_list.txt . 2) Must be removed from the list start_list.txt IP addresses using a larger file exclude_list.txt grep -vF --file=exclude_list.txt start_list.txt > list_grep.txt The line '10

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

On 6/1/23 22:36, L A Walsh wrote: Perhaps it would be a good idea for grep to provide such filtering (displaying <00>, or such) for non-ascii data? You mean, migrate some of less's functionality into 'grep'? I suppose something like that might work, if someone put a lot of time into it, and

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

On 6/1/23 07:50, L A Walsh wrote: I thought binary files were skipped, by default They're not. The '--binary-files=without-match' option enables that behavior. With that option, this issue doesn't come up. if they want to scan binary files as well as text, then positive results should be pr

bug#63819: Gnu `grep '.*'` does not match an empty string.

On 2023-05-31 19:17, Bob Vincent Il (US) wrote: Okay, but `echo ''` does not output an empty string. It outputs a line feed character. The line feed is not considered. Grep looks only for matches of "any part of the line excluding the terminating "

bug#63819: Gnu `grep '.*'` does not match an empty string.

On 2023-05-31 10:18, Bob Vincent Il (US) via Bug reports for GNU grep wrote: I discovered only today that the following commands all behave identically: * grep -q '.*' * grep -q '.\+' * grep -q . * grep -qE '.*' * grep -qE '.+' * grep -qE . No they don't. For exam

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

On 2023-05-30 14:01, g...@tlinx.org wrote: Why is finding the desired text in a binary file not a "positive finding" as it is in a text file? But it is a positive finding. Grep exits with zero status, which is a positive result. There is no perfect solution here. In the old days when 'grep'

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

-8 is found, it will override the values that were provided with PCRE_CFLAGS and PCRE_LIBS. Thank you. Pushed. I installed the attached minor fixup for that, to handle "./configure PCRE_CFLAGS= PCRE_LIBS=".From c3259803fe255fb55f2cfcdf4cf5bd94ae3befdd Mon Sep 17 00:00:00 2001 From: P

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

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 need a new binary_safe slot in struct pcre_comp? Shouldn't the binary_safe stuff be done at compile-ti

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

etter-understood so that we have a workaround we can trust), how about the attached patch instead? From 4ec71b63f9ac0bb27b60e1c9802edcba868099e8 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 21 Apr 2023 11:31:12 -0700 Subject: [PATCH] grep: use PCRE2 JIT only in unibyte locales * src/pcresea

bug#62769: pcre: correct overpessimistic error checking of pcre2_jit_compile()

On 4/11/23 23:08, Carlo Arenas wrote: Yes. but I would probably prefer voiding the return value to make it explicit. Thanks for checking. Casting expressions to void is not our style so I'll omit that (the comment makes things obvious to the reader anyway). So I installed the patch without th

bug#62769: pcre: correct overpessimistic error checking of pcre2_jit_compile()

re as the search will still succeed (albet perhaps more slowly). From 27864f5d0cfd7dcb704c6ba1afe1dfdcc7456925 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 11 Apr 2023 15:10:06 -0700 Subject: [PATCH] grep: make -P survive JIT compilation failure * src/pcresearch.c (Pcompile): Ignore fa

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

On 2023-04-07 22:01, Carlo Arenas wrote: Not sure I follow the whole logic here, but PCRE2[3] (search for "general category" which is what the "gc" above stands for) only supports the abbreviated form of the unicode classes and `Nd` is indeed the one that corresponds to `Decimal_Number`. That'

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

On 2023-04-06 06:39, demerphq wrote: Unicode specifies that \d match any digit in any script that it supports. "Specifies" is too strong. The Unicode Regular Expressions technical standard (UTS#18) mentions \d only in Annex C[1], next to the word "digit" in a column labeled "Property" (even

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

On 2023-04-06 08:45, demerphq wrote: Although this causes pcre2grep to mishandle Unicode characters: $ echo 'Ævar' | pcre2grep '[Ssß]' Ævar it mimics Perl 5.36: $ echo 'Ævar' | perl -ne 'print $_ if /[Ssß]/' Ævar so this seems to be what Perl users expect, despite its infelici

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

On 2023-04-05 12:40, Jim Meyering wrote: (C) preserve grep -P's tradition of \d matching only 0..9, and once grep uses 10.43 or newer, \b and \w will also work as desired. If I understand you correctly, (C) would mean that GNU grep -P, git grep -P, and pcre2grep -u would all use PCRE2_UTF | P

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

On 2023-04-05 11:32, Paul Eggert wrote: in a February 8 commit[1], Philip Hazel changed pcre2grep to use PCRE2_UCP, so this will mean 10.43 pcre2grep -u will behave like 3.9 GNU grep -P did (though 3.10 has changed this). Sorry, due to fumblefingers I gave the wrong URL for [1]. Here

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

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 pcre2grep does. It has always done only 8-bit processing unless you u

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

On 4/3/23 23:56, Carlo Arenas wrote: On Mon, Apr 3, 2023 at 2:38 PM Paul Eggert wrote: on March 23 Git disabled the use of PCRE2_UCP in PCRE2 10.34 or earlier[6], due to a PCRE2 bug that can cause a crash when PCRE2_UCP is used[7]. A bug fix[8] should appear in the next PCRE2 release

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

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? In the example Ævar supplied in , my impression was that it was

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

On 2023-04-03 23:35, arn...@skeeve.com wrote: Why in the world does grep even care about timestamps on files? The same reason 'awk' does. grep calls stat, fstat, etc., and the call fails with errno == EOVERFLOW if the file's timestamp is past the year 2038. For the same reason I expect that

bug#62657: PCRE2-related workarounds that GNU grep might need

On 2023-04-03 23:17, Carlo Arenas wrote: On Mon, Apr 3, 2023 at 2:50 PM Paul Eggert wrote: * Disable PCRE2_UCP unless PCRE2 10.35 or higher. this is because of a bug in JIT, alternatively JIT could be disabled Oh, that might be better as it doesn't affect behavior (just perfor

bug#62657: PCRE2-related workarounds that GNU grep might need

Recent commits in Git do the following to work around bugs in PCRE2. Quite possibly GNU grep -P should do the same, when in a UTF-8 locale. * Disable PCRE2_UCP unless PCRE2 10.35 or higher. * If ignoring case and PCRE2_MATCH_INVALID_UTF is defined, then enable PCRE2_NO_START_OPTIMIZE unles

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

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. GNU Bug#62605[1] "`[\d]` does not work with PCRE" has

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

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 f grep ^ f Yes, that triggers it. Of course one needs a "touch" and a filesystem that supports su

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

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 restore the grep 3.8 behavior. * NEWS: Mention this. * bootst

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

On 2023-04-03 05:07, Koen Claessen wrote: BTW, if you are interested, I could do a larger more targeted effort stress testing grep like this and possibly find more test cases with unexpected behavior. I would need some guidance on where to put most effort in order to be as useful as this can be.

bug#62605: `[\d]` does not work with PCRE

Also, please see the recent thread about this in the grep-devel mailing list, e.g.: https://lists.gnu.org/r/grep-devel/2023-04/msg4.html

bug#62605: `[\d]` does not work with PCRE

Thanks for reporting the bug with [\d]. This is a known bug and we're working on it; please see: https://bugs.gnu.org/62552 I merged the two bug reports.

  1   2   3   4   5   6   7   8   9   10   >