That's not quite true, as it can match command-line arguments.
I see. Perhaps the manual could be a little less terse than expecting
readers to understand the difference between "name suffix" and "base
name". Ok, it's clear in retrospect, but ... maybe something like (not
sure I got it corr
Would it be crazy for grep --exclude-dir=foo/bar to give a warning?
Since, as I understand it, any non-trailing / in the arg can never match
since the arg is matched against the basename.
This came up when I ran grep -r --exclude="t/*.dir", thinking it would
exclude all the test output director
AFAIK, these new warnings cause no malfunction.
Only if you've already changed your entire world not to use [ef]grep.
Then of course the warnings have no effect :).
Otherwise, they certainly do. I have scripts that run [ef]hundreds of
times (in loops, on lots of files). grep is fundamental t
Hi Jim,
Some must care about portability,
Certainly agreed. Even I do, sometimes :). But that does not mean
everyone needs to, in every situation. As I said, I fail to understand
the benefit of making the warning unconditional.
So far as I can see, it's also against GNU principles, as
simpler solution to undeprecate the tools in documentation and have
them be official GNU-enhancements as they de-facto has been for the
past 20+ years
+20
My pet issue was the inconsistency between documentation and reality,
Agreed.
I think the simplest way to fix that is t
[ef]grep
I guess my basic issue is that I don't understand the benefit of the new
warning. It causes a lot of trouble. What is the countervailing
positive benefit?
$ grep '\Q' /dev/null
grep: warning: stray \ before Q
It would be nice to be able to turn those off too. (It hit me to
sj> Personally, I'd rather have tools exit with an error code on
invalid uses rather than issuing warning messages.
For me (and according to historical practice), an unnecessary \ is not
invalid. So, not surprisingly, I, on the other hand, would rather have
grep provide a way to turn off t
Actually, egrep and fgrep were not entirely portable
They were portable to every system I ever used (admittedly not the
entire world), before POSIX got involved.
These days, my impression is that it's more portable to use grep -E
than to use egrep.
I agree. And IMHO that is a bug PO
It is painful to see the unconditional complaint (grep 3.8) about
[ef]grep usage when those programs have been present since the beginning
of Unix. I have hundreds of scripts that use [ef]grep since for many
years they were either the only, or then later the most portable, way to
get the behavior.
See the attached patch. Less than 10 minutes' work. :-)
Thanks Arnold!
Grep guys - I'm pretty sure I've signed papwerwork for grep.
copyright.list confirms that you have :).
I chose '-g' since that letter was unused. It has no mnemonic value.
If a one-letter option is going to be
I suggest adding --no-ignore-case to clear the case-insensitivity -i
search. I, and surely many others, have an alias or script that runs
grep with -i by default, along with other options (since GREP_OPTIONS
was killed). It would be highly convenient to be able to add
--no-ignore-case on the fly to
Trying to compile grep-2.28 on centos6.8 (32-bit, but I don't think that
matters), with the system compiler (gcc 4.4.47-17) and system pcre, I get:
pcresearch.c:53: error: expected specifier-qualifier-list before
'pcre_jit_stack'
That line is:
pcre_jit_stack *jit_stack;
And indeed, /usr/inclu
The difference is that grep -a treats the NUL byte as text, whereas
LC_ALL=C grep treats it as binary.
I see. Thanks for the explanation.
The latter has been longstanding behavior for quite some time.
I surmise it has not hit many distros yet.
It's problematic because it means an
Either of the following shell commands should work with grep 2.25:
LC_ALL=C grep 31325 test
grep -a 31325 test
In my grep 2.25 (compiled from original source), these two commands are
not equivalent. (This is on 32-bit or 64-bit GNU/Linux, though I doubt
the platform matters.)
$ LC_A
grep 2.11 (compiled from the original source).
--exclude-dir is ok by itself, and -r is ok by itself, but in
combination I get a seg fault.
$ unset GREP_OPTIONS
$ \grep --exclude-dir=foo -r .
Segmentation fault
This is on CentOS 5.8, though I doubt it matters.
karl
I guess I don't follow the purpose of involving glibc now. Because
whatever changes they might or might not agree to make, they obviously
won't reach user systems for years. So for anyone to make use of the
new options, it all has to be implemented in gnulib regex anyway. If
the goal is to minim
Sorry for my stupidity. It is [[:space:]], of course. I knew that
.. not the first time I've forgotten it, though :).
1) Did not expect this to match, but it does (I see no space between an e
and an n?):
$ echo "overseen" | grep 'e[:space:]n'
overseen
2) Expected this to match, but it doesn't:
$ echo "are not" | grep 'e[:space:]n'
$
3) Compiled from original source.
$ grep --version
GNU grep 2.6.3
Thanks,
Can you make it fail with only -r? So far I've had to use also
--include or one of the --exclude* options.
I think you are right. I had forgotten that I had GREP_OPTIONS set with
various --exclude's. Very sorry about that.
http://thread.gmane.org/gmane.comp.gnu.grep.bugs/2765/focus
grep 2.6 and 2.6.1, compiled from original source (on CentOS 5.4).
grep -r foo . (all args I tried did the same) gets an immediate seg fault.
Compiling with gcc 4.4.3 (though I doubt it matters), also installed
from original source.
Running under gdb shows that path is NULL upon entry to isdir1 in
>> I notice that grep.texi now uses year ranges in its copyright notice.
>> I am confused, because I thought this was discouraged. Has thinking
>> changed on this?
No, thinking on this has not changed (ever).
> I've always seen obvious value in using ranges, and decreased value
Follow-up Comment #3, bug #17623 (project grep):
Use the same option name as in coreutils?
--dereference-command-line-symlink-to-dir
And FWIW, personally I'd be happy if
--dereference-command-line-symlink-to-dir became the new default (even me, Mr.
Backward Compatibility Rules :). I suspect tha
Follow-up Comment #2, bug #28329 (project grep):
Irrelevant to the ticket, but FWIW, I use GREP_OPTIONS to do excludes:
--directories=skip --exclude-dir=.svn --exclude=*~
The only problem I've had is with older greps that don't have the options.
So it goes.
___
PS: If this is a gnulib problem, please forward it to the bug-gnulib
list. My subscription procedure takes too long.
You don't have to subscribe to post to bug-gnulib (or any GNU bug list).
However, in this case the same people would be responsible either
way and they are on this list, so
So does it confirm that there is no way to use ']' is the RANGE
character set
FWIW, I also believe it is correct that ] cannot be specified as the endpoint
of a range in a bracket expression. This is because when ] is used in a
bracket expression, as far as I know it has to be the first c
As for these errors:
> "search.c", line 284: void function cannot return value
> "search.c", line 289: void function cannot return value
> "search.c", line 294: void function cannot return value
Line 284 is:
return GEAcompile (pattern, size,
Where GEAcompile is defined condit
Hi Tony,
There was a patch somewhere for dynamic loading of the PCRE library.
Would that solve this problem?
I doubt it. Probably introduce new (and worse) ones.
The current plan is to leave it as
Regardless of the pcre-config output (which I guess we aren't making
proper use of),
I very strongly suggest using the current released versions of autoconf
(2.63) and automake (1.10.2) to generate the infrastructure files.
In grep-2.5.4-20090126, search.c says:
#ifdef HAVE_LIBPCRE
# include
#endif
Unfortunately this does not work on my system, which is the oldish
Red Hat WS 4 (but compiling with the newish gcc 4.2.4). On that system,
it's . When I change the #include, everything compiles
(with some mbs warnings)
Hi Tony,
Is there a "correct" or "preferred" resolution?
Yes, I simply forgot to add the file. Done now, as you've seen.
Sorry.
karl
It's probably useful to add this functionality to all coreutil filters.
Wouldn't it suffice to add buffer control options to cat, rather than
every program?
I still need to be convinced that glibc is not the correct place for
this. If it was there then any users of stdio could be con
And a question to the community: is --uncompress a good option name? Any
objections? Zlib uses the term 'decompress'.
Since gunzip (among others) uses the option name --decompress, grep
should too.
k
Any plans to integrate libbzip2 as well?
If anything is done to support bzip2, I strongly suggest thinking about
lzma support too, since lzma is better than bzip in both space and time.
I say "thinking about" because the lzma file format is being changed
(for the better) just now.
Looking at GNU Hello, it appears the problem was
eliminated by using gnulib
Yes, that's what I did in Hello and that's what I think is ultimately
the best course of action, although not necessarily for this upcoming
release. As Andreas said, though, it's certainly possible to use
gettext
I don't know what's different in CentOS 5 that's causing these tests to
Apparently it is something in the Czech locale support, and maybe color?
It's going to take someone more conversant with Czech than I am (in my
complete ignorance :) to really debug it.
For instance, the first failure in
grep doesn't use gnulib.
It should (one way or another), but admittedly that is a different story
and presumably not one for this release.
(I can't see that the config.* files are ever modified either.)
grep, like all GNU packages, should use the latest released config.*
files whene
Does this mean that the README-alpha file is included only in test
releases?
Yes.
I think grep always includes it in 'make dist'.
Using the readme-alpha feature in Automake will make it conditional.
Use this in configure.ac[.in]:
AM_INIT_AUTOMAKE([dist-bzip2 readme-alpha])
I wa
As for your task, try something like:
tail -1000 access_log | grep mygregexp
Another possibility is tac access_log | grep ...
Since autoreconf just runs the other autotools, how is this a problem with
autoreconf specifically?
All I'm telling you is what I have observed (and talked with Ralf and
others on the autoconf list about, too). If I run autoreconf, I get
older files copied in. If I run
$ACLOCAL -I gnuli
README-alpha is not a very obvious name either if you're
building from CVS.
True. The purpose of README-alpha is to be a README file for people
trying test releases.
For information about development builds, I suggest a different file. I
use README.dev.
I'll attach both files as I wro
1. Use autoreconf instead of calling all the autotools.
My experience is that autoreconf can copy older files over newer ones.
If you update common files (like config.* and texinfo.tex) via gnulib or
by hand, autoreconf will not necessarily preserve them. It's not
so simple to fix this proble
I tried compiling the new test release at
http://alpha.gnu.org/gnu/grep/grep-2.5.4-20080209b.tar.gz with gcc 4.2.3
on CentOS 5. configure gave this warning:
config.status: WARNING: intl/Makefile.in seems to ignore the --datarootdir
setting
... which is because gettext has apparently not been u
I tried compiling the new test release at
http://alpha.gnu.org/gnu/grep/grep-2.5.4-20080209b.tar.gz with gcc 4.2.3
on CentOS 5. There were two compilation warnings (which were repeated
for each search.c compilation, of course; I'll spare you the repetitions).
In file included from ../lib/regex.h:
I tried compiling the new test release at
http://alpha.gnu.org/gnu/grep/grep-2.5.4-20080209b.tar.gz with gcc 4.2.3
on CentOS 5. Two tests failed: foad1 and fmbtest. Since there are
binary characters involved, I'll include the output as an attachment.
karl
testfail.txt
Description: Binary data
mkdir_p = $(top_builddir)/./install-sh -c -d
The big problem with this is that top_builddir is defined after
mkdir_p
Definition-before-use is not required with make assignments like this.
This causes "make install" to fail.
What was the actual failure?
karl
We will need to add a meta string representing new lines
Any meta string will break compatibility too, of patterns that used the
meta string. I think the only thing to do is add an option like
--match-newlines-in-pattern. Which sounds like an incredible headache,
grep being so strongly line
So, sorry. For now, my source for regex is GLIBC. If / when gnulib
If that works better for you, fine. It makes little difference in terms
of the actual code.
For anyone using gnulib already (as I hope grep will), regex might as
well come from there too.
regex can be dropped into gawk
just as GLIBC is the canonical source for regex*.[hc].
glibc => gnulib. (The gnulib version is nearly the same as libc's,
except it has some portability and other fixes that aren't in libc yet.)
karl
Hi Tony,
I propose that we remove these tests from the release, but keep them in
CVS, and make a new release. Comments?
I'm not sure I understand.
If the tests are validly reporting bugs in grep, then I think it would
be better to keep them in CVS, and just not execute them, so that one
49 matches
Mail list logo
