Re: grep 2.5.1: NUL byte doesn't match a complemented character class

2007-08-23 Thread Jim Meyering
Joe Wells [EMAIL PROTECTED] wrote: I now can see what the difference between your environment and mine must be. I'm also using this environment variable setting: LC_CTYPE=en_US.UTF-8 When I change this (just for the “grep” process) to On some systems, the locale name is spelled slightly

Re: grep 2.5.1: NUL byte doesn't match a complemented character class

2007-08-23 Thread Jim Meyering
Joe Wells [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: On some systems, the locale name is spelled slightly differently: [get the proper spelling from the output of locale -a] (By the way, this is irrelevant to the bug in grep, but I believe the output of “locale -a” does

Re: Segmentation fault, dd or egrep

2007-11-11 Thread Jim Meyering
Zev Weiss [EMAIL PROTECTED] wrote: I'm trying to recover some data from a disk that was unexpectedly reformatted, and am running into a segmentation fault, though it's not clear from the output whether it's coming from dd or egrep (hence this email being sent to both grep and coreutils). I'm

Re: Possible bug with grep/sed/tail?

2008-11-21 Thread Jim Meyering
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); }' | \ gcc

Re: Possible bug with grep/sed/tail?

2008-11-21 Thread Jim Meyering
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?

2008-11-22 Thread Jim Meyering
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 alias. Ah, yes. That was it. Thanks

Re: Possible bug with grep/sed/tail?

2008-11-24 Thread Jim Meyering
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 to each and every filter in coreutils. Especially considering

Re: Possible bug with grep/sed/tail?

2008-11-25 Thread Jim Meyering
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 streams. It

Re: Possible bug with grep/sed/tail?

2008-11-25 Thread Jim Meyering
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 size1 - specific buffer size Also we could have aliases for stdin stdout, linebuffered, ... We still have the requirement on LD_PRELOAD,

Re: Possible bug with grep/sed/tail?

2008-11-29 Thread Jim Meyering
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 $line_buffer_so Note that I named

Re: GNU grep 2.5.4 released

2009-08-23 Thread Jim Meyering
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

2009-11-29 Thread Jim Meyering
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

Re: 20 clean-up csets on next

2009-11-30 Thread Jim Meyering
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 list). Object now if you see

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

2009-12-04 Thread Jim Meyering
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 print

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

2009-12-04 Thread Jim Meyering
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

2009-12-20 Thread Jim Meyering
From dc57dad0fd9ccc43e65491e7416652d1437dff30 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com 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. * .x

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

2009-12-22 Thread Jim Meyering
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.

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

2009-12-23 Thread Jim Meyering
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 meyer...@redhat.com Date: Wed, 23 Dec 2009 18:59:30 +0100 Subject: [PATCH] fix multi-byte-locale read

updated FSF copyright year lists

2010-01-01 Thread Jim Meyering
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

2010-01-01 Thread Jim Meyering
that have been completely rewritten. Of course, I've verified that all tests continue to pass. In the patches below, I've elided the large remove this file parts of the use regex from gnulib... cset. Jim From a0993b9906f007a4498fdb901a808f99ed39c5fe Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer

Re: 18 csets coming up

2010-01-02 Thread Jim Meyering
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 deleted files since 2004, and those few appear

Re: 18 csets coming up

2010-01-06 Thread Jim Meyering
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: avoid more warnings

Re: Naming of bootstrap vs autogen.sh

2010-01-15 Thread Jim Meyering
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

2010-02-03 Thread Jim Meyering
on a few preceding patches. I'll push them all shortly: From 5cf71c8a420697ba59a8219d892473a02892fb6c Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Thu, 14 Jan 2010 08:17:58 +0100 Subject: [PATCH] tests: exercise surprising -m1 vs. --context behavior * tests/max-count-vs

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

2010-02-04 Thread Jim Meyering
Paolo Bonzini wrote: On 02/04/2010 08:55 AM, Jim Meyering wrote: +$(PERL) -w$$T_ -I$(srcdir) -MCoreutils \ + -MCuTmpdir qw($$f) -- $$1;\ cut'n'paste? No, it was deliberate, albeit perhaps getting ahead of myself. That code is currently

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

2010-02-06 Thread Jim Meyering
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?

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

2010-02-06 Thread Jim Meyering
Paolo Bonzini wrote: Update of bug #17457 (project grep): http://savannah.gnu.org/bugs/?17457 Status:None = Invalid Open/Closed:Open = Closed Follow-up Comment #4: Hmm, this cannot be fixed. By definition the output

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

2010-02-06 Thread Jim Meyering
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 FD is not enough,

Re: grep extremely slow on OSX

2010-02-06 Thread Jim Meyering
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 systems

[PATCH] remove useless DJGPP-specific code

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

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

2010-03-04 Thread Jim Meyering
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.

[PATCH] doc: document release procedure

2010-03-04 Thread Jim Meyering
10ab6fb6f239eaef102e71140d425bbca91b12dc Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com 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

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

2010-03-04 Thread Jim Meyering
Here's a new test: From 29182990773f031a7b39f93a17a05b64fa28e38d Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com 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

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

2010-03-04 Thread Jim Meyering
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, and after those are resolved, I will pull the lever

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

2010-03-04 Thread Jim Meyering
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.

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

2010-03-05 Thread Jim Meyering
1a4806a05c61137d41f46e2d0db06a0eb2e860eb Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com 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_matching_with_multibyte_ops, match_anychar): Likewise. --- dfa.c | 30

gawk-grep dfa synchronization

2010-03-05 Thread Jim Meyering
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 meyer...@redhat.com Date: Fri

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

2010-03-05 Thread Jim Meyering
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

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

Re: Debian patches

2010-03-05 Thread Jim Meyering
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.

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

2010-03-06 Thread Jim Meyering
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 with

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

2010-03-06 Thread Jim Meyering
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/search.c

Re: Debian patches

2010-03-06 Thread Jim Meyering
Reuben Thomas wrote: 2010/3/6 Jim Meyering j...@meyering.net: ... 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/prep/maintain/maintain.html

Re: Debian patches

2010-03-07 Thread Jim Meyering
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 here.

Re: Debian patches

2010-03-07 Thread Jim Meyering
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

2010-03-07 Thread Jim Meyering
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? I certainly like the idea. So distros would exchange putting

Re: Debian patches

2010-03-07 Thread Jim Meyering
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 about moving the real Perl grep

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

2010-03-08 Thread Jim Meyering
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

2010-03-08 Thread Jim Meyering
Paolo Bonzini wrote: * dfa.c (FETCH): Wrap with do...while(0). Definitely ACK.

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

2010-03-08 Thread Jim Meyering
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

2010-03-08 Thread Jim Meyering
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

FYI, dfaexec bug-fix coming up

2010-03-08 Thread Jim Meyering
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 meyer...@redhat.com Date: Sun, 7 Mar 2010 20:07:30

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

2010-03-09 Thread Jim Meyering
Reuben Thomas wrote: On 9 March 2010 13:29, Jim Meyering j...@meyering.net 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

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

2010-03-09 Thread Jim Meyering
I've just pushed these: From b75dd4e9ffd42ec32f80f4d978c5e53dc6e7466e Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com 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

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

[PATCH] grep: avoid useless allocations for empty GREP_OPTIONS

2010-03-11 Thread Jim Meyering
FYI, From b9de803c28eabb2245d28865ea3fd0591f5d050b Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com 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

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

2010-03-11 Thread Jim Meyering
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 meyer...@redhat.com Date: Thu, 11 Mar 2010 15:12:47 +0100 Subject: [PATCH 1/3] maint: remove now-useless prototypes * src/dfa.c: Remove

sync dfaexec from gawk: fixes real bugs in grep

2010-03-11 Thread Jim Meyering
argument to each dfaexec call to char *. From 8226b2f161bf41c93f918b9f6fad4a3973475775 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Tue, 9 Mar 2010 15:31:22 +0100 Subject: [PATCH 1/3] dfa: manually merge gawk's dfaexec * src/dfa.c (dfaexec): Adjust API: return pointer

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

2010-03-11 Thread Jim Meyering
. 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 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com

Re: Whitespace

2010-03-12 Thread Jim Meyering
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

2010-03-12 Thread Jim Meyering
: From 5ad01d89ec6b4004e60d19d3f564efbfa48bf658 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com 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 scenario

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

2010-03-12 Thread Jim Meyering
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 05/17] dfa, grep: cleanup if-before-free and cast-of-argument-to-free

2010-03-12 Thread Jim Meyering
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. *

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

2010-03-12 Thread Jim Meyering
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 with

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

2010-03-12 Thread Jim Meyering
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

2010-03-12 Thread Jim Meyering
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

2010-03-12 Thread Jim Meyering
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

2010-03-12 Thread Jim Meyering
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

2010-03-12 Thread Jim Meyering
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 meyer...@redhat.com Date: Fri, 12 Mar

[PATCH] build: avoid compiler warnings

2010-03-12 Thread Jim Meyering
2001 From: Jim Meyering meyer...@redhat.com 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: i, wc. * src/dfa.c: Include assert.h, now

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

2010-03-13 Thread Jim Meyering
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 sets. FYI, I turned off -Werror to get past

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

2010-03-13 Thread Jim Meyering
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 21 ; echo $?; }`\n,$3, locale,

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

2010-03-13 Thread Jim Meyering
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

2010-03-14 Thread Jim Meyering
] timeout has been in coreutils since 7.0 From 45be60187525b45b3d979d45f365c89fd321fc54 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Sun, 14 Mar 2010 11:07:39 +0100 Subject: [PATCH] tests: clean up fedora.sh * tests/fedora.sh: Use grep, not ${GREP}. Use init.sh. Use timeout 10

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

2010-03-15 Thread Jim Meyering
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 on the timeout program[0], but if it's not available

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

2010-03-15 Thread Jim Meyering
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 on the timeout program[0], but if it's not available

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

2010-03-15 Thread Jim Meyering
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 clean up and concurrency-protection. It relies on the timeout program[0

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

2010-03-15 Thread Jim Meyering
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). * src/dfa.c

Re: [PATCH 1/9] tests: add more UTF-8 test cases

2010-03-15 Thread Jim Meyering
Paolo Bonzini wrote: * tests/Makefile.am (TESTS): Add spencer1-locale. (EXTRA_DIST): Add spencer1-locale.awk. * tests/spencer1-locale.awk: New. * tests/spencer1-locale: New. Thanks for adjusting. This is fine, now.

Re: [PATCH 2/9] dfa: fix handling of ranges in multibyte character sets

2010-03-15 Thread Jim Meyering
Paolo Bonzini wrote: Hi Paolo, Do you have a test that exercises this fix? As far as I can see, the above tests currently succeed with grep built from master. I expected them to fail. It passes because strcoll (and hences ranges) is case-insensitive in many locales: $ printf '1\ny\n.\n'

Re: [PATCH 2/9] dfa: fix handling of ranges in multibyte character sets

2010-03-15 Thread Jim Meyering
Paolo Bonzini wrote: Well, I would really like a test that passes with, and fails without, that fix, so how about using something like this: This shows that grep-2.5.3 gets it wrong: $ printf '%s\n' A Z | LC_ALL=en_US.UTF-8 grep -i '[a-z]' A and with your fix, grep -i does what

Re: [PATCH 9/9] grep: match multibyte charsets line-by-line when using -i

2010-03-16 Thread Jim Meyering
Paolo Bonzini wrote: The turtle combination -i + MB_CUR_MAX1 requires case conversion ahead of time. Avoid doing this repeatedly when many matches succeed. Together with the previous changes, this fixes https://savannah.gnu.org/bugs/?29117 and https://savannah.gnu.org/bugs/?14472. * NEWS:

Re: [PATCH 9/9] grep: match multibyte charsets line-by-line when using -i

2010-03-16 Thread Jim Meyering
Paolo Bonzini wrote: On 03/16/2010 02:25 PM, Jim Meyering wrote: This looks fine. I can commit this one first, with your changes squashed in. Oh. Yes, I see that does work. Sure, go ahead. Some of the performance benefits of the others will be less visible, but it doesn't break anything

Re: [PATCH 3/9] dfa: rewrite handling of multibyte case_fold lexing

2010-03-16 Thread Jim Meyering
Paolo Bonzini wrote: Let dfacomp do the folding to lowercase of multibyte regexes, and remove it from grep.c. Input strings to kwset.c are still folded outside kwset.c. * NEWS: Document bugfixes. * .x-sc_cast_of_argument_to_free: Remove. * src/dfa.c (wctok, addtok_wc): New. ... This looks

Re: [PATCH] tests: use different output files to simplify reading failed .log files

2010-03-17 Thread Jim Meyering
Paolo Bonzini wrote: I noticed that from the .log files it is hard to understand which grep invocation fails. One way to work around it would be to use set -x, but I think this other fix is better. * tests/case-fold-backref, tests/case-fold-char-class, tests/case-fold-char-range,

Re: [PATCH] tests: add another grep -i testcase, from bug 16179

2010-03-17 Thread Jim Meyering
Paolo Bonzini wrote: * tests/case-fold-backref: New. * tests/Makefile.am (TESTS): Add it. This looks fine. Thanks!

Re: [PATCH 8/9] grep: remove check_multibyte_string, fix non-UTF8 missed match

2010-03-17 Thread Jim Meyering
Paolo Bonzini wrote: Avoid computing ahead something that can be computed lazily as efficiently (or more efficiently in the case of UTF-8, though this is left as TODO). At the same time, soften the rejection condition for matching in the middle of a multibyte sequence to fix bug 23814.

Re: [PATCH] dfa: improve documentation of struct dfa

2010-03-17 Thread Jim Meyering
Paolo Bonzini wrote: * src/dfa.h (struct dfa): Reword some comments. Welcome improvements. Thanks.

Re: [PATCH] tests: fix syntax-check failures

2010-03-17 Thread Jim Meyering
Paolo Bonzini wrote: I should really make a pre-commit hook. The first one is fun though. :-) * tests/case-fold-backref: Use foo instead of the. * tests/dfaexec-multibyte: Remove trailing blanks. haha ;-) ACK.

Re: [PATCH 5/9] dfa: optimize simple character sets under UTF-8 charsets

2010-03-17 Thread Jim Meyering
Paolo Bonzini wrote: Use a bitset when not involving MBCSET is possible. Testcase: yes 'the quick brown fox jumps over the lazy dog' | sed 10q | \ time grep -c [ABCDEFGHIJKLMNOPQRSTUVWXYZ,] Before: 51ms (best of three runs); after: 16ms(best of three runs). * src/dfa.c

Re: [PATCH] tests: fix typo

2010-03-17 Thread Jim Meyering
Paolo Bonzini wrote: * fedora: Fix typo. --- tests/fedora |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tests/fedora b/tests/fedora index c022f1e..a162930 100644 --- a/tests/fedora +++ b/tests/fedora @@ -39,7 +39,7 @@ grep -F -w -f 116909.list 116909.in | diff

Re: [PATCH] tests: fix typo

2010-03-17 Thread Jim Meyering
Jim Meyering wrote: Paolo Bonzini wrote: * fedora: Fix typo. --- tests/fedora |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tests/fedora b/tests/fedora index c022f1e..a162930 100644 --- a/tests/fedora +++ b/tests/fedora @@ -39,7 +39,7 @@ grep -F -w -f 116909

Re: [PATCH 4/9] dfa: speed up handling of brackets

2010-03-17 Thread Jim Meyering
Paolo Bonzini wrote: ... Please use unsigned int not just unsigned. Fine. I fixed it throughout dfa.[ch], see posted patch. I also prefer unsigned int but I used the latter since it prevailed in those two files. Thanks. + if (MB_CUR_MAX 1) +{ +

[PATCH] maint: remove obsolete cvs-clean make target

2010-03-17 Thread Jim Meyering
FYI, From 915944fdb2282b380a36f64b5bf58c729b58d90d Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Wed, 17 Mar 2010 16:14:47 +0100 Subject: [PATCH] maint: remove obsolete cvs-clean make target * Makefile.am (cvs-clean): Remove obsolete target. --- Makefile.am | 30

dfa.c coverage

2010-03-18 Thread Jim Meyering
I've just glanced through the LCOV coverage report for grep's dfa.c: http://hydra.nixos.org/build/327533/download/1/coverage/src/dfa.c.gcov.html I see a surprising amount of code that is supposedly not exercised at all by make check. Something to investigate. If true, then adding tests to

Re: new snapshot available: grep-2.5.4.183-9159

2010-03-18 Thread Jim Meyering
Shiva Iyer wrote: Apologies if this is a known issue or expected behaviour. When I run configure with --enable-gcc-warnings and then do a make, I get the following compilation errors for search.c: CC search.o cc1: warnings being treated as errors search.c: In function 'Pexecute':

Re: cygwin results and help-version

2010-03-18 Thread Jim Meyering
Paolo Bonzini wrote: Since I had to reboot to Windows I gave a try at the grep snapshot under Cygwin. I have Cygwin 1.5.25. All grep tests passed except: - fmbtest.sh and euc-mb which were skipped Thanks for checking! - help-version which failed because the sleep process created when

Re: results after import of dfa into gawk

2010-03-19 Thread Jim Meyering
Aharon Robbins wrote: Hi. I just finished importing dfa.[hc] into gawk. Good to know they're in sync. Thanks. \s(20 THANK YOU !!! \s for all the work. It passes make check. Attached is a diff from grep to gawk to retain additional things I need (e.g. VMS). FYI, I added more years in the

Re: build failure

2010-03-19 Thread Jim Meyering
Eric Blake wrote: [I figured it was high time I subscribed to this list, too] Aww... you missed all the fun of the last two weeks. Is anyone else seeing this? dfa.c: In function 'parse_bracket_exp': dfa.c:494: error: passing argument 1 of 'mbrtowc' from incompatible pointer type

Re: Latest snapshot and glibc regex support

2010-03-19 Thread Jim Meyering
Matthew Burgess wrote: A while ago Linux From Scratch added the '--without-included-regex' flag to grep's configure invocation in order to fix the behaviour of grep -i' (see http://wiki.linuxfromscratch.org/lfs/changeset/8688). It's good that you mentioned that configure option. I haven't been

  1   2   3   4   5   6   7   8   9   10   >