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

on 10+ files fails with "Operation not > supported" > > On 2023-07-20 23:43:45 -0300, Santiago Ruano Rincón wrote: > > El 21/07/23 a las 04:06, Vincent Lefevre escribió: > > > On 2023-07-21 03:30:12 +0200, Vincent Lefevre wrote: > > > > There i

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

El 05/12/22 a las 23:36, Thorsten Glaser escribió: > Paul Eggert dixit: > > > Although you sent your email to 36...@debbugs.gnu.org / > > 930247@bugs.debian.9org, your email is reporting a separate bug > > Oh OK, I wasn’t aware, it sounded similar enough. I'll clone the bug in Debian (and adjust

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

El 18/09/22 a las 07:57, Lucas Nussbaum escribió: > Hi, > > On 16/09/22 at 21:35 +0200, Paul Gevers wrote: > > Hi Santiago, > > > > On 15-09-2022 09:26, Paul Gevers wrote: > > > I am trying to schedule autopkgtests in unstable on amd64 for all source > > > packages that have one. > > > > All res

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

El 13/09/22 a las 12:59, arn...@skeeve.com escribió: > Sam wrote: > > > I honestly think at this point, it'd be better to just deem them GNU > > extensions. > > I agree with this, wholeheartedly. FWIW. > > Arnold FWIW, {e,f}grep have been reintroduced in Debian with grep 3.8-2. Now, the stray

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

Tags: patch Dear grep upstream developers, Please, consider the attached patch to document that the GREP_OPTIONS environment variable requires the --color option to be taken into account. This is to solve https://bugs.debian.org/792385 Cheers, -- Santiago Description: Document that --color ir

bug#27763: egrep.sh: grep missing path

El 19/07/17 a las 02:56, Paul Eggert escribió: > Santiago Ruano Rincón wrote: > > > As suggested by this user, it would be better if egrep/fgrep script > > calls grep using its absolute path. > > Debian bug 863002 doesn't explain why it would be better, as the origi

bug#27763: egrep.sh: grep missing path

Control: tags -1 + patch Hi, As suggested by this user, it would be better if egrep/fgrep script calls grep using its absolute path. On Fri, 19 May 2017 22:04:44 +0100 john mullee wrote: > Package: grep > Version: 2.20-4.1 > > cat /bin/egrep > #!/bin/sh > exec grep -E "$@" > > shoul

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

El 23/07/16 a las 09:31, Jim Meyering escribió: > On Wed, Jul 20, 2016 at 2:58 PM, Jim Meyering wrote: > > On Wed, Jul 13, 2016 at 1:59 AM, Santiago Ruano Rincón > > wrote: … > Here are two patches. > The first adds coreutils' perl-based test harness to grep. &

bug#24024: grep: Mixing "max-count" and "after-context" outputs too few lines

Hi, Igor Bogomazov filed the following bug against grep in Debian. El 18/07/16 a las 14:30, Igor Bogomazov escribió: > Package: grep > Version: 2.25-6 > Severity: normal > > > Given after-context=3 it is expected to output at least 4 lines > as documented, but adding max-count=1 makes it stop

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

Hi, Please find below yet another old-standing bug filed against debian. grep's behaviour is still the same in 2.25. https://bugs.debian.org/525214 Cheers, Santiago - Forwarded message from Gunnar Wolf - Date: Wed, 22 Apr 2009 18:06:28 -0500 From: Gunnar Wolf To: Debian Bug Tracking

bug#23227: Inconsistent behavior for --file=~/some-file

El 05/04/16 a las 16:14, Eric Blake escribió: > On 04/05/2016 04:03 PM, Eric Blake wrote: > > Tilde expansion in the shell is defined by POSIX to only happen if ~ > > occurs as the first character of a word > > > > > Since this behavior is baked into your shell, there's nothing grep can > > do ab

bug#23227: Inconsistent behavior for --file=~/some-file

Hi, grep fails to parse the tilde (~) to represent $HOME, when it is used to give a file's path to --file=, but it works with --file % echo "a" > ~/tmp-pattern % echo "hola" | LANG=C grep --file=/home/santiago/tmp-pattern hola % echo "hola" | LANG=C grep --file /home/santiago/tmp-pattern hola % e

bug#22911: Minor doc changes to clarify the use of multiple -e, -f

And now that I'm cleaning the patches applied to the debian package, here is another tiny patch. Cheers, Santiago >From 1c86cafdc67c157ce8744da0b32151d1e0f77545 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Santiago=20Ruano=20Rinc=C3=B3n?= Date: Fri, 4 Mar 2016 20:01:48 +0100 Subject: [PATCH] doc: co

bug#22911: Minor doc changes to clarify the use of multiple -e,-f

Hi, Please consider this patch to clarify the use of multiple -e and -f options in grep. I think the current documentation is inconsistent with grep behaviour and POSIX man page for grep. This patch is intended to close another long-standing bug reported in Debian: https://bugs.debian.org/356120

bug#22071: incorrect behaviour for inverted matches with -l on empty files

El 01/12/15 a las 22:36, Mark Wotton escribió: > orb ➜ ~/src/grep-2.22 touch empty > orb ➜ ~/src/grep-2.22 ./src/grep -v -l "hi there" ./empty > > gives empty output. Surely the file "empty" should match 'does not match > "hi there"' ? -v, --invert-match Invert the sense o

bug#19998: GREP_OPTIONS alternative?

Hi, El 11/03/15 a las 17:58, Paul Eggert escribió: ... > On the other hand, now that I've tested it, I see that when I type 'fgrep' > Bash invokes it as '/bin/fgrep', which surprises me and which defeats the > purpose of having 'fgrep' look at $0. I installed the attached patch, which > should f

bug#19563: bug#19563: CVE number and trivial NSC follow-up patch

El 01/02/15 a las 08:39, Jim Meyering escribió: > I obtained a CVE number for this flaw and added a reference to it in NEWS. > Also fixed a now-unnecessary "goto" in related code. Hi, I'm running kwset-abuse test, but I don't get any difference with or without the fix for this CVE (in kwset.c). D

bug#15444: [debian-report...@plan9.de: Bug#734147: grep: colorisation corrupts character at end of line]

Hi, Forwarding some user's thoughts about this issue. Hope this helps to solve this bug. Regards, Santiago - Forwarded message from Marc Lehmann - Date: Fri, 05 Dec 2014 06:01:33 +0100 From: Marc Lehmann , To: Debian Bug Tracking System <734...@bugs.debian.org>, Subject: Bug#734147: g

bug#19094: Clean doc/{stamp-vti,version.texi}

El 18/11/14 a las 08:30, Eric Blake escribió: > On 11/18/2014 07:35 AM, Santiago Ruano Rincón wrote: > > Hello, > > > > Please, tell automake to clean doc/stamp-vti and doc/version.texi files. > > > > Sadly, this is not going to work. These files are intention

bug#19094: Clean doc/{stamp-vti,version.texi}

Hello, Please, tell automake to clean doc/stamp-vti and doc/version.texi files. I've come to this minor patch to make it possible to build the grep debian package twice in a row (to build it over an already built directory). Thanks, Santiago diff --git a/doc/Makefile.am b/doc/Makefile.am index

bug#18651: Clarify exit status description

Control: tags -1 + patch El 07/10/14 a las 09:27, Paul Eggert escribió: > Hmmm, well, to me the proposed clarification is not that clear either. And > the man page is no place for a chatty discussion about what POSIX allows of > other implementations; the full manual is the place for that sort of

bug#18651: Clarify exit status description

Hi, I'm attaching to this mail an old proposal to clarify the exit status description, included in the debian package: https://bugs.debian.org/446854 Regards, Santiago From 2432287712e802ce821e3158fb4f40a1a7b8b436 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Santiago=20Ruano=20Rinc=C3=B3n?= Date: T

bug#18454: Improve performance when -P (PCRE) is used in UTF-8 locales

El 17/09/14 a las 23:00, Paul Eggert escribió: > I've installed all the patches mentioned so far. > I've successfully build the latest commit (f6de00f6cec3831b8f334de7dbd1b59115627457), but I don't see any performance boost. Rather the opposite. Comparing with debian's grep 2.20-3, that includes

[patch #8132] Simplify information on EXIT STATUS

URL: Summary: Simplify information on EXIT STATUS Project: grep Submitted by: santiago Submitted on: vie 26 jul 2013 19:40:18 GMT Category: None Priority: 5 - Normal

[patch #8131] Improve documentation regarding PCRE

URL: Summary: Improve documentation regarding PCRE Project: grep Submitted by: santiago Submitted on: vie 26 jul 2013 15:53:32 GMT Category: None Priority: 5 - Normal

[patch #6588] Add --min-count NUM option to only display files with at least NUM matches

Additional Item Attachment, patch #6588 (project grep): File name: min-count.patchSize:4 KB ___ Reply to this item at: ___ Mensaje envi

[patch #7577] `grep -lc' to show only matching files

Follow-up Comment #4, patch #7577 (project grep): Two people filled different bugs in debian asking for the same behavior from grep -lc, and, with my user's hat put on, I found the combination of --count and --files-with-matches clear. grep's man page doesn't say that those options *only* print ma

[patch #7577] `grep -lc' to show only matching files

URL: Summary: `grep -lc' to show only matching files Project: grep Submitted by: santiago Submitted on: mié 13 jul 2011 23:56:25 GMT Category: None Priority: 5 - Normal

Re: Bug#624387: [bug #33198] Incorrect bracket expression when parsing in ru_RU.KOI8-R (Russian locale)

On 02/06/11 23:32, Jim Meyering wrote: > Santiago Ruano Rincón wrote: >> Follow-up Comment #3, bug #33198 (project grep): >> It seems the problem is still unsolved. I've tried both, 2.8 and patching >> 2.7, >> but I got the same results. Igor Ladygin confirms thi

[bug #33198] Incorrect bracket expression when parsing in ru_RU.KOI8-R (Russian locale)

Follow-up Comment #3, bug #33198 (project grep): Hi Jim, It seems the problem is still unsolved. I've tried both, 2.8 and patching 2.7, but I got the same results. Igor Ladygin confirms this. santiago@nomada:~$ echo Пример| LC_ALL=ru_RU.KOI8-R grep -qE "[Пп]"; echo $? 1 santiago@nomada:~$ echo S

[bug #33198] Incorrect bracket expression when parsing in ru_RU.KOI8-R (Russian locale)

URL: Summary: Incorrect bracket expression when parsing in ru_RU.KOI8-R (Russian locale) Project: grep Submitted by: santiago Submitted on: lun 02 may 2011 09:50:04 GMT Category: None