the fix in the attachment.
Best regards,
Tomasz Dziendzielski
From 07805259b9bf3e167847a1cf5308b6c54018b709 Mon Sep 17 00:00:00 2001
From: Tomasz Dziendzielski
Date: Sun, 17 Oct 2021 21:47:28 +0200
Subject: [PATCH] grep: Don't print line if matcher returned nothing
It can happen that re_sea
the fix in the attachment.
Best regards,
Tomasz Dziendzielski
From 07805259b9bf3e167847a1cf5308b6c54018b709 Mon Sep 17 00:00:00 2001
From: Tomasz Dziendzielski
Date: Sun, 17 Oct 2021 21:47:28 +0200
Subject: [PATCH] grep: Don't print line if matcher returned nothing
It can happen that re_sea
ng the patch with the fix in the attachment.
Best regards,
Tomasz DziendzielskiFrom 07805259b9bf3e167847a1cf5308b6c54018b709 Mon Sep 17 00:00:00 2001
From: Tomasz Dziendzielski
Date: Sun, 17 Oct 2021 21:47:28 +0200
Subject: [PATCH] grep: Don't print line if matcher returned nothing
It c
ch with the fix in the attachment.
Best regards,
Tomasz Dziendzielski
From 07805259b9bf3e167847a1cf5308b6c54018b709 Mon Sep 17 00:00:00 2001
From: Tomasz Dziendzielski
Date: Sun, 17 Oct 2021 21:47:28 +0200
Subject: [PATCH] grep: Don't print line if matcher returned nothing
It can happen that re_
the fix in the attachment.
Best regards,
Tomasz Dziendzielski
0001-grep-Don-t-print-line-if-matcher-returned-nothing.patch
Description: Binary data
at I think grep should also ignore the non-maching/bad character
instead of printing them.
Best regards,
Tomasz Dziendzielski
pon., 18 paź 2021 o 06:08 Paul Eggert napisał(a):
> On 10/17/21 15:15, Tomasz Dziendzielski wrote:
> > It's being printed even when re_search in EGexecute
scape any
incorrect lowercase characters, for example:
>>>re.search("\j","j", re.IGNORECASE)
re.error: bad escape \j at position 0
Due to that I think grep should also ignore the non-maching/bad character
instead of printing them.
Best regards,
Tomasz Dziendzielski
Also, even if we assume it should return a match (which I think it
shouldn't), then there's a second bug in print_line_middle, because why
would it print anything if there was no match?
Best regards,
Tomasz Dziendzielski
e sure it's not printed. That would make my
patch correct.
Reference:
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_03_03
Looking forward to feedback.
Best regards,
Tomasz Dziendzielski
pon., 18 paź 2021 o 07:10 Tomasz Dziendzielski <
tomasz.dziendzi
ot; even though it doesn't match anything. With
my patch it correctly does not print the string but I think for consistency
it also requires adaptations in case --color was not passed. I'll try to
work on that.
Best regards,
Tomasz Dziendzielski
A different inconsistency is in gnulib regex also, which matches 'a' to
'\a' but do not match the same if case insensitive is set. I'll still try
to work on that.
Best regards,
Tomasz Dziendzielski
pon., 18 paź 2021, 17:39 użytkownik Tomasz Dziendzielski <
tomasz.dzie
se but I don't think we
want to change it globally, so I think my patch should be fine and not
affect optimization.
Please check the attachment. If the patch is fine should I also send this
to gnulib mailing list to have it submitted or is this one enough?
Best regards,
Tomasz Dziendz
d as a consequence match is not
found.
If we apply the patch grep is able to match the '\a' correctly. The patch
has nothing to do with improving performance, if was just an additional
comment from my side that the fix should not affect the performance (in my
opinion). Sorry for confusion.
Best regards,
Tomasz Dziendzielski
t's not preserving
correctness.
Best regards,
Tomasz Dziendzielski
śr., 20 paź 2021 o 03:10 Tomasz Dziendzielski <
tomasz.dziendziel...@gmail.com> napisał(a):
> >> I found that for optimization purposes common cases in
> re_string_peek_byte
> >> are missed if p
14 matches
Mail list logo
