> From: Jim Meyering
> Cc: arn...@skeeve.com, bug-grep@gnu.org
> Date: Mon, 03 Oct 2011 13:27:12 +0200
>
> > I get a negative value for 0x95 from `lex'. An explicit `fprintf'
> > after this line:
> >
> > (c) = wctob(wc);
> >
> > shows that the value of `c' is -107. The value return
> From: Jim Meyering
> Cc: bug-grep@gnu.org, e...@gnu.org
> Date: Sun, 02 Oct 2011 21:45:01 +0200
>
> Eli, can you confirm that this also solves the problem
No, it doesn't. The branch of the code that calls wctob was where the
trouble was happening to begin with. The patch below, which still
> From: Jim Meyering
> Cc: arn...@skeeve.com, bug-grep@gnu.org
> Date: Mon, 03 Oct 2011 10:17:44 +0200
>
> Eli Zaretskii wrote:
>
> >> From: Jim Meyering
> >> Cc: bug-grep@gnu.org, e...@gnu.org
> >> Date: Sun, 02 Oct 2011 21:45:01 +0200
> &g
> From: Jim Meyering
> Cc: arn...@skeeve.com, bug-grep@gnu.org
> Date: Mon, 03 Oct 2011 18:41:25 +0200
>
> > This version of wctob solves the problem.
>
> Good. Thanks for confirming that.
> Then I suggest that users of dfa.c like gawk arrange to use that.
> grep and any users that (by use of
The Grep test suite includes the grep-dir test, which does this:
mkdir a || framework_failure
echo x | grep -f a/; { test $? -gt 1 && test $? -lt 128; } || fail=1
echo x | grep -if a/; { test $? -gt 1 && test $? -lt 128; } || fail=1
echo x | grep -Ff a/; { test $? -gt 1 && test $? -lt 128
> Date: Mon, 19 Dec 2011 09:40:15 -0800
> From: Paul Eggert
> CC: bug-grep@gnu.org
>
> On 12/19/11 09:21, Eli Zaretskii wrote:
> > why does it use an empty directory and not an empty file?
>
> Because it's testing that grep does the right thing when
> asked
> Date: Mon, 19 Dec 2011 11:09:30 -0700
> From: Eric Blake
> CC: bug-grep@gnu.org
>
> Gnulib is able to emulate fopen(".", "r") with sane semantics on mingw
> (by opening the null device under the hood, so that any actual fread()
> of the FILE* will return immediate EOF); but it looks like grep i
> Date: Mon, 19 Dec 2011 13:34:32 -0700
> From: Eric Blake
> CC: bug-grep@gnu.org
>
> > Thanks. FWIW, it doesn't look like anyone cares about Grep working on
> > Windows as a native program, because the simplest commands, something
> > like "grep -R foo .", cause Grep to emit an error message an
> Date: Mon, 19 Dec 2011 13:34:32 -0700
> From: Eric Blake
> CC: bug-grep@gnu.org
>
> The intent of the test is that grep should behave differently when
> operating on a directory instead of a regular file.
Can you elaborate on that difference in behavior? I mean the
difference between
echo
> Date: Tue, 20 Dec 2011 15:58:40 +0100
> From: Paolo Bonzini
>
> >echo foo | grep -f empty-directory/
>
> This should be a hard failure. Asking grep to open a directory and
> search for patterns in it is wrong.
Well, I agree. But the test suite doesn't.
> >echo foo | grep -f empty-
I'm not sure this warrants a Savannah bug report, but if tell me it
does, I will submit one.
During the past few days I needed to investigate several failures of
Grep 2.9 and 2.10 tests on MS-Windows. I must say that I found the
test suite less user-friendly than I'd like, when it comes to diggin
> Date: Mon, 19 Dec 2011 13:34:32 -0700
> From: Eric Blake
> CC: bug-grep@gnu.org
>
> > FWIW, it doesn't look like anyone cares about Grep working on
> > Windows as a native program, because the simplest commands, something
> > like "grep -R foo .", cause Grep to emit an error message and quit (I
This changeset fixes "grep -r" on MS-Windows (and also on MS-DOS).
Without it, Grep produces an error message "foo: Permission denied"
and quits.
Fix "grep -r" on MS-Windows and MS-DOS.
* src/system.h (is_EISDIR) [__MINGW32__ || __DJGPP__]: A different
definition for DOS/W
This changeset fixes a few problems in the test suite which fail some
tests due to reasons that have nothing to do with Grep per se.
Fix the test suite for MS-Windows.
* tests/reversed-range-endpoints: Don't reject program names with
leading directories and drive letters.
This changeset implements color highlighting of Grep matches on the
MS-Windows console (which does not directly support SGR sequences).
The code which produces SGR sequences is still present in the
MS-Windows build, and executed when stdout is not a console device,
because various programs, such as
This final changeset fixes a few general problems, and adds a couple
of NEWS entries.
Fix whitespace, indentation and documentation
* src/main.c (parse_grep_colors): Fix indentation.
(usage): Mention MS-Windows in help text for -U and -u options.
* NEWS: Mention M
> From: Jim Meyering
> Cc: bug-grep@gnu.org
> Date: Sat, 24 Dec 2011 15:57:23 +0100
>
> Can you rebase this series to be relative to the latest,
> now that I've pushed Paul's two fixes?
Not easily, but I will try.
> Date: Sat, 24 Dec 2011 13:46:28 -0800
> From: Paul Eggert
> CC: bug-grep@gnu.org
>
> How about something like this instead?
>
>#include "colorize.h"
>
> Where colorize.h looks like this:
>
>#define PR_SGR_START(s)PR_SGR_FMT( SGR_START, (s))
>#define PR_SGR_END(s) PR_SG
> From: Jim Meyering
> Cc: Eli Zaretskii , bug-grep@gnu.org
> Date: Wed, 28 Dec 2011 17:07:12 +0100
>
> Finally, Eli does not yet have an assignment on file for grep.
That must be some clerical mistake. You will see in the old
ChangeLog-2009 (btw, why is it absent from the late
> Date: Wed, 28 Dec 2011 17:06:05 +0100
> From: Bastien ROUCARIES
> Cc: Eli Zaretskii , bug-gnulib ,
> bug-grep@gnu.org
>
> Isatty is broken under windows but this not the right fix.
What's wrong about it? If it fails under some conditions, please
describe them.
> From: Jim Meyering
> Cc: bonz...@gnu.org, bug-grep@gnu.org
> Date: Wed, 28 Dec 2011 18:17:46 +0100
>
> > that I was contributing non-trivial code to Grep since 1997. In
> > particular, dosbuf.c was written by yours truly.
>
> Just because you contributed before does not guarantee that there
> Date: Wed, 28 Dec 2011 11:39:23 -0800
> From: Paul Eggert
> CC: Jim Meyering , Eli Zaretskii ,
> bug-grep@gnu.org
>
> Here's the sort of thing I had in mind. It works fine on non-Windows
> platforms but I don't know about Windows. The idea is to move the
>
> Date: Wed, 28 Dec 2011 13:34:18 -0800
> From: Paul Eggert
> CC: bonz...@gnu.org, j...@meyering.net, bug-grep@gnu.org
>
> > I see no machinery in place to
> > have the Windows build use the lib/ms files. What am I missing?
>
> Nothing. I don't know how the Windows build works.
Yes, you do ;-
> From: Jim Meyering
> Cc: Eli Zaretskii , bonz...@gnu.org, bug-grep@gnu.org
> Date: Fri, 30 Dec 2011 11:37:59 +0100
>
> I find the new semantics undesirable.
> SAME_INODE as a boolean is easy to read.
> When it becomes ternary, you have to handle the new possibilit
> From: Jim Meyering
> Cc: egg...@cs.ucla.edu, bonz...@gnu.org, bug-grep@gnu.org
> Date: Fri, 30 Dec 2011 12:28:40 +0100
>
> > Bottom line: just add a test against zero inodes to SAME_INODE, and be
> > done. You can then remove the test in main.c for that, as a bonus.
>
> As explained at leng
> From: Jim Meyering
> Cc: egg...@cs.ucla.edu, bonz...@gnu.org, bug-grep@gnu.org
> Date: Fri, 30 Dec 2011 13:38:17 +0100
>
> This is about changing code that everyone uses, in order to
> make it accommodate a system that is so fundamentally deficient
> that imho it is not a reasonable portabili
> From: bastien ROUCARIES
> Date: Fri, 30 Dec 2011 12:36:07 +0100
> Cc: bonz...@gnu.org,
> bug-gnu...@gnu.org,
> bug-grep@gnu.org
>
> > > In fact isatty under windows is equivalent to test if a file is a char
> > > device.
> >
> > That is true. But unless a Windows user goes out of their way,
> From: Jim Meyering
> Cc: bonz...@gnu.org, bug-grep@gnu.org
> Date: Fri, 30 Dec 2011 16:13:56 +0100
>
> > Anyway, I don't mind signing papers even if I already did once.
>
> Thanks.
> Here are some instructions:
> http://git.sv.gnu.org/cgit/coreutils.git/tree/HACKING#n454
Given that the code
> Date: Fri, 30 Dec 2011 14:47:59 -0800
> From: Paul Eggert
> CC: Eli Zaretskii , bonz...@gnu.org, bug-grep@gnu.org
>
> For consistency, shouldn't grep do something similar when checking
> whether the input file is the same as the output file? Not only
> is this more
> From: Bruno Haible
> Cc: bastien ROUCARIES , Eli Zaretskii
> , Eric Blake , bonz...@gnu.org,
> bug-grep@gnu.org
> Date: Tue, 03 Jan 2012 03:56:56 +0100
>
> I'm adding this new module. Feel free to use it in 'grep'.
Thanks
> #define IsConsoleHandle
> From: Bruno Haible
> Cc: bug-gnu...@gnu.org, roucaries.bast...@gmail.com, ebl...@redhat.com,
> bonz...@gnu.org, bug-grep@gnu.org
> Date: Tue, 03 Jan 2012 14:03:11 +0100
>
> Eli Zaretskii wrote:
> > > HANDLE h = (HANDLE) _get_osfhandle (fd);
> >
&g
> Date: Fri, 01 Feb 2013 00:17:42 -0800
> From: Paul Eggert
> Cc: bug-grep@gnu.org
>
> I think Eric Blake was talking about glibc regex.h in the
> context of glibc, whereas you're talking about it in a different
> context, where glibc regex.h is combined with some non
> glibc standard headers. Y
> From: Paul Eggert
> Date: Sun, 23 Mar 2014 17:21:35 -0700
>
> Although egrep's and fgrep's switch from shell scripts to
> executables may have made sense in 2005, it complicated
> maintenance and recently has caused subtle performance bugs.
> Go back to the old way of doing things, as it's simp
> From: Jim Meyering
> Date: Tue, 13 May 2014 09:35:41 -0700
> Cc: 17...@debbugs.gnu.org, Paul Eggert
>
> > Windows? It has PowerShell, not POSIX shell.
>
> And one cannot install a POSIX shell?
No. There's no decent native port of a Posix shell for Windows. The
only one that is usable is t
> Date: Tue, 13 May 2014 09:51:38 -0700
> From: Paul Eggert
> Cc: 17...@debbugs.gnu.org
>
> However, it shouldn't hurt to port GNU grep to the PowerShell
> environment
Please don't bother. PowerShell is crap, and any investment in it, in
the GNHU project or elsewhere, is a waste of resources.
> Date: Thu, 15 May 2014 01:04:52 +0900
> From: Norihiro Tanaka
> Cc: Paolo Bonzini , Paul Eggert
>
> I submit a fix of the previous patch.
Thank you.
> By the way, however, I can't understand why you adhere to keep using
> egrep and/or fgrep instead of `grep -E' or `grep -F' on minor platform
> From: arn...@skeeve.com
> Date: Wed, 14 May 2014 11:44:32 -0600
> Cc: bonz...@gnu.org
>
> Paul Eggert wrote:
>
> > ..., as would a simple C file whose main
> > function uses execlp to run the grep executable.
>
> Except on platforms that don't *have* execlp...
>
> I really think that moving
> Date: Wed, 14 May 2014 11:40:10 -0700
> From: Paul Eggert
> CC: bonz...@gnu.org, 17...@debbugs.gnu.org
>
> How do you invoke grep? You don't use PowerShell (and thank you for
> letting us know it's a waste of time), and I guess you don't use a POSIX
> shell (since you're objecting to a shell
> Date: Wed, 14 May 2014 12:33:35 -0700
> From: Paul Eggert
> CC: nori...@kcn.ne.jp, bonz...@gnu.org, 17...@debbugs.gnu.org
>
> On 05/14/2014 12:28 PM, Eli Zaretskii wrote:
> > Stock Windows shell, of course, cmd.exe.
>
> Aren't console aliases a standard sort
> Date: Wed, 14 May 2014 11:34:34 -0700
> From: Paul Eggert
> Cc: bonz...@gnu.org
>
> On 05/14/2014 10:44 AM, arn...@skeeve.com wrote:
>
> > Except on platforms that don't*have* execlp...
>
> Gnulib maintains a list of portability issues for many POSIX functions.
> None of the issues current
> From: Михаил Гаврилов
>
> Date: Thu, 26 Jan 2017 16:17:42 +0500
>
> Windows version grep not search two non ASCII words separated by space
> More details described here: https://github.com/geany/geany/issues/1366
> Last workable version is 2.24
The detailed description indicates that the
> From: Eric Blake
> Date: Mon, 13 Feb 2017 14:20:56 -0600
>
> > While we're on the topic, the undossify_input approach is just a
> > heuristic and it sometimes guesses wrong. I wish the heuristic could be
> > removed somehow, so that grep would behave more deterministically on
> > MS-DOS/Windows
> Cc: egg...@cs.ucla.edu, 25...@debbugs.gnu.org
> From: Eric Blake
> Date: Thu, 16 Feb 2017 11:40:29 -0600
>
> On 02/16/2017 11:26 AM, Eli Zaretskii wrote:
>
> >> I'm of the opinion that undossify_input causes more problems than it
> >> solves. We shou
> Cc: 25...@debbugs.gnu.org
> From: Paul Eggert
> Date: Thu, 16 Feb 2017 09:45:43 -0800
>
> On 02/16/2017 09:26 AM, Eli Zaretskii wrote:
> > It seems to me that when one bumps into some code which looks
> > incorrect or less than optimal, and one considers its replace
44 matches
Mail list logo
