Re: Possible bug with grep/sed/tail?

Paolo Bonzini wrote: >> A) # tail trace.txt | grep "com" >> - WORKS: produces output >> B) # tail trace.txt | grep "com" | cat >> - WORKS: produces output >> C) # tail -f trace.txt | grep "com" >> - WORKS: produces output, then waits and reports new lines >> D) # tail -f trace.txt | grep "com" | ca

Re: Possible bug with grep/sed/tail?

Karl Berry wrote: > It's probably useful to add this functionality to all coreutil filters. > > Wouldn't it suffice to add buffer control options to cat, rather than > every program? Unfortunately it's the middle of the pipeline that usually causes the buffering issues and so sticking a cat -

Re: Possible bug with grep/sed/tail?

Jim Meyering wrote: > Jim Meyering <[EMAIL PROTECTED]> wrote: >> Andreas Schwab <[EMAIL PROTECTED]> wrote: >>> Paolo Bonzini <[EMAIL PROTECTED]> writes: >>> alias line-buffer='preload /t/linebuf.so' >>> If you end the alias expansion with a space then the next word is also >>> expanded as an

Re: Possible bug with grep/sed/tail?

Jim Meyering wrote: >> What about adding buffer control to all coretuils filters. >> Is that still a desired feature do you think? > > I don't relish the idea of adding an option or feature > to each and every filter in coreutils. Especially > considering that this approach solves the problem --

Re: Possible bug with grep/sed/tail?

Jim Meyering wrote: > Pádraig Brady <[EMAIL PROTECTED]> wrote: >> Jim Meyering wrote: >>>> What about adding buffer control to all coretuils filters. >>>> Is that still a desired feature do you think? >>> I don't relish the idea of adding

Re: Possible bug with grep/sed/tail?

Jim Meyering wrote: > Pádraig Brady <[EMAIL PROTECTED]> wrote: >> >> I'm now thinking of 3 options: stdbuf -i -o -e >> The usual use case is: stdbuf -ol >> But you could also do: stdbuf -i4096 -o8192 >> We would warn about redundant combos like: stdb

Re: Possible bug with grep/sed/tail?

Paolo Bonzini wrote: > Jim Meyering wrote: >> Paolo Bonzini <[EMAIL PROTECTED]> wrote: So -ol (that's an el) would mean line-buffered stdout? That has to be equivalent to -o -l, and unless you consider ordering and multiple -l options (e.g., "-i -l -o -l" is ugly), then it doesn

Re: Possible bug with grep/sed/tail?

Jim Meyering wrote: > Brian Dessent <[EMAIL PROTECTED]> wrote: >> Jim Meyering wrote: >>> local setvbuf='__attribute__ ((constructor)) void >>> f () { setvbuf (stdout, NULL, _IOLBF, 0); }' >>> echo "$setvbuf" | gcc -s -include stdio.h -x c - -fPIC -shared \ >>> -o "$

Re: tests/backref-multibyte-slow timeout 5s is too short for my imac 400

t is installed isn't a big deal. > grep's test script could simply test for the new option and skip > the test if it's not available, just as it currently does if timeout > itself is not installed. The important thing is that it be installed > by developers, and we can arr

bug#15724: [PATCH] maint.mk: fix "release" target to build _version

On 10/27/2013 02:30 AM, Jim Meyering wrote: > This fixes a problem Paul noticed with grep-2.15: > > From 4c2f17d2a671eb6fc6ae318647040598f67705cc Mon Sep 17 00:00:00 2001 > From: Jim Meyering > Date: Sat, 26 Oct 2013 19:26:13 -0700 > Subject: [PATCH] maint.mk: fix "release" target to build _versi

bug#16232: [PATCH] grep: make --ignore-case (-i) faster (sometimes 10x) in multibyte locales

Cool so it does this transformation: sed 's/./[\L&\U&]/g' Though multi byte case handling has all sorts of edge cases (pardon the pun), and it may not be always valid to treat each character independently? For example see some of the tests in: http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f

bug#16232: [PATCH] grep: make --ignore-case (-i) faster (sometimes 10x) in multibyte locales

On 01/11/2014 05:40 AM, Jim Meyering wrote: > On Fri, Jan 10, 2014 at 8:52 PM, Jim Meyering wrote: >>> I wonder might this faster path be restricted to a safer but very common >>> input subset of: >>> >>> (MB_CUR_MAX == 1 || (in_utf8 && *c < 0x80)) >> >> That sounds like a good approach. >> Now I

bug#16232: [PATCH] grep: make --ignore-case (-i) faster (sometimes 10x) in multibyte locales

On 01/11/2014 11:33 AM, Pádraig Brady wrote: > On 01/11/2014 05:40 AM, Jim Meyering wrote: >> On Fri, Jan 10, 2014 at 8:52 PM, Jim Meyering wrote: >>>> I wonder might this faster path be restricted to a safer but very common >>>> input subset of: >>>

bug#16232: [PATCH] grep: make --ignore-case (-i) faster (sometimes 10x) in multibyte locales

On 01/12/2014 04:36 AM, Jim Meyering wrote: > On Sat, Jan 11, 2014 at 6:15 AM, Pádraig Brady wrote: >> On 01/11/2014 11:33 AM, Pádraig Brady wrote: > ... >> This is also a good summary of stuff to consider with case: >> http://www.unicode.org/faq/casemap_charprop.html

bug#20826: SEEK_HOLE not supported for ext4 for kernel < 3.1

On 16/06/15 13:47, Eric Blake wrote: > [adding bug-gnulib] > > On 06/16/2015 06:28 AM, Johannes Meixner wrote: >> >>> From one of our (SUSE) kernel developers >> I even got a proposal for a workaround in grep: >> >> --- a/src/grep.c >> +++ b/src/grep.c >> @@ -575,6 +575,17 @@ file_textbin (char *b

Re: grep --color enhancement

Charles Levert wrote: >[ Here is a message sent via private email, > for the benefit of everyone who subscribes > to the bug-grep mailing list. ] > >* On Monday 2005-12-12 at 10:12:01 +, Pádraig Brady wrote: > > >>Hi Charles, >> >> >

[patch #4758] More efficient color output, and don't corrupt multibyte chars

URL: Summary: More efficient color output, and don't corrupt multibyte chars Project: grep Submitted by: pixelbeat Submitted on: Wed 01/04/06 at 16:18 Category

[patch #4758] More efficient color output, and don't corrupt multibyte chars

Follow-up Comment #1, patch #4758 (project grep): I should give some context with this patch: http://lists.gnu.org/archive/html/bug-grep/2005-12/msg3.html ___ Reply to this item at:

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

On 18/04/2025 06:18, Jim Meyering wrote: On Tue, Apr 15, 2025 at 9:17 PM Jim Meyering wrote: ... We're going to have to revise that code. The difference I see is that before rawhide, that fclose would fail. It's perfectly fine for fclose to succeed in this case, as now happens on rawhide (becau