There were several posts to the list after grep-2.15 was released in
October about fixing bugs and releasing grep-2.16. For example:
http://lists.gnu.org/archive/html/bug-grep/2013-10/msg00082.html
What's the status of grep-2.16?
-- Bruce
akes a change and uses a different tab setting and makes it
look ugly, either in a pager or an editor.
Bottom line is to not permit patches with tabs.
-- Bruce Dubbs
linuxfromscratch.org
P.S. There was a considerable amount of research in the 1980s that
investigated cognitive interpr
Jim Meyering wrote:
Tabs in code are indeed evil. Different users have different tab stops.
I would convert *all* tabs to spaces and add to each file:
/* -*- tab-width:8; intent-tabs-mode:nil; -*- */
/* ex: set tabstop=8 expandtab: */
For the record, I think that such comments should be mad
Jim Meyering wrote:
On Fri, Mar 14, 2014 at 9:32 PM, Bruce Dubbs wrote:
...
For the record, I think that such comments should be made unnecessary.
I.e., maintain coding standards with enough automated infrastructure
that that type of crutch is not required. See the guidelines in
coreutils
Assaf Gordon wrote:
Hello,
On 10/29/2014 02:29 PM, Jim Meyering wrote:
Thanks to many fixes and improvements by Paul Eggert and Norihiro Tanaka,
here is a pre-release snapshot:
grep snapshot:
http://meyering.net/grep/grep-ss.tar.xz 1.2 MB
http://meyering.net/grep/grep-ss.tar.xz.sig
st,
and am hoping the attached will fix it by requiring use of
the zh_CN.UTF-8 locale, rather than letting the system
choose a locale matching "zh_CN". Does this patch solve
the problem for that test?
On Wed, Oct 29, 2014 at 2:56 PM, Bruce Dubbs wrote:
Assaf Gordon wrote:
Hello,
On 10
Jim Meyering wrote:
On Wed, Oct 29, 2014 at 2:56 PM, Bruce Dubbs wrote:
...
http://meyering.net/grep/grep-2.20.72-d512.tar.xz
...
Linux From Scratch 7.6
configure and make were clean.
$ env RUN_EXPENSIVE_TESTS=yes make -k check
big-match: skipped test: not enough main memory to run
e start address is 7ffa5405d010.
The end address is 7ffaf405d010.
What am I missing?
-- Bruce
On Sat, Nov 1, 2014 at 7:56 PM, Bruce Dubbs wrote:
Jim Meyering wrote:
On Wed, Oct 29, 2014 at 2:56 PM, Bruce Dubbs
wrote:
...
http://meyering.net/grep/grep-2.20.72-d512.tar.xz
...
Linu
Jim Meyering wrote:
Testing the first snapshot exposed several problems,
and most have been addressed. The sole remaining problem
is the failure of an "expensive" (not run by default: big-match)
that makes most systems run out of memory. I haven't looked at it yet.
Shouldn't the big-match test
system the pcre and git tests also:
SKIP: big-hole
SKIP: big-match
SKIP: long-line-vs-2GiB-read
SKIP: sjis-mb
XFAIL: triple-backref
SKIP: test-vc-list-files-cvs.sh
SKIP: test-wcrtomb-w32-1.sh
SKIP: test-wcrtomb-w32-2.sh
SKIP: test-wcrtomb-w32-3.sh
SKIP: test-wcrtomb-w32-4.sh
SKIP: test-wcrtomb-w32-5
source tarball.
The one line (one character) fix is:
sed -i 's/copyright{/copyright\\{/' build-aux/update-copyright
Translation: Escape the left brace in a perl regex.
I reported this to gnulib over a month ago but got no response. Thought
you would like to know.
-- B
Jim Meyering wrote:
grep snapshot:
http://meyering.net/grep/grep-ss.tar.xz 1.3 MB
http://meyering.net/grep/grep-ss.tar.xz.sig
http://meyering.net/grep/grep-2.21.82-fbc5.tar.xz
I tested in a linuxfromscratch environment. See
http://www.linuxfromscratch.org/lfs/view/stable/chapter0
Paul Eggert wrote:
Bruce Dubbs wrote:
I tested in a linuxfromscratch environment. See
http://www.linuxfromscratch.org/lfs/view/stable/chapter03/packages.html for
a
list of all packages.
You're getting one unexpected failure, from pcre-jitstack. That package
list doesn't men
Jim Meyering wrote:
Thanks for testing.
However, that failure probably indicates that you are running
a binary that uses an older version of libpcre. Compare the results
of these commands on a Centos6 system:
$ gcc print-pcre-version.c -lpcre; ./a.out
7.8 2008-09-05
$ gcc print-pcre-v
Paul Eggert wrote:
Bruce Dubbs wrote:
I would think that the tests in grep should account for both pcre and
pcre2, at
least for a couple of years.
Grep currently supports only PCRE. I'd be surprised if it worked with
PCRE2.
My test was with PCRE 8.35 with Debian and Ubuntu patches (I
Jim Meyering wrote:
Thanks for investigating.
I wonder why your libpcre-8.37 needs so much stack and mine
(built from the release tarball by me, with no patch) segfaults only
when I restrict stack to less than about 50 KB.
I.e.,this exits with status 1:
( ulimit -s 50; LC_ALL=C src/grep -P -
Paul Eggert wrote:
Bruce Dubbs wrote:
( ulimit -s 50; LC_ALL=C src/grep -P -n '^([/](?!/)|[^/])*~/.*'
pcrejit.txt )
but changing to a ulimit of 40 KB, it consistently segfaults.
That also jibes with what valgrind --tool=massif --stacks=yes reports.
$ valgrind --tool=massif --
ailure shows up in m4 and
diffutils. See gnulib-tests/test-update-copyright.sh
-- Bruce Dubbs
linuxfromscratch.org
Paul Eggert wrote:
$ printf '\200\n' | LC_ALL=C grep .
Binary file (standard input) matches
This is because the C locale is pure ASCII on these platforms, i.e.,
'\200' is not a valid character the way it is with traditional Unix. I
don't know why Red Hat made that change.
I also get the 'Bin
0inputs+0outputs (0major+3186885minor)pagefaults 0swaps
-- Bruce Dubbs
LFS
Greta wrote:
Dear grep developer,
I am Greta Romano and I need your help as soon as possibile.
I want to use grep command to search a string of 6 characters in every
line of a file (biological file with DNA nucleotide).
The problem is that I need to search these 6 characters in the first 30
ch
Paul Eggert wrote:
Thanks for reporting that. It's a reasonably serious bug. I installed the
attached patch to fix it.
Thanks for the patch. Are you going to consider releasing 2.28.1 soon?
LFS is going into a package freeze in a few days and we would prefer a new
version to a patch.
--
Marcel Partap wrote:
Hi,
is there any way to make grep place a space before and after the line number
instead of a colon?
*./src/ui_download_manager.cc:36:namespace cwidget
With many terminals not including the : as a word separator SHIFT+double click
on the filename selects
filename:line:
cluded-regex' to get the fix.
Will there be a new grep release soon?
-- Bruce Dubbs
linuxfromscratch.org
is hard for me
to email the actual log contents(I am writing from outside). Let me know if
you need the test-suite.log file.
Obviously, the report is out of date. Here is the log for the LFS
reference build of grep 3.3:
http://www.linuxfromscratch.org/lfs/build-logs/8.4/test-logs/099-
grep-
-2.31 and gcc-9.2.0 if that makes a difference.
-- Bruce Dubbs
linuxfromscratch.org
On 4/6/20 6:48 PM, Paul Eggert wrote:
On 4/6/20 1:54 PM, Bruce Dubbs wrote:
Program received signal SIGSEGV, Segmentation fault.
0x0041cc03 in __libc_start_main ()
(gdb) bt
#0 0x0041cc03 in __libc_start_main ()
#1 0x0040715a in _start () at ../sysdeps/x86_64/start.S
On 9/11/22 14:45, Sam wrote:
On 11 Sep 2022, at 21:41, Jim Meyering wrote:
On Thu, Sep 8, 2022 at 4:01 PM Karl Berry wrote:
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
it is as a Christmas present.
Thanks
Thomas
If building from source, workaround with:
sed -i "s/echo/#echo/" src/egrep.sh
before configure.
If not use:
sed -i "s/echo/#echo/" /usr/bin/[ef]grep
-- Bruce Dubbs
linuxfromscratch.org
29 matches
Mail list logo
