Re: grep --color enhancement

[ Here is a message sent via private email, for the benefit of everyone who subscribes to the bug-grep mailing list. ] * On Monday 2005-12-12 at 10:12:01 +, Pádraig Brady wrote: > Hi Charles, Hi. Thanks for your interest in GNU grep. > I notice you've been working on the grep --color c

Re: [patch] selected/context colors

* On Monday 2005-11-21 at 00:40:20 +0100, Benno Schulenberg wrote: > > You saw I didn't get it; then explain. As soon as I saw, I did my best to. Don't blame me for not trying or not caring to. Doing so badly, maybe. > Piss off. And damn you. I see this choice of words is not that off-limit

Re: [patch] selected/context colors

* On Sunday 2005-11-20 at 21:39:10 +0100, Benno Schulenberg wrote: > > But I didn't anticipate the "damn" controversy. > > I simply saw the word, didn't see the point, and asked you to remove > it. Now you could have just explained why the word was there. > Instead you went off saying that som

Re: [patch #4610] Consolidated documentation patch

* On Saturday 2005-11-19 at 20:57:46 +, Julian Foad wrote: > Charles Levert wrote: > > > >Unfortunately, there is no "an.tmac" provision > >for another hierarchical level and adding one > >would definitely be out of tradition. So I'm > >

Re: [patch #4610] Consolidated documentation patch

A long essay deserves a long answer... * On Friday 2005-11-18 at 21:48:54 +, Julian Foad wrote: > Charles Levert wrote: > >I have chosen to work on the actual documentation > >first, and to get it out early for review, rather > >than working on a ChangeLog entry ri

[patch #4610] Consolidated documentation patch

Follow-up Comment #5, patch #4610 (project grep): TeXinfo manual, version 4, unidiff output. ___ Additional Item Attachment: File name: grep.texi.diff4Size:75 KB TeXinfo manual, unidiff output, version 4

[patch #4610] Consolidated documentation patch

Follow-up Comment #4, patch #4610 (project grep): Man page, version 4, whole file. ___ Additional Item Attachment: File name: grep.1 Size:29 KB grep.1, whole file, version 4

Re: [patch #4610] Consolidated documentation patch

* On Friday 2005-11-18 at 14:05:26 +, Julian Foad wrote: > * Maybe have a look at my patch (attached) and combine the best of your and > my changes. (Sorry, I should have sent this earlier rather than trying to > "finish" it first.) Merged. Much of the GREP_COLORS stuff was rewritten in th

[patch #4610] Consolidated documentation patch

Follow-up Comment #3, patch #4610 (project grep): TeXinfo manual, version 3. I attached a unidiff output file. Check out dvi and info. ___ Additional Item Attachment: File name: grep.texi.diff3Size:74 KB TeXinfo manual,

[patch #4610] Consolidated documentation patch

Follow-up Comment #2, patch #4610 (project grep): Man page, version 3. I attached the whole file because it's now smaller than diff output. Check out "groff -Tascii" and "groff -Tps". ___ Additional Item Attachment: File name: grep.1

info+man: should "Diagnostics" be replaced by "Exit Status"?

Both the info and man documentation have a "Diagnostics" section. This section is traditionally used to list and explain specific warning and error messages. The "Exit Status" section, in contrast, usually documents just that, and only that. In grep's documentation, the former title is used abov

Re: What is GNU's policy regarding %format strings and gettext()?

* On Thursday 2005-11-17 at 16:28:38 -0800, Paul Eggert wrote: > Charles Levert <[EMAIL PROTECTED]> writes: > > > Right now, grep's hand-written man page does not have a COPYRIGHT > > section. Should we elect to continue with this hand-written > > solution

Re: [patch] selected/context colors

* On Friday 2005-11-18 at 00:53:21 +0100, Benno Schulenberg wrote: > Charles Levert wrote: > > * On Wednesday 2005-11-16 at 22:54:58 +0100, Benno Schulenberg > > wrote: > > > Charles Levert wrote: > > > > Have you tried with a recent 'less

Re: What is GNU's policy regarding %format strings and gettext()?

* On Thursday 2005-11-17 at 13:52:49 -0800, Paul Eggert wrote: > > That's for copyright notices in source code. But we're talking about > the output of --version; that's a different matter. For --version > it's OK to mention only the last year. So, if help2man is used, the COPYRIGHT section of

Re: What is GNU's policy regarding %format strings and gettext()?

* On Thursday 2005-11-17 at 13:16:10 -0800, Paul Eggert wrote: > /* Change this as needed */ > enum { COPYRIGHT_YEAR = 2005 }; We were having this discussion about copyright years a few days ago. Does this mean it's ok to keep only the last year, and just omit earlier ones? According to

Re: make dist

* On Thursday 2005-11-17 at 00:10:42 -0700, Bob Proulx wrote: > Charles Levert wrote: > > * Tony Abou-Assaleh wrote: > > > Found the problem. The automake version was 1.4, which caused a few things > > > not to work. The syntax of some macros changed in later

Re: Interaction of -i with square brackets

* On Wednesday 2005-11-16 at 16:39:36 -0800, Geoff Kuenning wrote: > > The root user is probably using a different locale. > > Bingo. That was (is) the problem. Thanks. > > But I don't understand why the locale should matter when I'm only > grepping for 7-bit characters. Because neither grep n

Re: [patch] selected/context colors

* On Wednesday 2005-11-16 at 22:54:58 +0100, Benno Schulenberg wrote: > Charles Levert wrote: > > * On Tuesday 2005-11-15 at 23:06:46 +0100, Benno Schulenberg > > wrote: > > > BTW, when using --color=always and piping the output to 'less', > > > text in

What is GNU's policy regarding %format strings and gettext()?

Yesterday, I saw an announcement for another GNU software package. It was said that "... multi-part message strings were re-formed to use a single printf formatting string". But combining printf-format strings and gettext() can lead to security vulnerabilities. In "Write It Secure: Format St

[bug #14990] "The -P option is not supported"

Follow-up Comment #3, bug #14990 (project grep): > "Support for the -P option has not been compiled into this binary" Good idea. I'll see if I can't do that right away, since it's a simple change. ___ Reply to this item at:

[bug #14990] "The -P option is not supported"

Update of bug #14990 (project grep): Severity: 3 - Normal => 2 - Minor Open/Closed:Open => Closed ___ Follow-up Comment #2: This specific message

Re: [patch] selected/context colors

* On Tuesday 2005-11-15 at 23:06:46 +0100, Benno Schulenberg wrote: > Charles Levert wrote: > > Please check that all colors as well as the various > > separators are ok. > > Phew... I can't imagine ever wanting to use all those colours. > That the file name i

Re: addition to GREP_COLORS documentation

[ To bug-grep readers: This was sent to me by private email. I am citing it whole here as I don't believe any of it is secret. ] * On Sunday 2005-11-13 at 22:21:29 -0800, Dan Nicolaescu wrote: > Hi! > > May I suggest an addition to the GREP_COLORS documentation? > > Currently the GREP_

Re: [patch] selected/context colors

* On Tuesday 2005-11-15 at 22:07:18 +0100, Benno Schulenberg wrote: [...] Thanks. I think I've taken every one of your suggestions into account. I have switched to "@table @code" and replaced incomplete sentence propositions by complete period-terminated sentences (except for the initial ones th

Re: [patch] selected/context colors

* On Monday 2005-11-14 at 21:54:25 -0500, Charles Levert wrote: > > Here is a new version of the patch. Here are now fragments covering most of the reworked TeXinfo documentation for this. An embedded @table for the capabilities was added within the @table row for the GREP_COLORS envir

Re: [patch] selected/context colors

* On Monday 2005-11-14 at 21:19:47 +, Julian Foad wrote: > Charles Levert wrote: > >(Make sure to try 2.5.1a with different combinations > >of options, to see what its behavior actually was.) Also make sure to try all combinations with some output prefix, e.g., with -H. >

Re: [patch] selected/context colors

* On Monday 2005-11-14 at 20:40:17 +, Julian Foad wrote: > Charles Levert wrote: > > > >Please confirm explicitly, however, that the > >part about the main color for the whole line > >being inverted in synchronization with the ':' > >and '-&#

Re: tests/yesno.sh, kinds of line (matching/non-matching, selected/rejected)

* On Monday 2005-11-14 at 17:01:10 +, Julian Foad wrote: > Yes, but I have long wanted a search tool that reports the matched text > only. Maybe that functionality should have been put into a new program > instead of into Grep. Bingo. Its innovations (i.e., practically successful inventions

Re: Common source for man page and info document?

* On Monday 2005-11-14 at 16:50:23 +, Julian Foad wrote: > (I received the following suggestion by private mail. Thanks, Matt. - > Julian.) > > * Matt Burgess wrote: > > The first thing that springs to mind here is DocBook XML[0]. There are > > stylesheets[1] that can convert the same DocB

Re: [patch] selected/context colors

* On Monday 2005-11-14 at 12:58:20 +, Julian Foad wrote: > Charles Levert wrote: > >Here is the selected/context colors patch, as discussed. > >Nothing else that was discussed is touched by this. > > > >I have attached a screen shot to be sure this > >is wha

[patch] selected/context colors

retrieving revision 1.284 diff -u -r1.284 ChangeLog --- grep/ChangeLog 13 Nov 2005 08:15:16 - 1.284 +++ grep/ChangeLog 14 Nov 2005 04:20:30 - @@ -1,3 +1,18 @@ +2005-11-14 Charles Levert <[EMAIL PROTECTED]> + + * src/grep.c: Rename global variables, macro

Re: when options conflict

* On Monday 2005-11-14 at 00:50:25 +0100, Benno Schulenberg wrote: > Charles Levert wrote: > > * On Friday 2005-11-11 at 22:09:17 +0100, Benno Schulenberg wrote: > > > Ideally, what should grep do when options conflict? > > > > > > 1) Abort with an error message

Re: tests/yesno.sh, kinds of line (matching/non-matching, selected/rejected)

* On Sunday 2005-11-13 at 23:46:09 +, Julian Foad wrote: > Charles Levert wrote: > >As for -C/-v/-o and the warning issue, I think > >we do disagree. With -o, I see a line-group > >(including selected and context lines) as a > >pool of _printable_ content, i.e., li

Re: [patch #4610] Consolidated documentation patch

* On Monday 2005-11-14 at 00:06:40 +0100, Benno Schulenberg wrote: > Charles Levert wrote: > > It just seems strange to have added things in > > 2005, have them circulating around, but not be > > able to claim a copyright privilege for them. > > Things don't work

Re: [patch #4610] Consolidated documentation patch

* On Sunday 2005-11-13 at 23:21:31 +0100, Benno Schulenberg wrote: > Charles Levert wrote: > > + * doc/grep.1, doc/grep.texi: Note that context lines are not > > available > > + with --only-matching and that a warning is issued under such > > uses. > >

Re: tests/yesno.sh, kinds of line (matching/non-matching, selected/rejected)

* On Sunday 2005-11-13 at 21:55:57 +, Julian Foad wrote: > Charles Levert wrote: > > > >> sl: terminfo-like string capability for selected lines > >> cx: terminfo-like string capability for context lines > [...] > >One consequence to document is that no

Re: when options conflict

* On Saturday 2005-11-12 at 23:44:02 -0800, Paul Eggert wrote: > Charles Levert <[EMAIL PROTECTED]> writes: > > > What do other grep implementations do (for > > those that support extended options that lend > > themselves to feature interaction problems)? > >

Re: tests/yesno.sh, kinds of line (matching/non-matching, selected/rejected)

* On Sunday 2005-11-13 at 18:44:57 +, Julian Foad wrote: > CONTEXT LINES AND MAX-COUNT > > Charles Levert wrote: > > Test #28: { ../src/grep -F -n -b -m 2 -v -C 1 -o yes; echo "?$?"; sed > > We'll discuss the interaction between "-v" and "

Re: tests/yesno.sh, kinds of line (matching/non-matching, selected/rejected)

* On Sunday 2005-11-13 at 17:36:03 +, Julian Foad wrote: > Charles Levert wrote: > >You can see by my design of the GREP_COLORS > >framework that I just plain forgot about -v and > >confused things: > > > > ml: terminfo-like string capability for matchi

Re: Common source for man page and info document?

* On Sunday 2005-11-13 at 18:35:04 +, Julian Foad wrote: > I'm getting very annoyed by the mis-match between the man page and the info > document. I and Debian and others don't want to lose the man page, and > GNU/FSF don't want to lose the "info" document. (I could probably grow to > like

tests/yesno.sh, kinds of line (matching/non-matching, selected/rejected)

I created a new test file, tests/yesno.sh. (Test feature interaction of -C, -v, -o, and -m.) Having more of these is never a bad thing, so I went ahead and committed it to CVS right away. It can always be modified to address the issues it raises, or code and documentation can be. On 2005-06-21, I

Re: when options conflict

* On Friday 2005-11-11 at 22:09:17 +0100, Benno Schulenberg wrote: > When grep is given the options -l and -o together, or -l and -h, > for example, then the -l option appears to take precedence and the > other one is ignored; no warning is given. This is an issue. Ideally, it should be explore

[patch #4610] Consolidated documentation patch

Update of patch #4610 (project grep): Status:None => Ready For Test ___ Follow-up Comment #1: Version 2. See ChangeLog. Again, check out dvi and info. _

Re: [patch #4610] Consolidated documentation patch

* On Friday 2005-11-11 at 22:33:11 +0100, Benno Schulenberg wrote: > Charles Levert wrote: > > * On Friday 2005-11-11 at 15:59:25 +0100, Benno Schulenberg wrote: > > > (Although I don't like to see "Unix" in allcaps.) > > > > I wasn't sure a

Re: [patch #4610] Consolidated documentation patch

* On Friday 2005-11-11 at 15:59:25 +0100, Benno Schulenberg wrote: > Charles Levert wrote: > > +7th Edition -s-1UNIX-s0 > > \s (Although I don't like to see "Unix" in allcaps.) I wasn't sure about this one. -- UNIX was the original marketing term (see, e

[bug #14946] "grep -P" doesn't support pattern lists

Update of bug #14946 (project grep): Status:None => Postponed ___ Follow-up Comment #1: Upon reflection, my proposed solution would not work, so I at least added an error and a message f

Re: make dist

* On Friday 2005-11-11 at 02:31:37 -0400, Tony Abou-Assaleh wrote: > Found the problem. The automake version was 1.4, which caused a few things > not to work. The syntax of some macros changed in later versions of > automake. Looking at the packages.debian.org web site, I see that stable, unstable

[patch #4610] Consolidated documentation patch

URL: Summary: Consolidated documentation patch Project: grep Submitted by: charles_levert Submitted on: Fri 11/11/05 at 05:07 Category: None Pr

Re: Changes to grep/doc/grep.1

* On Thursday 2005-11-10 at 23:03:28 +, Julian Foad wrote: > Benno Schulenberg wrote: > > > >The second patch adds the "(using wildcard matching)" also to the > >explanation of `--include'. It removes the "and directories", to > >make the text describe the actual behaviour of grep. > > I'm

Re: make dist

* On Thursday 2005-11-10 at 17:37:57 -0400, Tony Abou-Assaleh wrote: > Using the latest debian, there are several things broken in the cvs when > trying to create the nightly snapshots. > > I fixed some using one-liner patches, and still working on others. > > I am not sure why some things that u

[bug #8243] egrep with --color and -f patternfile gives different result to fgrep

Update of bug #8243 (project grep): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #2: This issue has been ad

[patch #1834] fixes grep -w --color

Update of patch #1834 (project grep): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #4: This issue has been

[bug #11579] "echo ab | grep -o ^." gives incorrect output

Update of bug #11579 (project grep): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #2: This issue has been a

[patch #4604] Fix left anchors and -w problems

Update of patch #4604 (project grep): Status: Ready For Test => Done Open/Closed:Open => Closed ___ Follow-up Comment #2: Slightly modified as

daily CVS snapshots (was Re: [patch #4604] Fix left anchors and -w problems)

* On Wednesday 2005-11-09 at 23:42:43 -0400, Tony Abou-Assaleh wrote: > Tony! I noticed you moved, so I adjusted the link to your list of grep implementations from the web page to point to . Or is that an ev

[bug #14946] "grep -P" doesn't support pattern lists

URL: Summary: "grep -P" doesn't support pattern lists Project: grep Submitted by: charles_levert Submitted on: Thu 11/10/05 at 04:08 Category: None

[patch #4604] Fix left anchors and -w problems

Update of patch #4604 (project grep): Status:None => Ready For Test ___ Follow-up Comment #1: Version 2. Note that this also addresses bug #8243. The execute() interface was changed from us

Re: [patch #4604] Fix left anchors and -w problems

* On Wednesday 2005-11-09 at 23:08:14 +, Julian Foad wrote: > Use a pointer if it > makes the code clearer (in callers and callees). This is not an inner loop > so code clarity is more important than speed efficiency. I will use a pointer. I found out that to use a pointer, I must actuall

Re: Changes to grep/doc/grep.1

23:44 - @@ -5,6 +5,10 @@ detect errors, for portability with other POSIX-compliant implementations. + * doc/grep.1, doc/grep.texi: Use just "grep" instead of + "the grep command", unless an example command really follows. + Use just "command" inst

Re: [patch #4604] Fix left anchors and -w problems

* On Wednesday 2005-11-09 at 15:50:33 +, Julian Foad wrote: > Charles Levert wrote: > > <http://savannah.gnu.org/patch/?func=detailitem&item_id=4604> > > <http://savannah.gnu.org/patch/download.php?item_id=4604&item_file_id=5449> > > >The following

[patch #4604] Fix left anchors and -w problems

URL: Summary: Fix left anchors and -w problems Project: grep Submitted by: charles_levert Submitted on: Wed 11/09/05 at 11:23 Category: None Pr

Re: Exit statuses and errors messages (was Re: grep . /; echo $?)

* On Tuesday 2005-11-08 at 20:40:12 -0500, Charles Levert wrote: > However, encouraging > users to use the "test $? -gt 1" (or > "test $? -ge 2") logic might be a good > thing to do for portability in any case, > as this is all th

[patch #4596] "egrep" and "fgrep" as minimal argv[0]-independent executables

Update of patch #4596 (project grep): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #3: Slightly modified as

Exit statuses and errors messages (was Re: grep . /; echo $?)

* On Wednesday 2005-11-09 at 00:47:29 +, Julian Foad wrote: > Charles Levert wrote: > > > >My take is that we could eventually change the > >whole suppressible_error()/errseen framework, > >but not right now, since this is more of a new > >feature than a bug fi

Re: grep grep.html

* On Tuesday 2005-11-08 at 23:29:21 +, Julian Foad wrote: > Charles Levert wrote: > > > >Modified files: > > . : grep.html > > > >Log message: > > Replace all capitalized "Grep" by a lowercase "grep". > &g

[patch #4596] "egrep" and "fgrep" as minimal argv[0]-independent executables

Follow-up Comment #2, patch #4596 (project grep): New version 3. Relative to latest CVS commits. Define COMPILE_RET, COMPILE_ARGS, EXECUTE_RET, EXECUTE_ARGS, COMPILE_FCT, and EXECUTE_FCT helper preprocessor macros. Use them. ___ Additio

Re: lowercase letters for binaries

* On Monday 2005-11-07 at 01:53:17 +, Julian Foad wrote: > Charles Levert wrote: > [...] > >Hence, my question was: is that the > >justification used by the POSIX committee when > >they standardized on this behavior for EREs? > > No. See the Ope

Re: lowercase letters for binaries

* On Monday 2005-11-07 at 21:40:49 +0100, Benno Schulenberg wrote: > So maybe the > following is a better text for 'info grep usage': > > 13. Why is this back-reference failing? > > echo "ba" | egrep '(a)\1|b\1' > > This gives no output, because the first alternate '(a)\1' does >

Re: lowercase letters for binaries

* On Sunday 2005-11-06 at 23:51:12 +0100, Andreas Schwab wrote: > Charles Levert <[EMAIL PROTECTED]> writes: > > > * On Sunday 2005-11-06 at 22:48:30 +0100, Andreas Schwab wrote: > >> only in BREs which don't have alternation. > > > > Is that the

Re: lowercase letters for binaries

* On Sunday 2005-11-06 at 22:48:30 +0100, Andreas Schwab wrote: > Note that POSIX does not allow back-references in EREs, You're right. I didn't notice that because GNU grep does support them (from GNU regex). > only in BREs which don't have alternation. Is that the justification? Strictly sp

Re: lowercase letters for binaries

* On Sunday 2005-11-06 at 16:50:57 +0100, Benno Schulenberg wrote: > Looking for something that's easy to fix, I came across > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=190551: > 'egrep' and 'fgrep' are mistakenly spelled 'Egrep' and 'Fgrep' in > the manpage. > > The first part of that pa

Re: grep . /; echo $?

* On Friday 2005-11-04 at 23:16:58 +0100, Benno Schulenberg wrote: > @@ -187,7 +187,7 @@ > suppressible_error (char const *mesg, int errnum) > { >if (! suppress_errors) > -error (0, errnum, "%s", mesg); > +error (0, errnum, "Cannot read %s", mesg); >errseen = 1; > } That particu

[patch #4596] "egrep" and "fgrep" as minimal argv[0]-independent executables

Follow-up Comment #1, patch #4596 (project grep): New version 2. Obsoletes both previous attachments. ___ Additional Item Attachment: File name: gefp2.patchSize:31 KB \"cvs diff -u\" patch version 2

Re: grep . /; echo $?

* On Friday 2005-11-04 at 16:50:55 +, Julian Foad wrote: > > Yes, that's true: the message could quite easily be extended or replaced, > but is this really something that needs fixing? It doesn't seem like a > significant problem to me. It's fairly obvious from its form that it's an > err

Re: [patch #4596] "egrep" and "fgrep" as minimal argv[0]-independent executables

* On Friday 2005-11-04 at 13:07:32 +, Julian Foad wrote: > Charles Levert wrote: > >* On Friday 2005-11-04 at 04:22:53 +, Charles Levert wrote: > > > >> <http://savannah.gnu.org/patch/?func=detailitem&item_id=4596> > > >>Full ChangeLog entry

Re: [patch #4596] "egrep" and "fgrep" as minimal argv[0]-independent executables

* On Friday 2005-11-04 at 04:22:53 +, Charles Levert wrote: > > URL: > <http://savannah.gnu.org/patch/?func=detailitem&item_id=4596> > > Summary: "egrep" and "fgrep" as minimal argv[0]-independent executables > Details: > > The fo

[patch #4596] "egrep" and "fgrep" as minimal argv[0]-independent executables

Additional Item Attachment, patch #4596 (project grep): File name: gefp.new_files.patch Size:0 KB Unidiff patch for new files (in addition to previous attachment) ___

[patch #4596] "egrep" and "fgrep" as minimal argv[0]-independent executables

URL: Summary: "egrep" and "fgrep" as minimal argv[0]-independent executables Project: grep Submitted by: charles_levert Submitted on: Fri 11/04/05 at 04:22 Cat

[PATCH] proper lowercasing of multi-octet-char "keys" string

23:28:05 - @@ -1,3 +1,11 @@ +2005-11-04 Charles Levert <[EMAIL PROTECTED]> + + * src/grep.c (mb_icase_keys): New function to properly lowercase + keys if match_icase. The problem was that some multi-octet + characters can get longer or shorter upon this conversi

Re: grep . /; echo $?

* On Thursday 2005-11-03 at 23:56:32 +0100, Benno Schulenberg wrote: > Charles Levert wrote: > > [...] > > src/grep: src: Is a directory > (The message itself is a bit strange though: it doesn't sound like > an error. "Cannot read a directory" would be bet

Re: Lots of bug fixes; possible release

* On Thursday 2005-11-03 at 21:20:59 +, Julian Foad wrote: > Charles Levert wrote: > > > >What I have solved: > > Excellent. I'm very impressed with your continuing work on this, Charles. Thanks. > > -- The "egrep" and "fgrep" scrip

Re: Question about "-m1 -A99" tests in foad1.sh

* On Thursday 2005-11-03 at 16:54:02 +, Julian Foad wrote: > Charles Levert wrote: > >grep_test "4/40/" "4/40/" "^4" -m1 -A99 > >grep_test "4/04/" "4/04/" "^4" -m1 -A99 > > >As I understand the in

Question about "-m1 -A99" tests in foad1.sh

I have a question about the following tests: = # Test combination of "-m" with "-A" and anchors. # Based on a report from Pavol Gono. grep_test "4/40/" "4/40/" "^4$" -m1 -A99 grep_test "4/04/" "4/04/" "^4$" -m1 -A99 grep_test "4/444/" "4/444/" "^

Re: grep . /; echo $?

* On Thursday 2005-11-03 at 04:35:42 +, Julian Foad wrote: > Charles Levert wrote: > >This was trivial to modify after all. > > > >Ok to apply? > > Not sure. If we're happy with the change in behaviour then yes, your patch > looks good, Ok. > but I h

Re: grep . /; echo $?

1.272 +++ grep/ChangeLog 3 Nov 2005 03:50:08 - @@ -1,3 +1,11 @@ +2005-11-03 Charles Levert <[EMAIL PROTECTED]> + + * src/grep.c (grep): For consistency, any error after a read() + in fillbuf() is reported for any type of files, now including + directories (whic

Re: grep . /; echo $?

* On Tuesday 2005-10-25 at 13:32:47 +0100, Julian Foad wrote: > Charles Levert wrote: > > > >According to the grep(1p) POSIX "man page": > [...] > >This does not restrict GNU grep from being more > >informative about what happened by documenting > >

Re: grep . /; echo $?

* On Monday 2005-10-24 at 15:58:30 +0100, Julian Foad wrote: > Dan Jacobson wrote: > >$ grep . /;echo $? > >1 > >$ strace grep . / > >...open("/", O_RDONLY|O_LARGEFILE) = 3 > >fstat64(3, {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0 > >read(3, 0x8071000, 32768) = -1 EISDIR (Is a directory)... > >

[bug #14630] feature request: grep -p[separator]

Follow-up Comment #2, bug #14630 (project grep): After verification, while AIX does support this option, neither do Solaris 10 nor HP-UX 11i (at least according to their online documentation). Also, /sbin/ifconfig eth0 is a much simpler way to achieve this specific task. __

[bug #14630] feature request: grep -p[separator]

Update of bug #14630 (project grep): Severity: 3 - Normal => 1 - Wish ___ Follow-up Comment #1: "Shocked" sounds somewhat quite strong a word. It's not so surprising that a non-standard extensi

Re: bug

* On Saturday 2005-09-03 at 20:08:42 -0500, complete wrote: > > grep -rn append_sid *.* How about just grep -rn append_sid . where "." designates the current directory? > The output from this shows data from the > "_New CompleteTranslations.com\_phpBB2" > directory only and it seems that a

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

[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 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. > >

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

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

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

[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

[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

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

  1   2   >