Hello,
This is a small addition to a recent change:
1cec27a7f0e5c7bdc44a88ef51af09f87a8cbc24
grep: use errno consistently in write diagnostics
With the above change, if SIGPIPE is set to 'ignore' (e.g. by the shell or
python),
then grep would exit with "write error: Broken Pipe".
Based on
Zev Weiss wrote:
The original question asked about colorizing both patterns in the output of
grep word1 | grep word2
(i.e. lines that contain *both* word1 and word2)
I interpreted the original question the other way. Now that I reread it, it
appears to be ambiguous.
This bug report does
On Sun, Apr 10, 2016 at 09:45:49PM -0700, Paul Eggert wrote:
This works for me:
grep --color=always -E 'word1|word2'
Isn't that a different search? The original question asked about
colorizing both patterns in the output of
grep word1 | grep word2
(i.e. lines that contain *both* word1 a
Jim Meyering wrote:
With this fix, I would like to make yet another grep release.
Does anyone have any pending changes we should consider?
I did a bit of bug triage, closing some bug reports and fixing one minor
documentation bug (Bug#22911). I didn't see any pending changes that can't wait
u
This is following up on:
http://bugs.gnu.org/22239
Could you please supply some specific test cases to illustrate the problem? I'm
not seeing it, but this could be because I'm not using your locale, or am using
machine-generated patterns. I am using master grep in the C locale on Ubuntu
15.10
No further comment, so I'm closing the bug report.
As this bug now appears to be fixed in grep master (or at least, as fixed as
well as libpcre will allow), I'm closing it.
On Sun, Apr 10, 2016 at 2:59 PM, Zev Weiss wrote:
...
> Well, I still have my multithreading patch series
> (https://github.com/zevweiss/grep/) awaiting review, which I'd hope to get
> applied at some point, though I'd guess it's enough of a review task that
> delaying an impending release for it
This works for me:
grep --color=always -E 'word1|word2'
Now that you have confirmed that the warnings are harmless,
they don't bother me.
Thanks, closing the bug report.
Thanks for the bug report. I installed the attached, which is not quite the same
as the patches you suggested, but which should address the issues.
From 0269180966fe6e084b8d8af1a61a3d521ad7e081 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sun, 10 Apr 2016 21:27:35 -0700
Subject: [PATCH] grep:
On 04/10/2016 02:59 PM, Zev Weiss wrote:
I still have my multithreading patch series
(https://github.com/zevweiss/grep/) awaiting review, which I'd hope to
get applied at some point, though I'd guess it's enough of a review
task that delaying an impending release for it isn't likely (the
mbtou
On Sun, Apr 10, 2016 at 02:10:08PM -0700, Jim Meyering wrote:
On Sun, Apr 10, 2016 at 1:43 AM, Paul Eggert wrote:
Paul Eggert wrote:
I plan to change GNU grep to use this new facility, and to add some grep
test
cases for this issue.
I did that by installing the attached patches into the gr
On Sun, Apr 10, 2016 at 1:43 AM, Paul Eggert wrote:
> Paul Eggert wrote:
>>
>> I plan to change GNU grep to use this new facility, and to add some grep
>> test
>> cases for this issue.
>
>
> I did that by installing the attached patches into the grep master. This
> fixes the bug for me, so I'm clo
Paul Eggert wrote:
I plan to change GNU grep to use this new facility, and to add some grep test
cases for this issue.
I did that by installing the attached patches into the grep master. This fixes
the bug for me, so I'm closing the bug report.
These patches mostly just report the fix and ad
15 matches
Mail list logo
