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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-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/pcresearch.c

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

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

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 failure

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`.

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

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 |

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's

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

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

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 performance

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

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"

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

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. *

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

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.

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

On 2023-04-01 23:52, arn...@skeeve.com wrote: It's interesting, as gawk uses the same regex, but with different flags. Also, GNU grep -w passes the following more-complicated regexp to dfaparse: (^|[^[:alnum:]_]))|a)|())*)([^[:alnum:]_]|$) and quite possibly the bug is related to this

bug#62272: Erroneous claim in grep man page

le the wording back a bit there too. I installed the attached doc patch, which I hope fixes these problems. (It also fixes a couple of troff typos I noticed in the neighborhood.)From 15f1f50e20e7bf615f338a6e064955fff9e4ab67 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 20 Mar 2023 00:20

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

the attached patch which shouldn't hurt but which I don't know fixes the bug.diff --git a/ChangeLog b/ChangeLog index dfce1a8df7..f42e2ede30 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,17 @@ +2023-03-19 Paul Eggert + + test-pselect, test-select: use different ports + I have observed rare and hard

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

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-edge PCRE2_EXTRA_ASCII_BSD macro if available? Something like

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

le? Something like the attached patch, say. This patch doesn't take your \D fixes (or the above suggestions) into account. From ed7fa801963aaf526f7725741d095c80ad944731 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 19 Mar 2023 01:23:51 -0700 Subject: [PATCH] grep: forward port to PCRE2 10

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

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? Are these incompatibilities documented anywhere? Is the goal for 'grep -P' to be compatible with

bug#62003: Report a bug

On 3/6/23 05:54, Belinda Maxwell wrote: How can I undo this one my phone which is Huawei p8 lite 2017. This is the error I'm getting When FILE is '-', read standard input. With no FILE, read '.' if recursive, '-' otherwise. With fewer than two FILEs, assume -h. Exit status is 0 if any line is

bug#36148: Debian Bug#930247: grep: does not handle backreferences correctly, violating POSIX

On 2023-01-20 01:51, Santiago Ruano Rincón wrote: I'll clone the bug in Debian (and adjust severities), to make it easier to follow/differentiate both bugs. Paul, do you want me to do the same in debbugs.gnu.org? Please don't bother, since the bug is already fixed upstream.

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

On 2023-01-12 21:54, Carlo Arenas wrote: On Thu, Jan 12, 2023 at 7:38 PM Paul Eggert wrote: Fair enough, this will likely need a new test though, and of course changes to the current ones as well. Right now they will report that grep doesn't have '-P' support instead of reporting

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

the wrong thing.From ad986ac2a50f98a8731a141a2d55c49b613e48e5 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 12 Jan 2023 19:35:08 -0800 Subject: [PATCH] grep: diagnose no UTF-8 support (Bug#60708) * src/pcresearch.c (Pcompile): Issue a diagnostic and exit instead of misbehaving if libpcre2 does not s

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

On 1/11/23 14:12, Carlo Arenas wrote: pcre2_config does a static check (defined at compile time) and therefore is unlikely to fail and might be even under the right circumstances optimized out. Not sure what is meant by "static check" here. The call won't be optimized out unless you compile

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

On 2023-01-10 21:37, Jim Meyering wrote: + uint32_t unicode = 1; + pcre2_config (PCRE2_CONFIG_UNICODE, ); + if (unicode && localeinfo.multibyte) Shouldn't that be: uint32_t unicode; if (localeinfo.multibyte && 0 <= pcre2_config (PCRE2_CONFIG_UNICODE, ) && unicode) That

bug#60690: [PATCH v2] grep: correctly identify utf-8 characters with \{b, w} in -P

On 1/9/23 11:51, Ævar Arnfjörð Bjarmason wrote: /b: 155781 (*UCP)/b: 46035 /s: 0 (*UCP)/s: 0 /w: 142468 (*UCP)/w: 9706 So the output still differs, and some of those differences may or may not be

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

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 file matches $ printf '\300\n' | grep -P '\b' $ Plain grep

bug#60690: [PATCH v2] grep: correctly identify utf-8 characters with \{b, w} in -P

On 1/9/23 03:35, Ævar Arnfjörð Bjarmason wrote: You almost never want "everything Unicode considers a digit", and if you do using e.g. \p{Nd} instead of \d would be better in terms of expressing your intent. For GNU grep, PCRE2_UCP is needed because of examples like what Gro-Tsen and Karl

bug#60506: feature: parallel grep --recursive

On 2023-01-02 18:34, Paul Jackson wrote: There's no need for special logic in grep to run parallel grep's. There might be, if one wants to use a parallel grep to search a single large file.

bug#36148: Debian Bug#930247: grep: does not handle backreferences correctly, violating POSIX

b061d24916fb9a14da37a3f2a05cb80dc65cfd38 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 5 Dec 2022 14:16:45 -0800 Subject: [PATCH] grep: bug: backref in last of multiple patterns * NEWS: Mention this. * src/dfasearch.c (GEAcompile): Trim trailing newline from the last pattern, even if it has back-references and follows a pattern

bug#59639: Is this a bug?

On 2022-11-27 09:29, Klaus Dittrich wrote: grep  gdk* file.txt You should quote the pattern for the shell, e.g.: grep 'gdk*' file.txt You can see what's going on by using the shell command 'set -x' before running 'grep'.

bug#58134: grep for windows Include GLOB pattern with double star doesn't seem to work

On 9/27/22 16:19, Alex Benoit via Bug reports for GNU grep wrote: However, this worked: grep -rl --include="*.xml" foo . Is the double star supported on Windows? Yes and no. It's a POSIX glob, which means "**" is equivalent to "*", and that's what's supported. Whether it's MS-Windows

bug#58134: grep for windows Include GLOB pattern with double star doesn't seem to work

On 9/28/22 10:29, Alex Benoit wrote: For instance, if I run the grep command from /, and I have the files: /a/b/folder/file.xml /a/b/file2.xml /a/folder/file3.xml /folder/file4.xml I want to match the file.xml, file3.xml and file4.xml, but not file2.xml, because it is not under a folder named

bug#58096: support malloc NULL return

On 9/26/22 02:19, Aleksandar Kostadinov wrote: Can grep be updated to also support a NULL return value? No need for an update, as grep has done that for many years. This is a configuration problem on the part of the memkind user. See:

bug#57604: Bug#1019724: warning: stray \ before - causes autopkgtest failure

On 9/19/22 05:32, Santiago Ruano Rincón wrote: as you can read below, there are 4235 packages including the warning in their build logs. Funnily, grep is also in the list :-) Grep is on the list because Debian indirectly requires ucf to build Grep, and ucf issues the warning about stray \

bug#57696: grep: Document that GREP_COLORS requires --color

From: Paul Eggert Date: Fri, 9 Sep 2022 13:12:24 -0500 Subject: [PATCH] doc: improve GREP_COLORS doc (Bug#57696) --- doc/grep.in.1 | 5 +++-- doc/grep.texi | 3 +-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/grep.in.1 b/doc/grep.in.1 index 0423866..5b3123d 100644

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

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 report doesn't say that apt-file fails to work, only that apt-file issues a warning and then goes on to work. Transitioning away

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

On 9/7/22 03:02, Simon Josefsson via Bug reports for GNU grep wrote: $ grep '\Q' /dev/null grep: warning: stray \ before Q $ grep '[:alpha:]' /dev/null grep: character class syntax is [[:space:]], not [:space:] Is the use of diagnostic warnings like this supported by POSIX? Yes, POSIX says

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

On 9/6/22 15:33, Karl Berry wrote: Since it bothers you to use POSIXLY_CORRECT, let's invent some other envvar that turns off the warning, like "PLEASE_LET_ME_USE_EFGREP_I_DONT_CARE_ABOUT_POSIX", and Arnold and I will set it and life can go on. Python has PYTHONWARNINGS. I suppose GNU Grep

bug#57613: grep man page tries to rewrite POSIX history

check this now. I installed the attached which I hope clears this up. From 216f754287f2123f45d274f0a003182524efd43d Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 6 Sep 2022 13:52:12 -0500 Subject: [PATCH] Fix obsolescence doc for egrep, fgrep --- doc/grep.texi | 6 +++--- 1 file

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

On 9/5/22 17:07, Karl Berry wrote: I have hundreds of scripts that use [ef]grep since for many years they were either the only, or then later the most portable, way to get the behavior. Actually, egrep and fgrep were not entirely portable even before POSIX deprecated them in 2001. For

bug#57399: etiquette / GPL question

On 8/25/22 10:25, Terence Kelly wrote: Shall I cc: Jim Meyering too? Yes please.

bug#57399: etiquette / GPL question

On 8/24/22 22:55, Terence Kelly wrote: (Plan Zero)  Write a little shell script that (a) downloads the grep-3.7 tarball, (b) unpacks it, (c) applies a small patch to a single .c source file, which adds roughly ten new lines of code, (d) builds the grep executable by calling ./configure, make,

bug#56843: grep mangling lines

On 7/30/22 17:42, David G. Pickett wrote: Any clues on how I got an xterm to mess up? Presumably by sending that sequence of escape characters to xterm. You should be able to reproduce the problem by using grep --color=always and sending the output to a file F, and then by typing 'cat F'.

bug#56843: grep mangling lines

I'm not seeing the problem on Ubuntu 22.04 LTS, using grep 3.7 and GNOME Terminal 3.44.0 using VTE 0.68.0 +BIDI +GNUTLS +ICU +SYSTEMD. The output isn't even colored unless I pass something like '--color=always' to 'grep', which leads me to wonder whether you're using an alias for 'grep'

bug#56453: 回复： 回复： bug#56453: Bug reports

On 7/9/22 05:16, GUI wrote: Thank you very much.I think there are something wrong with my expression. grep Download When you type something, hitting grep will do a row match The "grep Download" command has no file.So it is the case that"If no FILE is given, recursive searches examine the

bug#56453: 回复： bug#56453: Bug reports

On 7/8/22 21:53, GUI wrote: " If no FILE is given, recursive searches examine the working directory, and nonrecursive searches read standard input. "You use the word 'and' to say 'If no FILE is given' when this happens, 'recursive searches Examine the working directory' and 'nonrecursive

bug#56453: Bug reports

On 7/8/22 06:35, GUI via Bug reports for GNU grep wrote: [root@localhost ~]# grep Download dwad dawdwa Downloads Downloads ^C [root@localhost ~]# It looks like you typed the string "grep Download dwad dawdwa Downloads Downloads" and then typed control-C. This caused the shell to not execute

bug#56352: bug#56350: UTF-8 LC_CTYPE bug esp when a certain range of Korean characters

Thanks, that's a Gnulib bug that was fixed here: https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=b19a10775e54f8ed17e3a8c08a72d261d8c26244 This has been propagated to GNU Grep and the fix should appear in the next Grep release. I plan to reply separately about GNU Sed.

bug#56079: Missing performance optimisation: Word start/end tests

On 6/19/22 00:38, sur-behoffski wrote: a\[def] Yes, and this comes up even in strict POSIX without GNU extensions, as "a^" is a valid extended regular expression that cannot match anything. I don't know whether dfa.c, regex.c, etc. optimize for this, but if not it would be nice if

bug#56077: Pattern Beginning With Dash Throws Error

On 6/18/22 15:05, gazip--- via Bug reports for GNU grep wrote: I just encountered a problem where when the search pattern starts with a dash, grep interprets it as an argument parameter. That's normal for grep. See question 3 of: https://www.gnu.org/software/grep/manual/html_node/Usage.html

bug#55641: Using colours with grep

On 5/29/22 08:40, Jim Meyering wrote: Adding a test for the new behavior would be nice. OK, thanks, I installed the new warning and followed up with the attached patch to test it.From d85711f6945f79443bbb51b4d0f668a91a163e50 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 29 May 2022

  1   2   3   4   5   6   7   8   9   10   >