Re: a bug in ALL grep?

On Friday 15 February 2008, Meir wrote: > I am trying to check that a file does not contain lines with terminating > tabs (see attached). The file is about 1000 lines long in the format of > , yet my "grep" finds 5 lines with terminating > tabs. I checked the file with a binary editor - nope! > > a

[bug #9668] Interpreting '-' specially not allowed by POSIX?

Follow-up Comment #2, bug #9668 (project grep): the GNU project already in general treats '-' as stdin as well as handles /dev/... pieces sanely. that specific part of POSIX is simply ignored. see discussion on the GNU tar mailing list for more info. ___

[bug #22654] performance issue in an uutf8 environment

Follow-up Comment #1, bug #22654 (project grep): i'm pretty sure there's already issues open on this topic ... also, utf8 really doesnt play a role in the linux kernel at all, so i really dont know what you're implying in that statement __

Re: colors too much when pattern is dot

On Wednesday 23 April 2008, Mikel Ward wrote: > With GREP_COLOR enabled, grep --color=auto colors the entire line when > the pattern is "." or "^.". > > It's not a big problem, and maybe my understanding is wrong, but I > would expect the . to match only the first character, and hence only > the fi

Re: Bug: grep -o '^.' Prints All Characters.

On Thursday 24 April 2008, Ralph Corderoy wrote: > $ grep --version > grep (GNU grep) 2.5.1 > > Copyright 1988, 1992-1999, 2000, 2001 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is > NO warranty; not even for MERCHANTABILITY o

Re: grep 2.5.3 make check errors

On Friday 09 May 2008, Jason Bachman wrote: > Testing: ../src/grep Word -o -i >input: "WordA/wordB/WORDC/" >output: "" >expect: "Word/word/WORD/" > FAIL > Testing: ../src/grep WORD -o -i >input: "WordA/wordB/WORDC/" >output: "" >expect: "Word/word/WORD/" > FAIL > Testing

[PATCH] grep(1) man page: touchup --label option

The --label description has a little .I bleed (includes the "." after it). Also give people a hint to see the -H option as not everyone is familiar with grep to know this behavior. Signed-off-by: Mike Frysinger --- doc/grep.1 |7 +-- 1 files changed, 5 insertions(+), 2

[bug #25539] empty display with DOS newlines and color=auto

URL: Summary: empty display with DOS newlines and color=auto Project: grep Submitted by: vapier Submitted on: Tue 10 Feb 2009 05:58:39 AM GMT Category: None Severity:

Re: grep -P and 2.5.4

On Thursday 19 February 2009 15:49:40 dx k9 wrote: > We recently upgraded to 2.5.4, from 2.5.1 and the user is reporting this. > > grep -nP "[\x80-\xff]" > /prj/folder/example/htdocs/dog/present.txt > grep: Support for the -P option is not compiled into this > --disable-perl-regexp binary so rebui

Re: enable perl regexp

On Monday 23 February 2009 14:32:17 dx k9 wrote: > What's the syntax to enable perl regexp when building grep? ./configure --help | grep perl > I just tried > > ./configure --prefix=/usr/local/grep-2.5.3 --enable-perl-regexp and that > didn't work "didnt work" is a very good description. post t

Re: spaces in filenames

On Thursday 03 September 2009 18:01:09 Roland Deluca wrote: > Grep.exe BUF_SIZE "D:\ Copy of EXAMPLES \*.*" -> returns NO > RESULTS > > Does not return results for a directory with spaces in the file name and > wild characters in quotes? this really isnt a grep problem. the shell handles

[patch #7017] dlopen PCRE

Follow-up Comment #1, patch #7017 (project grep): you cant dlopen(libpcre.so). you need to figure out the SONAME you're currently linking against and load that. ___ Reply to this item at:

[PATCH] grep(1) man page: touchup --label option

The --label description has a little .I bleed (includes the "." after it). Also give people a hint to see the -H option as not everyone is familiar with grep to know this behavior. Signed-off-by: Mike Frysinger --- doc/grep.1 |7 +-- 1 files changed, 5 insertions(+), 2

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

current git (dfc952df53977580b545c4f0a901542d8db1ac91) passes `make check` on my system: x86_64 Gentoo Linux gcc-4.4.3 glibc-2.11 the only patches we have in Gentoo against grep are related to gnulib/po, and they should be fixed with latest versions of both -mike signature.asc Description: Thi

[patch #7017] dlopen PCRE

Follow-up Comment #5, patch #7017 (project grep): a configure test wouldnt be useful either. people building packages will have libpcre.so on their system so the configure test would pass. but the systems where that package gets deployed will fail most of the time because people arent installin

[patch #7017] dlopen PCRE

Follow-up Comment #7, patch #7017 (project grep): did you post the wrong file ? the latest patch still doesnt check the result of AC_CHECK_LIB(), and it's dlopening libpcre.so. hardcoding any filename isnt going to work. the SONAME you should be hardcoding is whatever matches the pcre.h you're

[patch #7017] dlopen PCRE

Follow-up Comment #10, patch #7017 (project grep): yes, that configure.ac check looks correct, but that is certainly not in any of the posted patches so far. ldd is a host test, so that wouldnt work (i.e. it implicitly invokes the host ldso to find things out). you could use `readelf -d` and as

Re: git magic help required

On Thursday 11 March 2010 19:01:42 Reuben Thomas wrote: > having done some more work on my patch #7017, I pulled updates from > master to make sure I had no conflicts, which worked fine, but now I > have a commit after those updates, and a commit before, which I want > to merge in some way to get a

Re: char-class-multibyte test failure

On Friday 26 March 2010 02:32:01 Jim Meyering wrote: > Mike Frysinger wrote: > > the new char-class-multibyte test fails with grep-2.6.1 on my system. i > > have en_US.UTF8 on my system, but not the french utf8 locale. > > > > using gcc-4.4.3 and glibc-2.11 on x86_64

Re: new snapshot available: grep-2.6.1.28-37ad

On Monday 29 March 2010 05:49:34 Jim Meyering wrote: > Here's one last snapshot before grep-2.6.2. > > Paolo found and fixed a bug in my fgrep-infloop patch, > and there have been a few build-related changes. > > grep snapshot: (.gz files are here, too) > http://meyering.net/grep/grep-ss.tar.xz

implicit decl in tests/get-mb-cur-max.c

minor issue: tests/get-mb-cur-max.c:28: warning: implicit declaration of function 'set_program_name' -mike signature.asc Description: This is a digitally signed message part.

Re: grep-2.6.3 imminent: please test this snapshot

On Thursday 01 April 2010 07:37:37 Jim Meyering wrote: > There is a bug in grep-2.6.2 that can make grep -F infloop. > I think we've addressed all of the pending problems except > one reported by Norihirio Tanaka (we're deliberately deferring > work on that, since it is so far out on the fringe of

Re: grep -o

On Mon, Oct 25, 2010 at 10:34 AM, wrote: > Looks like -o ignores -i? > > $ echo "AA" |grep -i "aa" > AA > $ echo "AA" |grep -io "aa" > $ uname -r > 2.6.16.60-0.57.1-smp kernel version via uname isnt useful. you need to show what version of grep you're using. if it isnt the latest (grep-2.7), y

Re: Run-time dynamic linking in grep

On Sunday, January 16, 2011 18:12:09 Reuben Thomas wrote: > I have two outstanding patches against grep: #7017 (dlopen PCRE) & > #6107 (Patch to add transparent decompression). Both require dynamic > run-time linking (indeed, #6107 is purely to add it). please post actual URLs to the bugs in quest

Re: plus sign appears not to work as expected

On Saturday 11 February 2012 12:50:56 Bill Gradwohl wrote: > I had hoped to find a help list because this may be my problem, but here > goes: > > grep --color '^[[:alpha:]]*' xxx > Lists every line including blank lines, highlighting leading alpha strings. > > grep --color '^[[:alpha:]][[:alpha:]

Re: plus sign appears not to work as expected

On Saturday 18 February 2012 17:51:32 Bob Proulx wrote: thanks Bob -mike signature.asc Description: This is a digitally signed message part.

Re: Using $ in quotes with characters after it

On Friday 23 March 2012 20:52:49 Dan wrote: > dw@circe:~$ grep '^abc.*$\?' testfile > abc;klj? > abcasdf > dw@circe:~$ grep "^abc.*$\?" testfile > abc;klj? > abcasdf > dw@circe:~$ grep ^abc.*$\? testfile > dw@circe:~$ run `set -x` before these commands to see what exactly is being passed to grep.

Re: Using $ in quotes with characters after it

On Saturday 24 March 2012 15:06:00 Dan wrote: > This is the output after running `set -x`. It looks like the shell is > behaving properly. It's un-escaping the question mark when it's supposed > to be and it isn't when it isn't supposed to be. Grep shouldn't be > producing that output though. T

Re: Using $ in quotes with characters after it

On Sunday 25 March 2012 17:11:50 Dan wrote: > Interesting. I missed that part of the man page where it says "?" loses > its meaning in basic grep. Thanks for your time in helping me figure out > where exactly I went wrong. np. nuances, by their nature, are hard to pick up on :). -mike signatu

Re: [PATCH] build: work with new glibc when not optimizing

On Sat, Sep 1, 2012 at 12:10 PM, Eric Blake wrote: > Starting with glibc 2.15, the system headers refuse to compile > unconditional use of FORTIFY_SOURCE if optimization is disabled > but -Werror is in effect. pretty sure you mean 2.16.0 > Pushing, as this is similar to the recent coreutils patch

bug#16698: making the grep-2.17 release soon

On Saturday, February 08, 2014 18:34:59 Jim Meyering wrote: > I want to make a release soon, preferably next week, with a first > snapshot tomorrow. > There is the pcre-related problem that can result in an infloop or > segfault, but that is in libpcre. I may write a configure-time test > to detec

bug#16758: [PATCH 2/2] ignore configure.lineno

* .gitignore: Add configure.lineno. --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 0b195d9..6a911b6 100644 --- a/.gitignore +++ b/.gitignore @@ -18,6 +18,7 @@ /config.status /configure /configure.ac +/configure.lineno /doc/grep.1 /doc/grep.aux

bug#16757: [PATCH 1/2] search for pcre via pkg-config

Since pcre ships a pkg-config module now, let's default to using that. If the system lacks pkg-config support, we still fall back to the old logic of probing the headers/libs directly. * configure.ac: Call m4_pattern_forbid on the PKG_ namespace. * m4/pcre.m4: Change serial to 2. (gl_FUNC_PCRE): R

bug#16698: making the grep-2.17 release soon

On Sunday, February 09, 2014 08:17:29 Jim Meyering wrote: > On Sat, Feb 8, 2014 at 7:12 PM, Mike Frysinger wrote: > > On Saturday, February 08, 2014 18:34:59 Jim Meyering wrote: > >> I want to make a release soon, preferably next week, with a first > >> snapshot tomor

bug#16757: [PATCH 1/2] search for pcre via pkg-config

On Saturday, February 15, 2014 20:20:35 Jim Meyering wrote: > On Fri, Feb 14, 2014 at 2:09 PM, Mike Frysinger wrote: > > Since pcre ships a pkg-config module now, let's default to using that. > > If the system lacks pkg-config support, we still fall back to the old > > lo

bug#17246: grep-2.19 planning

On Fri 11 Apr 2014 18:04:09 Jim Meyering wrote: > I would like to plan for a release in a couple of weeks. Paolo, > you seemed to be motivated to work on an egrep/fgrep alternative. > I am happy with including shell scripts for grep-2.19, but if you feel > strongly about it and are preparing a pat

bug#19985: active locale impacts binary data detection?

i've got some users reporting diff behavior between 2.20 and 2.21. the example file is attached and has mixed encoding. i think the new behavior is correct, but want to make sure it's expected, or that the maintainers don't have different ideas here. with 2.20: $ LC_ALL=en_US.UTF8 grep 8 test

bug#16757: [PATCH 1/2] search for pcre via pkg-config

On 25 May 2014 01:14, Paul Eggert wrote: > --- a/m4/pcre.m4 > +++ b/m4/pcre.m4 > > + if test $test_pcre = yes; then the previous code quoted test_pcre ... i guess previously it was normalized into "yes" and "no", but seems pretty cheap & easy to be resilient ? > +PKG_CHECK_MODULES([PCRE],

bug#16757: [PATCH 1/2] search for pcre via pkg-config

On 21 Apr 2014 17:29, Paul Eggert wrote: > Thanks for the patch in . In looking it over > I see a couple of things. First, it looks big enough that we'll need > copyright papers for it. Can you please get the ball rolling on that? > I assume you know the drill. fwi

bug#21827: Large file support

On 04 Nov 2015 14:07, Michael Brunnbauer wrote: > I am quite surprised that my grep (suddenly?) has problems with large files: > > fiano:~$ ls -l todelete.txt > -rw-r--r-- 1 brunni users 2981338204 Nov 4 13:40 todelete.txt > fiano:~$ grep test todelete.txt > grep: todelete.txt: Value too lar

bug#21827: Large file support

On 05 Nov 2015 15:05, Paul Eggert wrote: > On 11/04/2015 05:07 AM, Michael Brunnbauer wrote: > > Any ideas what could be going wrong? > > It appears you've run afoul of glibc bug#18781. > > https://sourceware.org/bugzilla/show_bug.cgi?id=18781 > > Yeowch. If I'm right, that's a serious glibc bu

bug#21827: Large file support

On 06 Nov 2015 07:35, Michael Brunnbauer wrote: > On Thu, Nov 05, 2015 at 10:37:43PM -0500, Mike Frysinger wrote: > > > It appears you've run afoul of glibc bug#18781. > > > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=18781 > > > > > &

bug#22286: Similar to the google way of showing grep result

On 01 Jan 2016 04:56, Peng Yu wrote: > Grep by default show match result by lines. But in certain cases it would > be better to should show the context of the matches just like in google so > that users can easily check if a document is relevant or not. Is there any > tool like this? sounds like y

Re: egrep --exclude problem

On Friday 31 August 2007, Yakov Lerner wrote: > I am doing > egrep --exclude=.svn -r foo . > but grep still prints matches under .svn subtree ? > Why ? What I am doing wrong ? apparently --exclude only works on the filename, not the entire path ... which sucks -mike signature.asc Desc

Re: grep-2.5.4 Test Release

On Monday 19 November 2007, Tony Abou-Assaleh wrote: > I'd appreciate any feedback: Did I miss or mess something? i see warnings about __restrict_arr being redefined in lib/posix/regex.h ... do you need to sync up latest regex code from gnulib ? src/search.c:check_multibyte_string() calls wcrtom

Re: grep-2.5.4 Test Release

On Tuesday 20 November 2007, Tony Abou-Assaleh wrote: > > src/search.c:check_multibyte_string() calls wcrtomb() on a const string > > but wcrtomb() in most cases will be modifying the first argument (which > > is the const string) > > That code wasn't touched in at least 2 years. Is it easy to fix?

Re: Test Release: grep-2.5.4-20080209b

On Saturday 09 February 2008, Tony Abou-Assaleh wrote: > We are getting closer to an actual release :O) > > I made a new test release grep-2.5.4-20080209b. You can download it from: while `make check` passes for me, i'm guessing the failing tests from 2.5.3 were dropped rather than fixed ? for e

Re: Test Release: grep-2.5.4-20080209b

On Sunday 10 February 2008, Ken Moffat wrote: > On Sun, Feb 10, 2008 at 04:34:42AM -0500, Mike Frysinger wrote: > > On Saturday 09 February 2008, Tony Abou-Assaleh wrote: > > > We are getting closer to an actual release :O) > > > > > > I made a new test r

bug#25283: grep: (standard input): invalid argument when run from make

On 27 Dec 2016 11:23, Paul Eggert wrote: > Thanks for reporting that problem. I wonder why GNU 'make' sets stdout to > append > mode? That surprises me, and I don't see where POSIX allows it. Anyway, it's > clearly a bug in 'grep' no matter what 'make' is doing. I wrote up a test > case > for