bug#22059: grep -E: unexpected behaviour

s it, a message could be expected perhaps configurable by the -s/--no-messages option because the input is (sort of) unreadable. Version: 2.20 from the Debian Jessie package 2.20-4.1 Charles

bug#22444: compiler warnings in test snapshot

Hello, I tested the snapshot 2.22.29-83df mentioned by Jim Meyering. On Mac OS X 10.11.3, I found some compiler warnings. I'm not a programmer, so I don't know whether they're harmless or not. I thought I'd report them here. I pasted them below.

bug#22444: compiler warnings in test snapshot

On Sat, Jan 23, 2016 at 9:10 PM, Paul Eggert wrote: > Thanks for checking this so quickly! > > Charles Diza wrote: > > error.c:386:12: warning: data argument not used by format string >> > > That one is a false alarm. The format string might contain fewer formats >

[bug-grep] [bug #12727] --with-filename --only-matching, not as expected

Update of bug #12727 (project grep): Status:None => Confirmed Depends on: => patch #3770 ___ Follow-up Comment #1: This is covered by pa

Re: Bug in grep -P --color [bug-grep]

Strange. I didn't receive the original message to which you're replying from my bug-grep subscription. * On Friday 2005-04-22 at 17:33:18 +0200, Claudio Fontana wrote: > > --- Behdad Esfahbod <[EMAIL PROTECTED]> ha > scritto: > > Hi > > I think I have spotted a nasty bug somewhere in the > >

Re: Bug in grep -P --color [bug-grep]

* On Saturday 2005-04-23 at 01:40:00 +0200, Claudio Fontana wrote: > In the meantime, try this one, it's better (I hope). /* note: PCRE must be configured to work under UTF-8 */ Would it be appropriate to detect this at configure time from the installed PCRE, and if so to define something lik

Re: Bug in grep 2.5.1a (+ patch to fix it) [bug-grep]

* On Thursday 2005-04-28 at 10:28:54 +0100, Gordon Lack wrote: > > The Changelog at savannah.gnu.org > indicates that my original fix (reported as fixed in Fedora) has gone > into the GNU code. (However, I can't run CVS through my firewall, so I > can't download CVS code...) Yes, you can, but no

[bug-grep] [patch #3801] Red Hat's "color" patch

Follow-up Comment #2, patch #3801 (project grep): This patch #3801 is completely obsoleted by patch #3644. The shortcoming of this approach are also discussed under bug #11022, which includes its own attached patch which can also be considered obsolete and should not be applied to CVS. ___

[bug-grep] [bug #11022] Line wrapping causes GREP_COLOR background color to "smear"

taining' /usr/share/doc/grep-2.5.1/* The red background colour extends to the end of the line. Suggested patch attached. ___ Follow-up Comments: ------- Date: Thu 04/28/2005 at 16:10

[bug-grep] [bug #11022] Line wrapping causes GREP_COLOR background color to "smear"

Update of bug #11022 (project grep): Status:None => Confirmed ___ Reply to this item at: ___

[bug-grep] [bug #11022] Line wrapping causes GREP_COLOR background color to "smear"

Follow-up Comment #4, bug #11022 (project grep): Here's a new patch, produced by cannibalizing patch #3644. The framework introduced by the preprocessor macros is a good thing to have now as moves the actual SGR strings in one place and it will be re-used many times by a newer patch #3644. This

[bug-grep] [bug #11022] Line wrapping causes GREP_COLOR background color to \\\\\\\\

Update of bug #11022 (project grep): Summary: Line wrapping causes GREP_COLOR background color to => Line wrapping causes GREP_COLOR background color to Depends on: => patch #3644 __

[bug-grep] [patch #3801] Red Hat's

Update of patch #3801 (project grep): Summary: Red Hat's "color" patch => Red Hat\'s \ Depends on: => patch #3644 ___ Reply to this item at:

[bug-grep] [bug #11022] Line wrapping causes GREP_COLOR background color to \\\\

Update of bug #11022 (project grep): Summary: Line wrapping causes GREP_COLOR background color to "smear" => Line wrapping causes GREP_COLOR background color to Depends on: => patch #3801 ___

[bug-grep] [bug #11022] Line wrapping causes GREP_COLOR background color to "smear"

Update of bug #11022 (project grep): Summary: Line wrapping causes GREP_COLOR background color to => Line wrapping causes GREP_COLOR background color to "smear" ___ Reply to this item at:

[bug-grep] [patch #3801] Red Hat's "color" patch

Update of patch #3801 (project grep): Summary:Red Hat\'s \ => Red Hat's "color" patch Depends on: => bugs #11022 ___ Reply to this item at:

Re: Applying outstanding patches [bug-grep]

* On Thursday 2005-04-28 at 17:27:06 +0100, Julian Foad wrote: > > when the script is run from within "make check" the > LANG environment variable does not get through from the calling line in my > script to the function defined in the same script. Isn't using LANG instead of the higher priorit

[bug-grep] [bug #11022] Line wrapping causes GREP_COLOR background color to "smear"

Follow-up Comment #7, bug #11022 (project grep): The "do { ... } while (0)" makes it the syntactical equivalent of a function call. Consider #define F(x) if (x) h(x) #define G(x) do { if (x) h(x); } while (0) { if (y) F(x); else z++; if (y) G(x); else z++; } and matc

[bug-grep] [bug #9768] --ignore-case and --only-matching don't work together

Update of bug #9768 (project grep): Open/Closed:Open => Closed ___ Reply to this item at: _

[bug-grep] [bug #9768] --ignore-case and --only-matching don't work together

Update of bug #9768 (project grep): Status:None => Fixed ___ Follow-up Comment #1: Fixed in src/grep.c CVS revision 1.97. Other --match-icase issues remain. ___

Re: grep.pot missing [bug-grep]

* On Friday 2005-04-29 at 03:22:04 -0300, Tony Abou-Assaleh wrote: > > CVS states that on Thu Nov 11 17:07:18 2004 UTC you removed the grep.pot > file because it is a generated file. > > I didn't manage to find an easy way to generate it. Could you post some > comments to the list to clarify this

[bug-grep] [patch #3807] Red Hat's "oi" patch

Follow-up Comment #3, patch #3807 (project grep): The problems this fixes are not specific to --only-matching, but are most probably generic --ignore-case problems, given the nature of the fix. ___ Reply to this item at:

[bug-grep] [patch #3962] More tests for foad1.sh

URL: Summary: More tests for foad1.sh Project: grep Submitted by: charles_levert Submitted on: Fri 04/29/2005 at 09:54 Category: None Priority:

[bug-grep] [patch #3962] More tests for foad1.sh

Follow-up Comment #1, patch #3962 (project grep): New 2b version with -F,-G,-E loop and improved comments. ___ Additional Item Attachment: File name: foad1.sh.diff.charles2bSize:4 KB New version with -F,-G,-E loop and improved comm

[bug-grep] [patch #3962] More tests for foad1.sh

Follow-up Comment #2, patch #3962 (project grep): New 2c version with additional non-reflexivity tests. s/blindingly/blindly/ in the original summary. BTW, these tests currently fail; that's what justifies them. ___ Additional Item Attac

Re: Testing for UTF-8 bugs [was: Applying outstanding patches] [bug-grep]

* On Thursday 2005-04-28 at 20:06:59 +0100, Julian Foad wrote: > Charles Levert wrote: > > > >Isn't using LANG instead of the higher priority > >LC_ALL risky in any case? > > Good point - in fact, that was the problem (the test suite sets LC_ALL=C). > Thanks.

[bug-grep] [patch #3962] More tests for foad1.sh

Update of patch #3962 (project grep): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #3: Applied as CVS revis

[bug-grep] [patch #3965] Remove $(srcdir) from grep.po and stamp-cat-id targets in po/Makefile.in.in

Follow-up Comment #1, patch #3965 (project grep): Isn't there the problem that, when using a production package where "grep.pot" is precomputed, it will reside under srcdir, but in any other situation where it is initially absent and has to be recomputed, it will eventually reside under the build

Re: avoiding non-plain files with -I [bug-grep]

* On Sunday 2005-05-01 at 19:03:59 +0300, Jacob Lerner wrote: > > Is it possible to have grep ignore p(FIFO) and devices(b,c) without trying > to open them ? Is there such a switch ? DOes grep do it with -I switch ? According to `grep --help`: -D, --devices=ACTION how to handle devices, F

Re: [OT] bye bye grep [bug-grep]

* On Friday 2005-04-29 at 15:06:06 +0100, Julian Foad wrote: > Claudio Fontana wrote: > > > >I do not quite agree with how the > >development/maintainment is going on, as I often told > >Stepan, so I will try to find another project which > >needs some help. > > Oh. Certainly we have a problem wi

Re: GNU grep version 2.5.1 Nightly CVS Releases [bug-grep]

* On Friday 2005-04-29 at 13:43:24 -0300, Tony Abou-Assaleh wrote: > GNU grep version 2.5.1 Nightly CVS Releases are available at: > > http://www.dal-acm.ca/~taa/grep/ > > They are generated using 'make dist' around midnight, local time, Halifax, > Nova Scotia (current time zone ADT [-0300]

[bug-grep] [bug #12995] grep with --color and -i causes color match not to be displayed

Update of bug #12995 (project grep): Status:None => Confirmed ___ Follow-up Comment #1: Thanks for the report. Unfortunately, this bug does exist in the latest stable release of GNU gre

[bug-grep] [bug #12995] grep with --color and -i causes color match not to be displayed

Update of bug #12995 (project grep): Depends on: => patch #3807 ___ Reply to this item at: ___

Proposed new file for CVS: DISTRIBUTORS [bug-grep]

Hi. I propose adding this new file to CVS. The rationale is explained in the attached file itself. Comments? The purpose of this file is to help GNU grep maintainers track down bug fixes and improvements made by distributors so they can be integrated back into the upstream releases from GNU, if

Re: Proposed new file for CVS: DISTRIBUTORS [bug-grep]

* On Tuesday 2005-05-10 at 09:50:01 +0100, Julian Foad wrote: > Charles Levert wrote: > >I propose adding this new file to CVS. > [Information for Grep developers about known distributions of Grep.] > > This is a useful bit of information for us developers, so I would like t

Re: Documentation typo [bug-grep]

* On Sunday 2005-05-15 at 21:25:19 +, Laurence Darby wrote: > > The man page says > >--line-buffering > Use line buffering, it can be a performance penality. Thanks for reporting this. It's been fixed in CVS since ] revision 1.24 ] date: 2003/06/16 08:34:16; author

Re: Proposed new file for CVS: DISTRIBUTORS [bug-grep]

* On Wednesday 2005-05-11 at 09:52:24 +0200, Stepan Kasal wrote: > > Any place is good, go ahead! I had already started doing it in HTML at this point, so I now went ahead and added it as grep/devel.html under webcvs. This means it's currently available as

Re: [ADMIN] the bug-grep prefix [bug-grep]

* On Saturday 2005-06-04 at 19:42:44 +0200, Stepan Kasal wrote: > > Let me remind you that if you want to filter the postings to > a separate folder, and if you use procmail, you can use the > following recipe: > > :0: > * ^List-Post:[EMAIL PROTECTED]> > bug-grep-new Since the list also automati

Re: Web Pages Repository Commits are not emailed [bug-grep]

* On Sunday 2005-06-05 at 22:44:50 -0300, Tony Abou-Assaleh wrote: > Charles keeps adding useful stuff to the web pages. But the commits are > not sent to the grep-commit@gnu.org list. Is there a separate list for the > web cvs commits? See <http://savannah.gnu.org/support/?fun

Re: grep

* On Friday 2005-06-10 at 15:11:18 +0200, Emanuele Giaquinta wrote: > > I'm a GNU/Linux user. > Will a new grep release be made soon? > I'm asking cause I've found some bugs in 2.5.1, using perl regexp, already > fixed in cvs. Hi. I am replying with a Cc to bug-grep because this isn't an issue

Re: Release what we've got?

* On Monday 2005-06-13 at 14:47:03 -0300, Tony Abou-Assaleh wrote: > I vote for the immediate release. > > Lesson #7 from the Cathedral and the Bazaar: > > "Release early. Release often. And listen to your customers." Here's something I've said in a previous thread: "I think that, given the c

Re: Bug #11022: Line wrapping causes GREP_COLOR background color to "smear"

* On Tuesday 2005-06-14 at 00:44:56 +0100, Julian Foad wrote: > Charles Levert wrote: > >There are also bugs such as > > > > <https://savannah.gnu.org/bugs/?func=detailitem&item_id=11022> > > > >that could be closed right now as well because > >a

Re: Applying outstanding patches [was: Release what we've got?]

Partial comments... * On Tuesday 2005-06-14 at 00:26:06 +0100, Julian Foad wrote: > > I have applied those that I felt happy with. On your personal copy, right? I haven't seen anything in CVS yet. > "oi" patch: > Is it safe to be changing our copy of "regex.h" like this? Why the > chan

Re: Bug #11022: Line wrapping causes GREP_COLOR background color to "smear"

* On Monday 2005-06-13 at 20:56:59 -0400, Charles Levert wrote: > * On Tuesday 2005-06-14 at 00:44:56 +0100, Julian Foad wrote: > > Should we also clear to EOL after > > changing colour at the start of a match, for symmetry? > > Nothing grep does necessitates that. Otherwi

[bug #11022] Line wrapping causes GREP_COLOR background color to "smear"

Additional Item Attachment, bug #11022 (project grep): File name: charles1b.patchSize:5 KB Newer version with ChangeLog and SGR_START fix ___ Reply

[bug #11022] Line wrapping causes GREP_COLOR background color to "smear"

Update of bug #11022 (project grep): Status: Confirmed => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #8: Attached file #2606 (

--with-included-foo={yes,no} and which foo.h to use?

This is a problem I thought was limited to "regex.h", but it may be more generalized after all. I'll start the discussion on bug-grep; we'll see if it needs to be moved elsewhere as it goes. If a user configures with --with-included-foo=yes the problem I want to highlight doesn't manifest it

Re: Boyer Moore overflow patch

* On Wednesday 2005-06-15 at 01:45:10 +0100, Julian Foad wrote: > > diff -u -3 -p -d -r1.8 foad1.sh The following patch should be equivalent and much more readable. I haven't looked at the rest yet, so I can't vouch for the validity of the tests themselves, regardless of how they're scripted. I

Re: Boyer Moore overflow patch

* On Tuesday 2005-06-14 at 22:19:26 -0400, Charles Levert wrote: > * On Wednesday 2005-06-15 at 01:45:10 +0100, Julian Foad wrote: > > I noticed there's a problem with LC_ALL still > being set to $u from above, which it shouldn't > be. I'll have to investigate that

Re: --with-included-foo={yes,no} and which foo.h to use?

Thanks for replying. My understanding of this is still not yet complete, so here it goes. * On Tuesday 2005-06-14 at 22:06:43 -0700, Paul Eggert wrote: > Charles Levert <[EMAIL PROTECTED]> writes: > > > Does using gnulib solves the problem? > > It seems to have a &q

[patch #3769] Make nlscan() in src/grep.c robust to non-line-boundary argument

Update of patch #3769 (project grep): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #1: Applied (committed)

[patch #3768] Warn and set context to zero if --only-matching in main() in src/grep.c

Update of patch #3768 (project grep): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #1: Applied (committed)

[bug #12727] --with-filename --only-matching, not as expected

Update of bug #12727 (project grep): Status: Confirmed => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #2: Fixed by CVS revision

[patch #3770] Isolate new print_linehead() function from prline() in src/grep.c

Update of patch #3770 (project grep): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #1: Applied (committed)

[patch #3767] Remove two match_icase code paths from prline() in src/grep.c

Update of patch #3767 (project grep): Status:None => Postponed ___ Follow-up Comment #4: The attached patch no longer applies, but this still will need to be removed from there when the

[patch #3644] --initial-tab and 3 newly colorized items

Update of patch #3644 (project grep): Status:None => Done Assigned to:None => charles_levert Open/Closed:Open => Closed ___

[patch #3771] Merge only_matching code path in prline() in src/grep.c

Update of patch #3771 (project grep): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #1: Reworked version par

Re: Patching patches or rewriting them

* On Tuesday 2005-06-21 at 17:37:33 +0100, Tim Waugh wrote: > On Tue, Jun 21, 2005 at 12:07:42PM -0300, Tony Abou-Assaleh wrote: > > > If a patch is applied to the CVS, and I find a better solution, should I > > be writing a replacement patch or a new patch to the most recent CVS? > > > > (For in

Re: grep-2.5.1a egrep/fgrep PATH problem

* On Wednesday 2005-06-22 at 20:57:22 +0100, Chris Hughes wrote: > > Hiya, Ahoy! > The egrep/fgrep wrappers assume that grep-2.5.1a is the first grep on the > user's PATH: > > #!/bin/sh > exec grep -E ${1+"$@"} > > So if I install into in /usr/gnu/ (on Solaris for example) and run > /usr

Use of 0 instead of NULL in src/kwset.c

There are known bugs in src/kwset.c, so I'm reading the code trying to better understand what it does and how it does it. Namely, the fix Julian proposed for review a few days ago. I notice this file consistently uses 0 in place of NULL. It's the ultimate in C portability, but I think it makes t

Re: grep-2.5.1a egrep/fgrep PATH problem

* On Thursday 2005-06-23 at 08:30:48 -0300, Tony Abou-Assaleh wrote: > Would it make sense to add switches to the configuration script that would > determine how egrep/fgrep are installed? Current option seem to be: > > 1) don't install (should use grep -E/F) > 2) install wrapper (what we do now)

Re: Use of 0 instead of NULL in src/kwset.c

* On Thursday 2005-06-23 at 08:33:11 -0300, Tony Abou-Assaleh wrote: > > The rest of GNU grep's source code uses NULL > > all over the place. Would anyone be opposed to > > a 's/0/NULL/g' switch for these pointer values? > > Are there any portability issues that are not > > already triggered by th

Re: grep-2.5.1a egrep/fgrep PATH problem

Thanks for taking the time to look at this. * On Thursday 2005-06-23 at 17:04:29 -0700, Paul Eggert wrote: > Charles Levert <[EMAIL PROTECTED]> writes: > > > What do others on the list think? > > We should go back to the way "grep" used to do this, before we

Re: grep-2.5.1a egrep/fgrep PATH problem

* On Thursday 2005-06-23 at 17:04:29 -0700, Paul Eggert wrote: > Charles Levert <[EMAIL PROTECTED]> writes: > > That is, we should use binaries by default. Ok. I'm all for this. I will break those distribution packages that use symlinks, but that's the very idea. &

Re: grep-2.5.1a egrep/fgrep PATH problem

* On Thursday 2005-06-23 at 19:34:53 -0700, Paul Eggert wrote: > Charles Levert <[EMAIL PROTECTED]> writes: > > > egrep fgrep: Makefile > > (echo '#! /bin/sh'; \ > > Shouldn't the shell name be configured? On the one hand, is there any system tha

Re: grep-2.5.1a egrep/fgrep PATH problem

* On Friday 2005-06-24 at 05:49:24 -0300, Tony Abou-Assaleh wrote: > Are assuming that grep will be "installed"? For the main grep binary to work? No. It still would have no hardcoded path. It just wouldn't support adjusting its behavior according to the name under which it was invoked. For th

Re: grep-2.5.1a egrep/fgrep PATH problem

* On Friday 2005-06-24 at 11:32:25 -0700, Paul Eggert wrote: > Charles Levert <[EMAIL PROTECTED]> writes: > > > How about this, then? > > > > We store the grep executable as > > > >/usr/libexec/grep/2.5.2/i686-pc-linux-gnu/grep > > Yes, I thoug

Re: grep-2.5.1a egrep/fgrep PATH problem

* On Friday 2005-06-24 at 11:49:16 -0700, Paul Eggert wrote: > Tony Abou-Assaleh <[EMAIL PROTECTED]> writes: > > > What's the purpose of having more committers if we have active ones? > > I'm a bit of a special case, I had a bit of a chuckle when I saw Tony's question, given your obvious "senato

[bug #13581] Segmentation fault with -P option

Update of bug #13581 (project grep): Status:None => Works For Me Open/Closed:Open => Closed ___ Follow-up Comment #1: This cannot be reprod

Re: Use of 0 instead of NULL in src/kwset.c

* On Sunday 2005-07-03 at 20:47:58 +0100, Julian Foad wrote: > > I agree and would support such a change. I do not think there are any > portability problems. The only concern I have is that you should check > whether there are any large patches to this file currently in our patch > tracker.

Re: Use of 0 instead of NULL in src/kwset.c

* On Monday 2005-07-04 at 00:05:59 -0700, Paul Eggert wrote: > Charles Levert <[EMAIL PROTECTED]> writes: > > > + unsigned u = kwset->mind - (i + 1); > > A minor point: the usual GNU style is to say "unsigned int" rather > than plain "unsigned&q

src/kwset.c (kwsincr): Replace arbitrary array size by proper value

Proposed patch; I'll write a ChangeLog entry if it's accepted. I have checked that this will hold for CHAR_BIT up to 1023. Custom tools used for checking this available upon request (part analytical, part experimental). --- src/kwset.c 2005-07-04 01:14:37 -0400 +++ src/kwset.c 2005-07-04 11:45

src/kwset.c (kwsprep): Avoid copying altogether when kwset->trans is NULL

Proposed patch; I'll write a ChangeLog entry if it's accepted. By defining delta and next as pointers to arrays, we can avoid copying by not having an intermediate array when kwset->trans is NULL. There may be a downside in using a variable pointer instead of an array name (which is equivalent to

src/kwset.c (kwsincr, kwsprep): obstack_alloc()-related fixes

Proposed patch; I'll write a ChangeLog entry if it's accepted. The added call to obstack_free() will pop the top allocation off the obstack, which just succeeded before the last one failed. It's just to keep things clean. --- src/kwset.c 2005-07-04 01:14:37 -0400 +++ src/kwset.c 2005-07-04 09:

Re: Nice to see progress

* On Monday 2005-07-04 at 20:11:25 +0100, Julian Foad wrote: > Charles, thanks for all the work you're doing, getting things moving again, > fixing bugs, preparing the way for future improvements, and adding some > oft-requested enhancements. My pleasure. I may explain a little

Re: src/kwset.c (kwsincr): Replace arbitrary array size by proper value

* On Monday 2005-07-04 at 22:44:43 -0700, Paul Eggert wrote: > Charles Levert <[EMAIL PROTECTED]> writes: > > > I have checked that this will hold for CHAR_BIT > > up to 1023. I've put this in the ChangeLog. > > Custom tools used for checking > > thi

Re: src/kwset.c (kwsincr): Replace arbitrary array size by proper value

* On Tuesday 2005-07-05 at 11:12:31 -0700, Paul Eggert wrote: > Charles Levert <[EMAIL PROTECTED]> writes: > > > My only fear is that there likely already is a > > published paper proving just this, probably in > > a much more elegant way, and that I don't kn

Re: --with-included-foo={yes,no} and which foo.h to use?

; it's rather the opposite. Hopefully this won't always be true. Please comment. I'd really like to see this go in before 2.6, for the above reasons. 2005-07-07 Charles Levert <[EMAIL PROTECTED]> Big regex.[ch] update from latest glibc CVS libc/posix/.

Re: Changes to grep/src/grep.c

* On Thursday 2005-07-07 at 00:36:00 +0100, Julian Foad wrote: > > I don't know if you realised what you were including here. Please could > you avoid committing experimental code like this to the stable code base. > In fact, please commit a change that removes all traces of that "XM" > featu

Re: src/kwset.c (kwsincr): Replace arbitrary array size by proper value

* On Tuesday 2005-07-05 at 16:59:09 -0700, Paul Eggert wrote: > Charles Levert <[EMAIL PROTECTED]> writes: > > > -- Balanced binary trees (at every node, > >the depth difference of the two subtrees is > >at most 1). > > > > -- Worst (i.e., maximal) dep

Re: Changes to grep/src/grep.c

* On Thursday 2005-07-07 at 10:43:42 +0100, Julian Foad wrote: > Charles Levert wrote: > > > >Done. Hopefully it will be considered at one > >point and won't disappear into oblivion. > > Many thanks. Note that I wasn't objecting to the idea of that feature

Re: --with-included-foo={yes,no} and which foo.h to use?

* On Thursday 2005-07-07 at 11:29:00 +0100, Julian Foad wrote: > Charles Levert wrote: > >Please comment. I'd really like to see this go > >in before 2.6, for the above reasons. > > I'm generally in favour of getting this in to Grep soon, unless it has the >

Re: --with-included-foo={yes,no} and which foo.h to use?

* On Thursday 2005-07-07 at 14:01:32 +0200, Stepan Kasal wrote: > > On Thu, Jul 07, 2005 at 02:33:59AM -0400, Charles Levert wrote: > > > > But there's a catch-22 here. See below. > > I don't understand exactly why the number is 22... If you're seri

Re: --with-included-foo={yes,no} and which foo.h to use?

* On Thursday 2005-07-07 at 11:25:40 +0300, Aharon Robbins wrote: > > One thing I've started doing in gawk, just for my own sanity, is putting > the CVS/RCS $Id$ numbers of glibc files into the ChangeLog when I import > them. That way, a year later I know what version I started with and I > can l

Re: --with-included-foo={yes,no} and which foo.h to use?

* On Thursday 2005-07-07 at 09:46:00 -0400, Charles Levert wrote: > > Good idea. I will rewrite the ChangeLog > entry with this in mind, and addressing Julian > concerns too. Here is a reworked ChangeLog entry. 2005-07-07 Charles Levert <[EMAIL PROTECTED]> Big

Re: src/kwset.c (kwsincr): Replace arbitrary array size by proper value

* On Thursday 2005-07-07 at 16:48:49 -0700, Paul Eggert wrote: > Charles Levert <[EMAIL PROTECTED]> writes: > > >> The height of a balanced binary tree with N internal nodes always lies > >> between lg(N + 1) and (1.4404 lg (N + 2) - 0.3277). Here, the > &

Re: src/kwset.c (kwsincr): Replace arbitrary array size by proper value

* On Friday 2005-07-08 at 08:21:10 -0400, Charles Levert wrote: > So it suffices to show that > > 3 > a * (log_2(2^(b + 2) + 2) - log_2(2^b + 2)) > > for a given value of b, for my upper bound > to get even looser compared to Knuth's when > that b is incre

Re: Boyer Moore overflow patch

* On Saturday 2005-07-16 at 14:43:10 +0100, Julian Foad wrote: > Charles Levert wrote: > >I think the only pending patch that's affected > >is one you were working on to fix a bug. > > Sorry to be so forgetful, but could you post the URL or tracker number of > th

Re: [bug #13859] matching '([A]|[B]){2}' in different locales

* On Wednesday 2005-07-20 at 17:28:39 +, anonymous wrote: > > Follow-up Comment #2, bug #13859 (project grep): > > Thank you, that version works correctly regardless of locale for me too. The > problem seems to be worked around by your dfa_optional patch. If I keep all > other patches, but un

[bug #13847] memchr() not checked on Pexecute() - leads to segfault

Update of bug #13847 (project grep): Status:None => Works For Me ___ Follow-up Comment #1: Although this bug is already fixed in CVS, the attached patch suggests the idea of adding a test f

[bug #13847] memchr() not checked on Pexecute() - leads to segfault

Update of bug #13847 (project grep): Open/Closed:Open => Closed ___ Follow-up Comment #2: I have created a new tests/pcre.sh file with such a test. The bug was already fixed, so I am now

Re: grep dfa bug

* On Monday 2005-08-01 at 09:12:03 +0900, KIMURA Koichi wrote: > > I think I found bug of dfa of gawk. You mean grep? (Both use a dfa.) > Situation: > In Japanese ShiftJIS locale, half-witdth katakana in character class > does not match appropriately. > > Reproduce: > set LANG=ja_JP.SJIS > ex

[bug #14161] German man-page outdated, missing several options

Update of bug #14161 (project grep): Status:None => Invalid Open/Closed:Open => Closed ___ Follow-up Comment #1: The upstream GNU grep

[sr #104575] Return column number of first match as option to grep

Update of sr #104575 (project grep): Priority: 5 - Normal => 3 - Low Status:None => Need Info ___ Follow-up Comment #1: Hi John. Can you che

Patch: non-empty matches following empty ones

-u -r1.270 ChangeLog --- grep/ChangeLog 27 Jul 2005 02:44:53 - 1.270 +++ grep/ChangeLog 22 Aug 2005 14:59:37 - @@ -1,3 +1,11 @@ +2005-08-22 Charles Levert <[EMAIL PROTECTED]> + + * src/grep.c (print_line_middle): In case of an empty match, + make m

Re: Patch: non-empty matches following empty ones

Hi Stepan. You've been MIA (missing in action) for a while on this list! :-) Good to read you back. * On Tuesday 2005-08-23 at 12:06:13 +0200, Stepan Kasal wrote: > > I think that all matches should be printed, even the empty ones. > And the same holds for --colour; if an automated system tri

Re: Patch: non-empty matches following empty ones

* On Tuesday 2005-08-23 at 16:24:05 +0200, Stepan Kasal wrote: > > Sure, I understood that. That's what > sed 's/a*/X/g' > or > awk 'gsub(/a*/,"X")' > does. > > Your arguments seem to show that grep should print only lines > with _nonempty_ matches. (Empty pattern might be an except

Re: Patch: non-empty matches following empty ones

* On Tuesday 2005-08-23 at 11:22:08 -0400, Charles Levert wrote: > * On Tuesday 2005-08-23 at 16:24:05 +0200, Stepan Kasal wrote: > > > > OK, I no longer object to it. But please change the decumentation > > (info and manpage) so that it states this clearly. > >

[patch #4354] add --no-recurse-symlinks feature

Follow-up Comment #3, patch #4354 (project grep): The find command already does not follow symbolic links by default, so that the following pipeline can be used: find /usr/include -type f -print0 | xargs -0r grep -H lstat instead of a hypothetically new grep -r --no-recurse-symlinks lstat

Re: Patch: non-empty matches following empty ones

* On Friday 2005-08-26 at 11:33:34 +0100, Julian Foad wrote: > > 1. With "--only-matching" or "--color", ensure non-empty matches are >displayed or colored even after an empty match. (Bug fix.) Given the single way that print_line_middle() is called in the source code, it's implicit that thi

  1   2   >