messages are in a different style than used in the grep git
repo; I'll fix them up depending on how exactly they should be
bundled together.
- Though I have attempted to follow the GNU coding style, my own
usual coding style differs from it quite a bit, and there may as a
result be some stylistic misfits here and there. I'm happy to fix
any of these anyone points out.
Any/all feedback welcome.
Thanks,
Zev Weiss
On Tue, Jun 09, 2015 at 11:00:34AM +0100, Aaron Crane wrote:
Zev Weiss wrote:
At a high level: I've added a new flag, -M/--parallel[=N], that
enables multithreaded operation.
Thanks, this looks really interesting.
I'd like to suggest changing the code to use -j/--jobs as the na
On Tue, Jun 09, 2015 at 12:04:11PM +0100, Aaron Crane wrote:
Zev Weiss wrote:
Hmm -- I picked --parallel largely for consistency with the corresponding
flag for coreutils' sort, which strikes me as a closer relative to grep than
either make or parallel.
That's a good point; I wasn&
On Tue, Jun 09, 2015 at 12:05:57AM -0700, Paul Eggert wrote:
Thanks very much for looking into this. I'll take a look at it in
more detail once the paperwork goes through. I use grep -r a lot, and
would appreciate the speedup.
OK, I've received confirmation from Donald Robertson at the FSF t
On Thu, Jun 11, 2015 at 11:44:28AM -0500, Zev Weiss wrote:
On Tue, Jun 09, 2015 at 12:05:57AM -0700, Paul Eggert wrote:
Thanks very much for looking into this. I'll take a look at it in
more detail once the paperwork goes through. I use grep -r a lot,
and would appreciate the speedup.
e
someone more familiar with the codebase can probably fix them much more
quickly than I could.
Zev
>From 4e43b4d57997e7a4c08cf0134f62e486843df4e3 Mon Sep 17 00:00:00 2001
From: Zev Weiss
Date: Sun, 25 Oct 2015 21:59:32 -0500
Subject: [PATCH] dfa: plug a memory leak in dfamust ().
* src/dfa.c
GCC's ASAN & UBSAN enabled -- tests for grep proper all passed in
both cases, though ASAN still reported some memory leaks from the gnulib
test suite (I didn't look closely at exactly what they were, but could
provide logs if it's of interest).
Zev Weiss
-expensive tests
pass for me on Debian stretch with gcc 5.3, glibc 2.22, and Linux kernel
4.3.
Zev Weiss
On Sun, Apr 10, 2016 at 09:45:49PM -0700, Paul Eggert wrote:
This works for me:
grep --color=always -E 'word1|word2'
Isn't that a different search? The original question asked about
colorizing both patterns in the output of
grep word1 | grep word2
(i.e. lines that contain *both* word1 a
hing in the master thread, but I'd guess it's
probably negligible in most cases, and isn't really the goal of the
patches.]
Zev Weiss
Hello,
I noticed a subtle bug was recently introduced (by commit af6af288) in
grep's tests/status -- I believe the attached patch should fix it.
Thanks,
Zev
>From 198922006962729dc785b812c5243867a3083770 Mon Sep 17 00:00:00 2001
From: Zev Weiss
Date: Fri, 3 Jun 2016 01:28:11 -0500
| 105 ++--
3 files changed, 51 insertions(+), 58 deletions(-)
Thanks,
Zev Weiss
* src/grep.c (main): replace bitwise ORs with logical ORs where it
makes sense (when dealing with boolean conditions as opposed to
bitmasks).
---
src/grep.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/grep.c b/src/grep.c
index d812bae..9776507 100644
--- a/src/grep.
* src/dfa.c (parse_bracket_exp): mark zeroclass const.
* src/dfasearch.c: mark patterns0 const.
---
src/dfa.c | 2 +-
src/dfasearch.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/dfa.c b/src/dfa.c
index 4e47b39..19363ce 100644
--- a/src/dfa.c
+++ b/src/dfa.c
@@
* src/grep.c (grepdirent): Remove dirdesc variable and just use
fts_cwd_fd directly, since the fts_options test was guaranteed to
succeed (and fts_cwd_fd was already being used directly in fstatat()
anyway).
---
src/grep.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/sr
* src/grep.c (reset, main): We're going to need pagesize and buffer
initialized anyway, so we might as well do so unconditionally early on
rather than checking on every call to reset().
---
src/grep.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/src/grep.c
* src/grep.c: Make list_files a tristate enum instead of an int.
---
src/grep.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/src/grep.c b/src/grep.c
index 4fa56cf..eadc2be 100644
--- a/src/grep.c
+++ b/src/grep.c
@@ -929,6 +929,14 @@ static enum
WI
* src/grep.c (grepdesc): The `grep()' function no longer has
special-case negative return values, since it no longer handles
directories, so don't bother checking for them.
---
src/grep.c | 61 +++--
1 file changed, 27 insertions(+), 34 delet
ux-gnu) [if
that's of any relevance]
Thanks,
Zev Weiss
The
first three should have no impact on any users, however.
(The bulk of the changes in these patches are fairly mechanical; for
some of them something like `git show --color-words' on a local branch
might make the review process slightly less tedious.)
Combined diffstat for these six follow
* src/dfa.c: remove global dfa struct. A pointer to a struct dfa is
instead added as a parameter to the functions that had been using the
global.
---
src/dfa.c | 207 +-
1 file changed, 98 insertions(+), 109 deletions(-)
diff --git a/sr
* src/dfa.c: move global variables holding lexer state into a new
struct (`struct lexer_state') and add an instance of this struct to
struct dfa. All references to the globals are replaced with
references to the dfa struct's new member.
---
src/dfa.c | 294 ++--
* src/dfa.c: move global variables holding regex syntax configuration
into a new struct (`struct regex_syntax') and add an instance of it to
struct dfa. All references to the globals are replaced with
references to the dfa struct's new member. As a side effect, a
`struct dfa' must be allocated wi
* src/dfa.c: Replace utf8 and unibyte_c static local variables with
static globals initialized by a new function dfa_init() which must be
called before any other dfa*() functions.
(dfa_using_utf8): Rename using_utf8() to dfa_using_utf8() for
consistency with other exported functions.
* src/dfa.h (d
* src/dfa.c (dfasyntax): Remove initialization of mbrtowc_cache.
(init_mbrtowc_cache): New function.
(dfa_init): Call init_mbrtowc_cache().
---
src/dfa.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/src/dfa.c b/src/dfa.c
index 970b51f..e577393 100644
-
* src/dfa.c: move global variables holding parser state (`tok' and
`depth') into a new struct (`struct parser_state') and add an instance
of it to struct dfa. All references to the globals are replaced by
references to the dfa struct's new member.
---
src/dfa.c | 92 ++
On Sat, Aug 20, 2016 at 01:09:20AM +0900, Norihiro Tanaka wrote:
On Thu, 18 Aug 2016 05:50:14 -0500
Zev Weiss wrote:
* src/dfa.c: remove global dfa struct. A pointer to a struct dfa is
instead added as a parameter to the functions that had been using the
global.
Hi,
Why we move global
On Fri, Aug 19, 2016 at 09:37:54AM -0700, Jim Meyering wrote:
On Thu, Aug 18, 2016 at 7:46 AM, Jim Meyering wrote:
On Thu, Aug 18, 2016 at 3:50 AM, Zev Weiss wrote:
* src/dfa.c: remove global dfa struct. A pointer to a struct dfa is
instead added as a parameter to the functions that had
On Sat, Aug 20, 2016 at 07:34:20AM +0900, Norihiro Tanaka wrote:
On Sat, 20 Aug 2016 07:25:06 +0900
Norihiro Tanaka wrote:
Hi Zev,
Thanks for replying. I say a reverse thing.
I believe that there is no problem if only dfaexec() is thread safe. In
other words, I think that variables that we
On Sat, Aug 20, 2016 at 05:52:09PM -0700, Jim Meyering wrote:
On Thu, Aug 18, 2016 at 3:50 AM, Zev Weiss wrote:
Hello,
Thank you for separating those so nicely.
I have pushed your patches 2..6, now, so will close this.
The only changes I made were to the formatting and member ordering of
On Sun, Aug 21, 2016 at 08:40:59AM +0900, Norihiro Tanaka wrote:
On Fri, 19 Aug 2016 18:03:19 -0500
Zev Weiss wrote:
Okay -- so your question is about the necessity of making operations other than
dfaexec() thread-safe? That's reasonable, though (obviously) I went ahead made
the
On Sat, Nov 19, 2016 at 12:36:12AM -0800, Paul Eggert wrote:
Stephane Chazelas wrote:
one can
use (?m) if he wants ^ to match the beginning of each line in
the NUL-delimited record instead of just the beginning of the
record.
I think the intent is that ^ and $ should match only the
line-termi
On Tue, Feb 07, 2017 at 03:01:11PM -0800, Paul Eggert wrote:
Thanks for reporting the problem. It looks like we did not
sufficiently test 'grep' on older systems when we made some fixes that
anticipate adding multithreading support. I installed the attached
patch to fix the problem, and this sh
On Tue, Apr 25, 2017 at 02:45:14AM CDT, L. A. Walsh wrote:
/usr/bin/grep --color=auto -I -D skip -d skip -exclude-from=EX -P -r xrm
/usr/bin/grep: xrm: No such file or directory
/usr/bin/grep --version
/usr/bin/grep (GNU grep) 2.21.31-adf9
How did 'xrm' become a file name?
It happened after
* src/grep.c (matchers): Mark const.
---
src/grep.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/grep.c b/src/grep.c
index 2277a60..0643a7e 100644
--- a/src/grep.c
+++ b/src/grep.c
@@ -2003,7 +2003,7 @@ if any error occurs and -q is not given, the exit status
is 2.\n"))
* src/grep.c (grepdirent): Don't twiddle out_file back and forth
during recursion.
(main): Set out_file once based on command-line arguments.
* bootstrap.conf (gnulib_modules): Add isdir gnulib module.
---
bootstrap.conf | 1 +
src/grep.c | 18 --
2 files changed, 9 insertions
On Fri, Nov 03, 2017 at 03:45:07AM CDT, Paul Eggert wrote:
Zev Weiss wrote:
-static struct
+static const struct
{
char const name[12];
There's already a const after the } at the end of the struct, so this
'const' is not needed. The usual style in 'grep' is to p
On Fri, Nov 03, 2017 at 03:46:59AM CDT, Paul Eggert wrote:
This adds a syscall, which sounds like both a performance loss
This I considered while writing the patch, but decided was unlikely to
be significant. The isdir() is only evaluated in the case of receiving
exactly one command-line arg
On Sat, Nov 04, 2017 at 01:55:51AM CDT, Paul Eggert wrote:
Zev Weiss wrote:
I'm wondering how robust (paranoid?) grep really needs to be in the
face of concurrent filesystem modifications.
Not that paranoid. Still, it's better for grep to avoid races when
it's easy, as is the
On Fri, Sep 04, 2020 at 11:12:07AM CDT, Jim Meyering wrote:
On Tue, Sep 1, 2020 at 4:22 AM Paul Eggert wrote:
On 9/11/14 1:13 PM, Paul Eggert wrote:
> Thanks, but there's no need for that; just have 'grep' complain if the option
is
> used and O_NOATIME == 0.
On looking into this more today, O
40 matches
Mail list logo
