Re: Possible bug with grep/sed/tail?

Brian Dessent <[EMAIL PROTECTED]> wrote: > It has been said before in previous threads but I want to re-state that > this is possible in a very simple and general way with the LD_PRELOAD > facility: > > $ echo '__attribute__((constructor)) void f() { setvbuf (stdout, NULL, > _IOLBF, 0); }' | \ >

Re: Possible bug with grep/sed/tail?

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 alias. Ah, yes. That was it. Thanks ;-)

Re: Possible bug with grep/sed/tail?

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

Re: Possible bug with grep/sed/tail?

Pádraig Brady <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: ... >> Then you can use it e.g., to watch *interactively* filtered tail -f output. >> For example, watch for warnings in build output like this: >> >> make >& log & line-buffer tail -F

Re: Possible bug with grep/sed/tail?

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 an option or feature >>

Re: Possible bug with grep/sed/tail?

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't let you line-buffer more than one of the three stre

Re: Possible bug with grep/sed/tail?

Pádraig Brady <[EMAIL PROTECTED]> wrote: > 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: stdb

Re: Possible bug with grep/sed/tail?

Pádraig Brady <[EMAIL PROTECTED]> wrote: ... >>> tail -f access.log | stdbuf --fd=1 --size=1 cut -d' ' -f1 | uniq >>> >>> size=0 => unbuffered >>> size=1 => line buffered >>> size>1 -> specific buffer size >>> >>> Also we could have aliases for stdin stdout, linebuffered, ... >>> >>> We still have

Re: Possible bug with grep/sed/tail?

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 \ >>

Re: GNU grep 2.5.4 released

Antonio Diaz Diaz wrote: ... > [3] http://www.nongnu.org/lzip/zutils.html Hi Antonio, I would like to distribute compression-stream-agnostic scripts like those in your zutils package via gzip releases. Would you be willing to contribute those to gzip and assign copyright? Jim

20 clean-up csets on "next"

Hi, I've just pushed 20 c-sets to next, here: http://git.savannah.gnu.org/gitweb/?p=grep.git;a=shortlog;h=refs/heads/next Overall summary: use more bits from gnulib and enable some of its syntax-checks (several more to go, see cfg.mk for the list). Object now if you see anything you don't lik

Re: 20 clean-up csets on "next"

Jim Meyering wrote: > I've just pushed 20 c-sets to next, here: > > http://git.savannah.gnu.org/gitweb/?p=grep.git;a=shortlog;h=refs/heads/next > > Overall summary: use more bits from gnulib and enable some of > its syntax-checks (several more to go, see cfg.mk for the l

enable a few more checks

FYI, I've just pushed these: >From 196b828887ae5a92e695b8a75501aacdd5370122 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri, 4 Dec 2009 09:00:07 +0100 Subject: [PATCH 1/4] maint: enable po-check * cfg.mk (local-checks-to-skip): Enable sc_po_check. * po/POTFILES.in: Sort an

Re: [bug #27196] Using -o and -i options together is broken

Paolo Bonzini wrote: > Follow-up Comment #2, bug #27196 (project grep): > > $ echo abcDEF | ./grep -o -i C.E > cDE > $ echo abcDEF | LANG=en_US.ASCII ./grep -o -i C.E > $ > > Happens irregardless of --with/--without-included-regex Hi Paolo, Thanks for all the triage! Note that the first didn't p

[bug #17457] "grep -r foo . > somefile" goes into an infinite loop

Follow-up Comment #2, bug #17457 (project grep): Hi Paolo, That script does not evoke an infinite loop for me on F12 on a tmpfs file system. Does it for you? Of course, switching to fts is definitely worth doing regardless, since it will remove an entire class of limitations. _

enable a few more syntax-checks

>From dc57dad0fd9ccc43e65491e7416652d1437dff30 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri, 4 Dec 2009 23:19:07 +0100 Subject: [PATCH 1/4] maint: enable cast_of_alloca_return_value check * cfg.mk (local-checks-to-skip): Enable sc_cast_of_alloca_return_value. *

[bug #17623] grep -R should NOT follow symlinks

Follow-up Comment #2, bug #17623 (project grep): Hi Paolo, I too have long wished for a way to make grep -R not follow symlinks. My first thought was to handle it like find, cp, du, ls and chown etc. have done, with their -H, -L and -P options, but all of those are already in use with grep. On

[PATCH] fix multi-byte-locale read-beyond-end-of-buffer error

FYI, here's a fix: tests/fmbtest.sh provokes the failure, too, so I'm not planning to add a test case. >From 60a7e46a1c3ff186c373e776958ea02437b686ef Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Wed, 23 Dec 2009 18:59:30 +0100 Subject: [PATCH] fix multi-byte-locale read-

updated FSF copyright year lists

FYI, I've just updated all copyright year lists to include 2010. Just after I pushed that, I noticed that the change also included an update to make grep use the latest version of gnulib. While that's a good thing, it should have at least been mentioned in the commit log.

18 csets coming up

t; -- 1.6.6.334.g442f >From 7f65deb0490da83a2a9d4e58ea45a2c75ca53b4d Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Thu, 24 Dec 2009 17:59:05 +0100 Subject: [PATCH 03/18] maint: avoid compilation warnings * bootstrap.conf (gnulib_modules): Add ignore-value. * src/search.c (check_multibyt

Re: 18 csets coming up

Paolo Bonzini wrote: > On 01/01/2010 04:48 PM, Jim Meyering wrote: >> IMHO, the only one that deserves particular scrutiny is the last one: >> >>maint: use regex from gnulib, rather than our bit-rotting one >> >> There have been almost no changes to the

[PATCH] build: run gnulib's tests, too

My 18-cset series has been side-tracked, as I've explored differences between gnulib's regex code and what's in glibc. For now, here's something independent that I'm pushing: >From 51ad8c98cbbc972d95046771f69421ff3ca5af40 Mon Sep 17 00:00:00 2001 From: Jim Meyering

Re: 18 csets coming up

Jim Meyering wrote: > I expect to push the following in a day or so: > > .gitignore: ignore more > maint: avoid warnings about unused fwrite return value > maint: avoid compilation warnings > fix a possible bug: remove errant semicolon > maint

Re: Naming of "bootstrap" vs "autogen.sh"

Reuben Thomas wrote: > I noticed that grep's autogen.sh was recently renamed bootstrap; does > this prefigure a change to the GNU Coding Standards? It was more than a name change. It indicates my desire for the functionality provided via gnulib's bootstrap script. AFAICS, the GCS is not involved

Re: [bug #28588] -m breaks -A

useful to provide less context that requested in this case, I may well change it. Comments welcome. In the mean time, I've added a test case to exercise the offending behavior. Here it is, though note that it depends on a few preceding patches. I'll push them all shortly: >

FYI, [PATCH] use gnulib's regex code

ained copy) when the libc one is found to be inadequate. [Note, I've removed parts of the diffs below that merely showed lib/reg* being removed. ] >From 74b28d9e9eb457581908d00d09701b6be5aa450a Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Wed, 3 Feb 2010 21:30:16 +0100 Subject: [PAT

Re: FYI, [PATCH] use gnulib's regex code

Paolo Bonzini wrote: > On 02/04/2010 08:55 AM, Jim Meyering wrote: >> +$(PERL) -w$$T_ -I$(srcdir) -MCoreutils >> \ >> + -M"CuTmpdir qw($$f)" -- "$$1";\ > > cut'n'paste? No, it was delibera

[bug #24732] --only-matching prints only non-overlapping matches in each line

Follow-up Comment #2, bug #24732 (project grep): maybe leave open, but as a feature reqest. However, with ambiguity like this, it's good to document (and add a test case demonstrating) the intended behavior. Does any other implementation of grep offer this option? _

[bug #28588] -m breaks -A

Update of bug #28588 (project grep): Status:None => In Progress ___ Follow-up Comment #1: I replied on the mailing list: http://thread.gmane.org/gmane.comp.gnu.grep.bugs/2237/focus=2244

Re: [bug #17457] "grep -r foo . > somefile" goes into an infinite loop

Paolo Bonzini wrote: > Update of bug #17457 (project grep): > > Status:None => Invalid > Open/Closed:Open => Closed > > Follow-up Comment #4: > > Hmm, this cannot be fixed. By definition

Re: [bug #17457] "grep -r foo . > somefile" goes into an infinite loop

Paolo Bonzini wrote: >> Actually, how about detecting this and diagnosing >> the problem rather than falling into the infloop? >> >> This currently evokes an infloop for me: >> >> $ seq 100> k >> $ grep 111 k>> k >> >> However, simply detecting when the output FD is also an input F

Re: grep extremely slow on OSX

Titus von der Malsburg wrote: > When I do a simple grep on a 50Mb file with ~1.3 million lines, it > takes 2s on Linux (Ubuntu karmic with stock kernel, 2.6.31-17) and > ~12min on OSX (v. 10.5.8): > > grep '^[0-9]' < file.dat > /dev/null > > ~1.2 million lines actually begin with a number. Both

Re: compilation warning

Eric Blake wrote: > The build failed for me after ./configure --enable-gcc-warnings, when pcre > development files are not available: > > search.c: In function 'Pexecute': > search.c:729: error: function might be possible candidate for attribute > 'noreturn' [-Wmissing-noreturn] > > Rather than dec

five small patches

write failure, not 1 [PATCH 4/5] tests: correct TESTS_ENVIRONMENT's PATH setting [PATCH 5/5] tests: add help-version sanity tests from coreutils >From b4fb8046603e4a9c32df8cf09ecdd654bc3f4c21 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri, 5 Feb 2010 07:12:44 +0100 Subject: [P

[PATCH] remove useless DJGPP-specific code

Just saw this in the vicinity, so cleaned up: >From 59e615e3fd46ee97ba5009238793ee9b57d3e8dd Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Mon, 8 Feb 2010 10:24:32 +0100 Subject: [PATCH] remove useless DJGPP-specific code * src/grep.c (grepfile): Remove now-useless DJGPP-specific code.

Re: grep -v broken for large pattern lists

Rob Robason wrote: > running the command > > grep -v -F -f pattern-file search-file > > with a large pattern-file (in my case 1234 patterns) fails to yield the > complement of the same command less the -v option. The result is the same > without the -F option, though _much_ slower. > > The patterns

Re: [PATCH] add --group-separator=FOO and --no-group-separator

Paolo Bonzini wrote: > I took inspiration from bug #28906 to implement this. Improvements > to the wording in the manual are welcome. Otherwise okay? Thanks! That looks like a fine change. Adding a line or two in NEWS would nice. It'd be good to mention in the individual descriptions that thes

Re: grep: foad1.sh tests fail for grep 2.5.4 on Mac OS X

ust an extra "-n " at the beginning of > the output line. > > Please let me know if I can be if further assistance. Thanks for the report. Here's a fix for the "-n"-related problems. Once it's applied, do others remain? >From 8f9395ea428a27690e10f55b581c

grep-2.6 is imminent: pending patches, bug reports?

Hello, It's been over a year since the release of 2.5.4, so I would like to make a new release shortly. Paolo Bonzini is about to post a patch or two, and after those are resolved, I will pull the lever for 2.6. If anyone has unresolved problems, please let us know here, as soon as possible. Jim

[PATCH] doc: document release procedure

ep, too: >From 10ab6fb6f239eaef102e71140d425bbca91b12dc Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Thu, 4 Mar 2010 18:01:21 +0100 Subject: [PATCH] doc: document release procedure * README-release: New file. --- README-release | 86 1 files changed, 86 insertio

[PATCH] tests: add a test based on an example from Paolo Bonzini

Here's a new test: >From 29182990773f031a7b39f93a17a05b64fa28e38d Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Thu, 4 Mar 2010 18:24:03 +0100 Subject: [PATCH] tests: add a test based on an example from Paolo Bonzini * tests/word-multi-file: New test. * tests/Makefile.am (TESTS)

Re: grep-2.6 is imminent: pending patches, bug reports?

Aníbal Monsalve Salazar wrote: > On Thu, Mar 04, 2010 at 04:25:57PM +0100, Jim Meyering wrote: >>Hello, >> >>It's been over a year since the release of 2.5.4, so I would like to >>make a new release shortly. Paolo Bonzini is about to post a patch or >>two

Re: grep-2.6 is imminent: pending patches, bug reports?

Hi Arnold, Aharon Robbins wrote: > Has anyone looked at issues with dfa.c? There is a difference in > how dfa handles x{0} from how regex handles it; dfa, IIRC, treats > it as x{1}. Gawk checks for this and doesn't use dfa in such a case, > but it'd be nice if it were fixed. That'd make a ni

Re: grep-2.6 is imminent: pending patches, bug reports?

arn...@skeeve.com wrote: >> echo Y | LC_ALL=en_US.UTF-8 ./grep -i '[y]' > > I think gawk dfa fixes this. It rings a vague bell As it seems it should: This link shows a patch that does solve the problem, and says it comes from gawk's dfa.c. http://patch-tracker.debian.org/patch/series/view/gr

Re: grep-2.6 is imminent: pending patches, bug reports?

charclass.patch had many superfluous casts, but appeared to be semantically equivalent to the dfa.c change below. >From 4a0f966463ed44e90958aa75f048dace7edd3649 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Thu, 4 Mar 2010 22:23:06 +0100 Subject: [PATCH] fix a bug in handling of -i and cha

Re: grep-2.6 is imminent: pending patches, bug reports?

d apply the entire series with "git am FILE". >From 1a4806a05c61137d41f46e2d0db06a0eb2e860eb Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri, 5 Mar 2010 09:48:00 +0100 Subject: [PATCH 1/5] build: avoid shadowing warnings * dfa.c (match_mb_charset): Rename parameter: s/index/idx/. (check_matchin

gawk->grep dfa synchronization

ize-loop maint: dfa-sync: don't malloc zero maint: dfa: sync a comment and dead-to-grep code: no semantic change As such, I'll probably give it a NEWS entry before pushing. >From 11a68fea2d9ec9c54165ce1ecfa25d773477bb70 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri,

feedback on 1..3 [Re: [PATCH 0/6]

Hi Paolo, Thanks for all the work. Paolo Bonzini wrote: > Subject: [PATCH 1/6] fix for bug 21276 > > * lib/savedir.c (isdir1): Use realloc instead of calloc. Remove > dead code. > (savedir): Do not leak name_space if allocation of new_name_space fails. ... I hesitated to address that error-path

Re: Debian patches

Reuben Thomas wrote: > 2010/3/5 Paolo Bonzini : >> On 03/05/2010 11:28 AM, Reuben Thomas wrote: >>> >>> 2010/3/5 Paolo Bonzini: 03-dlopen-pcre.patch        Ialso not appropriate for upstream (not in its current shape        anyway since it should at least use ltdl and not hardco

Re: Debian patches

Reuben Thomas wrote: > I attach a patch for grep.1 and grep.texi which improves the discussion of > PCRE. Thanks. Applied, as below. In the future, please include full git format-patch output, or send with git send-email, including a ChangeLog-style-with-discussion-when-appropriate commit log.

Re: [PATCH] augment case-fold-char-class test case

Paolo Bonzini wrote: > * tests/case-fold-char-class: Test matching lowercase against uppercase > as well as vice versa. > --- > tests/case-fold-char-class | 14 +++--- > 1 files changed, 11 insertions(+), 3 deletions(-) > > diff --git a/tests/case-fold-char-class b/tests/case-fold-char-c

[PATCH 5/6] fix cross-line matching in PCRE backend

Paolo Bonzini wrote: > Subject: [PATCH 5/6] fix cross-line matching in PCRE backend > * search.c (Pexecute): Split the buffer in lines and match each line > separately. > * tests/fedora.sh: Add regression testsuite. Won't this induce a large performance penalty for a buffer with no matches but wit

Re: [PATCH 0/6] *** SUBJECT HERE ***

Paolo Bonzini wrote: > Subject: [PATCH 6/6] allow grep -Pz > > * src/search.c (Pcompile): Remove restriction on grep -Pz. > * tests/pcre-z: New. > * tests/Makefile.am (TESTS): Add pcre-z. Thanks for adding another test. ACK, once you address the nits below. > diff --git a/src/search.c b/src/searc

Re: [PATCH 0/6] *** SUBJECT HERE ***

Paolo Bonzini wrote: >>> +echo a | grep -P a>/dev/null 2>err || skip_ >> >> Please give skip_ an argument to tell why the test is being skipped. >> >>> +compare err /dev/null || fail_ >> >> Same for fail_ here, and below. > > Done. > >>> +REGEX=a >>> + >>> +echo 'abc >>> +0def >>> +0ghi >>> +0aaa

Re: Debian patches

Reuben Thomas wrote: > 2010/3/6 Jim Meyering : ... >> I've always seen obvious value in using ranges, and decreased value >> in writing them out.  Arguments to the contrary?  I could try claiming >> amnesia or even Alzheimer's ;-) > > http://www.gnu.org/

Re: Debian patches

Reuben Thomas wrote: > Section 6 of http://www.gnu.org/software/grep/devel.html seems to be > superceded by README-release, so should be removed. I've just done that. Thanks. > I am assuming that with the flurry of activity for the 2.6 release, > it's acceptable to post little nits like this her

Re: Debian patches

Reuben Thomas wrote: > Could I get some clarification on whether there's any desire for an > acceptable version of my patch to allow libpcre to be linked at > run-time? I certainly like the idea.

Re: Debian patches

Paolo Bonzini wrote: > On 03/07/2010 09:42 AM, Jim Meyering wrote: >> Reuben Thomas wrote: >>> Could I get some clarification on whether there's any desire for an >>> acceptable version of my patch to allow libpcre to be linked at >>> run-time? >&g

Re: Debian patches

Paolo Bonzini wrote: > On 03/07/2010 11:59 AM, Jim Meyering wrote: >> I too hesitate to commit to libtool for something so small and optional. >> How about making this feature available only on systems that >> provide working dlopen and shared library support? > > What a

Re: [PATCH 5/5] Small refactoring in src/dfa.c

Paolo Bonzini wrote: > * src/dfa.c (parse_bracket_exp_mb): Return MBCSET. > (lex): Assign return value of parse_bracket_exp_mb to lasttok, return it. Looks fine and saves a line. ACK.

Re: [PATCH 4/5] use do...while(0) idiom

Paolo Bonzini wrote: > * dfa.c (FETCH): Wrap with do...while(0). Definitely ACK.

Re: [PATCH 3/5] extract common code from if/else

Paolo Bonzini wrote: > * dfa.c (dfaexec): Simplify logic for MB_CUR_MAX > 1 case. Good factoring. Our I-caches will thank you.

Re: [PATCH 2/5] remove register variable hacks

Paolo Bonzini wrote: > * dfa.c (dfaexec): We can extract the address of a variable without fearing > performance problems, modern compilers know better. > --- > src/dfa.c | 27 --- > 1 files changed, 8 insertions(+), 19 deletions(-) Shorter and more readable. ACK

Re: [PATCH 1/5] remove register keywords

Paolo Bonzini wrote: > * dfa.c (dfaexec): Modern compilers just ignore it. Good riddance ;-)

Re: [PATCH] simplify parsing of [a-z]

Paolo Bonzini wrote: > * src/dfa.c (in_coll_range): New. > (lex): Use it instead of regcomp/regexec. > > +static int > +in_coll_range (char ch, char from, char to) > +{ > + char c[6] = { from, 0, ch, 0, to, 0 }; > + return strcoll (&c[0], &c[2]) <= 0 && 0 <= strcoll (&c[2], &c[4]); > +} This loo

FYI, dfaexec bug-fix coming up

atter, I had to make one more small change. Once I merge with recent changes and tease apart the minimal fix, I'll post the patch. In the mean time, please defer invasive changes to dfaexec. >From 720850a595f7196a778ef5ac7b9a167196df0631 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sun

Re: FYI, dfaexec bug-fix coming up

Paolo Bonzini wrote: > On 03/08/2010 02:49 PM, Jim Meyering wrote: >> This adds a failing test. >> I was flabbergasted to see that this test fails. >> >> The only reason it doesn't fail with Debian's patches is >> because they've turned off the DFA

Re: [PATCH] doc+bootstrap: document build-from-git-clone process

Reuben Thomas wrote: > On 9 March 2010 13:29, Jim Meyering wrote: >> * README-hacking: New file, nearly identical to the one in coreutils. > > Can the differences be clearly marked? This document looks long enough > to be commoned up, or to put it another way, long enough for

[PATCH] doc+bootstrap: document build-from-git-clone process

FYI, just pushed: (patches welcome if anyone sees something that needs adapting) >From 3c2dac22f427a7e10c096573d14c07ce926ae188 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Mon, 8 Mar 2010 20:22:35 +0100 Subject: [PATCH] doc+bootstrap: document build-from-git-clone process * bootst

3 tiny changes: plug obvious leak; tiny sync w/gawk; trailing space

I've just pushed these: >From b75dd4e9ffd42ec32f80f4d978c5e53dc6e7466e Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Tue, 9 Mar 2010 15:02:41 +0100 Subject: [PATCH 1/3] dfa: avoid a leak (work_mbc->chars) * src/dfa.c (parse_bracket_exp_mb): Remove useless (and leaked MALLOC). ---

[PATCH] build: record build-from-clone tool requirements

I'm going to push this shortly. >From 2c9cb22f1ee1d36549988a69e4b45865dde768df Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Tue, 9 Mar 2010 21:07:33 +0100 Subject: [PATCH] build: record build-from-clone tool requirements * bootstrap.conf (buildreq): This makes bootstrap fail with

[PATCH] grep: avoid useless allocations for empty GREP_OPTIONS

FYI, >From b9de803c28eabb2245d28865ea3fd0591f5d050b Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Mon, 8 Mar 2010 17:44:43 +0100 Subject: [PATCH] grep: avoid useless allocations for empty GREP_OPTIONS * src/grep.c (prepend_default_options): Ignore GREP_OPTIONS when it's empty, not j

[PATCH] grep: plug an inconsequential leak

Not consequential in the sense that I doubt it would ever cause run-time trouble. However, plugging it does eliminate distracting warnings from tools like valgrind, and that matters. >From cebcd3ece053c51bbbf1f47669c771eced828b61 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Mon, 8 Mar 2

[PATCH 1/3] maint: remove now-useless prototypes

FYI, some clean-up, in preparation for the dfa.c merge from gawk: >From bedc0229b071ff536a631462e74113913f4c645f Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Thu, 11 Mar 2010 15:12:47 +0100 Subject: [PATCH 1/3] maint: remove now-useless prototypes * src/dfa.c: Remove the prototype of e

[PATCH] dfa: do not accept [[:UPPER:]] or [[:LOWER:]] internally

p 17 00:00:00 2001 From: Jim Meyering Date: Thu, 11 Mar 2010 16:24:47 +0100 Subject: [PATCH] dfa: do not accept [[:UPPER:]] or [[:LOWER:]] internally * src/dfa.c (parse_bracket_exp_mb): Those class names are not valid, and rejected elsewhere, so there is no point in allowing upper or mixed-case

sync dfaexec from gawk: fixes real bugs in grep

nimal. In particular, I've done something rather ugly in simply casting the 3rd argument to each dfaexec call to "char *". >From 8226b2f161bf41c93f918b9f6fad4a3973475775 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Tue, 9 Mar 2010 15:31:22 +0100 Subject: [PATCH 1/3] dfa: manu

Re: sync dfaexec from gawk: fixes real bugs in grep

t one, so the comment in 2nd isn't right. > I'll move param-name addition to the 2nd, where it belongs. The body of the commit log for 2/3 was outdated. Here's the same series, but with the above change and a corrected log comment. >From 4b5d6197e98450eb01efb301aabea907a96cb36f Mo

Re: Whitespace

Reuben Thomas wrote: > how can I set up whitespace-global-mode not to mess up grep source > files? At first I thought it was that my global setting is to have > indent-tabs-mode nil, so that whenever I saved I was turning tabs into > spaces, but even when I fixed this, I was getting differences, it

Re: sync dfaexec from gawk: fixes real bugs in grep

Paolo Bonzini wrote: >> + *end = eol; > > As a follow-up I'd make this *end++ = eol, so that the code below > either simplifies (fewer "+ 1") or becomes more idiomatic > (e.g. comparing "< end" and ">= end" instead of <= and >). I have mixed feelings about that. On one hand, it seems like it'd ma

Re: sync dfaexec from gawk: fixes real bugs in grep

the result: >From 5ad01d89ec6b4004e60d19d3f564efbfa48bf658 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sun, 7 Mar 2010 10:38:29 +0100 Subject: [PATCH] dfa: appease static analyzers * src/dfa.c (transit_state_singlebyte): Call abort rather than returning in a "can't happen&quo

Re: [PATCH 01/17] kwset/system: remove ptr_t

Paolo Bonzini wrote: > * src/kwset.h: Declare kwset using an incomplete struct type. > * src/system.h (ptr_t): Remove. ACK. You beat me to it ;-)

Re: [PATCH 02/17] grep: cleanup one const cast

Paolo Bonzini wrote: > * src/search.c (GEAcompile): Do not reuse motif when operating on the > (const) pattern, so we can make it non-const. Remove cast from free. Easy ack. no semantic change.

Re: [PATCH 03/17] dfa: get rid of x*alloc

Paolo Bonzini wrote: > * src/dfa.c: Include xalloc.h. > (xmalloc, xrealloc, xcalloc): Remove. > --- > src/dfa.c | 35 ++- > src/dfa.h | 12 > 2 files changed, 2 insertions(+), 45 deletions(-) > > diff --git a/src/dfa.c b/src/dfa.c ... The part abov

Re: [PATCH 05/17] dfa, grep: cleanup if-before-free and cast-of-argument-to-free

Paolo Bonzini wrote: > * .x-sc_avoid_if_before_free: Remove. > * .x-sc_cast_of_alloca_return_value: Remove. > * .x-sc_cast_of_x_alloc_return_value: Remove. > * .x-sc_cast_of_argument_to_free: Temporarily add src/search.c. > * cfg.mk (local-checks-to-skip): Remove sc_cast_of_argument_to_free. > * sr

Re: [PATCH 04/17] dfa: remove CRANGE dead code

Paolo Bonzini wrote: > The only use of CRANGE was removed by commit 193830d. In theory it is > more correct to do what CRANGE did, but in practice it seems like it did > not work. > > * src/dfa.h (token): Remove CRANGE. > * src/dfa.c (atom): Do not handle CRANGE. > (prtok): Likewise. Can't argue

Re: [PATCH 07/17] syntax-check: enable makefile-TAB-only-indentation

Paolo Bonzini wrote: > * cfg.mk (local-checks-to-skip): Enable makefile-TAB-only-indentation. > * Makefile.am: Fix only occurrence. easy ack. Thanks!

Re: [PATCH 08/17] syntax-check: enable m4-quote-check

Paolo Bonzini wrote: > * cfg.mk (local-checks-to-skip): Enable m4-quote-check. > * configure.ac: Fix occurrence. ... > -AC_DEFINE(GREP, 1, [We are building grep]) > +AC_DEFINE([GREP], 1, [We are building grep]) Another easy one. ACK

Re: [PATCH 09/17] syntax-check: enable space-tab

Paolo Bonzini wrote: > * cfg.mk (local-checks-to-skip): Enable space-tab. > * .x-sc_space_tab: Add exceptions. > * tests/status.sh: Fix occurrence. Easy^2

Re: [PATCH 06/17] grep: fix error-message-uppercase

Paolo Bonzini wrote: > * cfg.mk (local-checks-to-skip): Enable error-message-uppercase. > * src/dfa.c (parse_bracket_exp_mb, lex, dfaparse): Fix occurrences. > * src/search.c (Pcompile, Pexecute): Fix occurrences. Consistency++ ACK. Thanks!

Re: [PATCH 00/16] my last hefty patch drop

Paolo Bonzini wrote: > So, here are my patches for 2.6. While they are big, they are worth Thanks! I've ACK'd the syntax-related ones. Now, I'll apply everything, and do a little testing before reviewing the meatier change sets.

[PATCH] build: avoid build failure with --enable-gcc-warnings

I'm pushing this, to fix a build failure when configured with --enable-gcc-warnings: dfa.c:35:1: error: macro "assert" is not used make[2]: *** [dfa.o] Error 1 >From 2d6b4e93db8058d23d4e37734b6ad65f9f05872b Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri, 12

[PATCH] build: avoid compiler warnings

From d9f05ea1da9e63489e4f6bd59e3391c20b549983 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri, 12 Mar 2010 20:34:55 +0100 Subject: [PATCH] build: avoid compiler warnings * src/search.c (mbtolower): s/free/n_free/ to avoid shadowing. (is_mb_middle): Remove declarations of now-unused vars:

Re: [PATCH 00/16] my last hefty patch drop

Jim Meyering wrote: > Paolo Bonzini wrote: >> So, here are my patches for 2.6. While they are big, they are worth > > Thanks! > I've ACK'd the syntax-related ones. > Now, I'll apply everything, and do a little testing > before reviewing the meatier change

Re: [PATCH 10/17] tests: add more UTF-8 test cases

Paolo Bonzini wrote: > * tests/Makefile.am (TESTS): Add spencer1-locale.sh. > (EXTRA_DIST): Add spencer1-locale.awk. > * tests/spencer1-locale.awk: New. > * tests/spencer1-locale.sh: New. ... > + printf ("status=`echo '%s'| { LC_ALL=%s ${GREP} -E -e '%s' >/dev/null > 2>&1 ; echo $?; }`\n",$3,

Re: [PATCH 05/17] dfa, grep: cleanup if-before-free and cast-of-argument-to-free

Aharon Robbins wrote: > I'm not happy with removing the null checks in calls to free(); there > were systems out there that would throw a fatal error if you passed > null to free(). I'd prefer to leave those checks in. Hi Arnold, The key word there is "were". Such systems are no longer relevant.

[PATCH] tests: clean up fedora.sh

ilently skipped. Jim [0] timeout has been in coreutils since 7.0 >From 45be60187525b45b3d979d45f365c89fd321fc54 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sun, 14 Mar 2010 11:07:39 +0100 Subject: [PATCH] tests: clean up fedora.sh * tests/fedora.sh: Use "grep", not ${GREP}. Us

Re: [PATCH] tests: clean up fedora.sh

Paolo Bonzini wrote: > On 03/14/2010 12:18 PM, Jim Meyering wrote: >> The new fedora.sh test was annoyingly slow. >> Yeah, 3 seconds is "slow" for some of us ;-) >> >> This fixes it, along with a little clean up and concurrency-protection. >> It relies o

Re: [PATCH] tests: clean up fedora.sh

Paolo Bonzini wrote: > On 03/14/2010 12:18 PM, Jim Meyering wrote: >> The new fedora.sh test was annoyingly slow. >> Yeah, 3 seconds is "slow" for some of us ;-) >> >> This fixes it, along with a little clean up and concurrency-protection. >> It relies o

Re: [PATCH] tests: clean up fedora.sh

Jim Meyering wrote: > Paolo Bonzini wrote: > >> On 03/14/2010 12:18 PM, Jim Meyering wrote: >>> The new fedora.sh test was annoyingly slow. >>> Yeah, 3 seconds is "slow" for some of us ;-) >>> >>> This fixes it, along with a little

Re: [PATCH 7/9] dfa: run simple UTF-8 regexps as a single-byte character set

Paolo Bonzini wrote: > This partially works around https://savannah.gnu.org/bugs/?29117, > but in general provides a speedup whenever fgrep is "almost" sufficient > but not quite (e.g. grep ^abc). Speedup is too good to be true :-) > (can get to 1000x on some not-too-contrived testcases). > > * sr

  1   2   3   4   5   6   7   8   9   10   >