Running grep 2.20 on Debian Jessie.
Apparently grep is not processing the GREP_OPTIONS
environment variable. I have been setting the "-i" option in
there for years as that is the most useful for me. Lately it
has not been working. I have done many tests and it seems
that GREP_OPTIONS is completely
For a long time I have used GREP_OPTIONS to set the
--ignore-case option. Suddenly it seems to be ignoring it.
I am running Debian Jessie and grep 2.20
> Dennis Clarke wrote:
> > On Solaris 10 update 10 on Sparc with Sun Studio 12 tools.
> >
> > $ env | sort
> > AS=/usr/ccs/bin/as
> > CC=/opt/SUNWspro/bin/cc
> > CFLAGS=-erroff -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xc
> -xcode=pic32 -xregs=
.node002
TERM=vt100
TZ=GMT0
USER=dclarke
VISUAL=/usr/xpg4/bin/vi
WINDOW=3
_=/usr/xpg4/bin/env
$
See attached testsuite log file.
Dennis
ps: I have filed reports like this before and usually see no reply, activity,
nothing.
grep-2.13_SunOS2.10_sparcv9_test-suite.log.bz2
Description: BZip2
> On 11/19/2012 08:13 PM, Dennis Clarke wrote:
> > See attached testsuite log file.
>
> The key failure seems to be that the following
> works, when it should fail:
>
> mkdir a
> echo x | grep -f a/
>
> This should exit with status 2, but it exits with
>
errbuf,
size_t errbuf_size)
{
const char *msg;
The compiler here was c99 in Oracle Studio 12.5 on Solaris 10 sparc
with strict C99 compliance mode enforced.
Dennis Clarke
On 08/28/2016 04:45 AM, Paul Eggert wrote:
Dennis Clarke wrote:
lib/regcomp.c will not compile with C99 strict compiler because of
the usage of the non-standard "__restrict".
Thanks for the bug report. What are the diagnostics?
I didn't get to see much other tha
lib/regex.c
So really these can all use the standarc C library function provided and
not use the thing in regexec.c at all.
Hold on a sec here ... are we re-writing the POSIX standard C library
functions for some reason ?
Dennis
On 08/28/2016 04:45 AM, Paul Eggert wrote:
Dennis Clarke wrote:
Coffee number two.
Digging through the Changelog and looking at things like
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16911#24 I see the
problems run deeper. This rabbit hole just goes on and on.
I am happy with the change
so grep supplies a substitute regex matcher on systems
like Solaris that lack the extensions to POSIX that grep needs.
yep .. Solaris systems can be very spec tight and this is why I often
compile things with c99 just to shake loose these little bugs which
would otherwise fly under radar.
Thank you for the quick bug fix.
Dennis
On 08/28/2016 07:58 PM, Paul Eggert wrote:
Dennis Clarke wrote:
On 08/28/2016 03:58 PM, Paul Eggert wrote:
I see the problem ...
Ah, that explains it. 12.4 c99 supports __restrict__ but not __restrict,
Sort of what I said .. I think. For that matter are you sure about the
use of
printf '\351\n' | od -Ax -t x1 -v
000 e9 0a
002
dasoyva_$ LC_ALL=en_US.ISO8859-1 /usr/bin/printf '\351\n'
�
Wonder how I would test this on a strict POSIX system here. Any thoughts?
Dennis
specific complaint which is only of value on a
very specific system and usage case. There is no way that grep could
configure a "good block size" unless it were tailor built. Doesn't
seem to be a reasonable RFE. In my opinion.
Dennis
efile:582: bash] Error 2
real 20.71
user 14.33
sys 4.36
beta$
Nice.
However configure works without bash around.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
However configure works without bash around.
What you tested was bash's configure. The original
query was about grep's configure.
oops
dc
I work on GNU autoconf beta
today :
https://lists.gnu.org/r/autoconf/2020-07/msg6.html
What magic grep does grep want ?
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
y tone certainly could have been better. Sorry. I simply do not see
why this is a problem given that I have the installed XPG4 grep as well
as GNU grep in my path and they are both working fine. I have no idea
why configure seems baffled by this. Very frustrating.
Dennis
UN_PATH=/opt/bw/lib
LD=/usr/ccs/bin/sparcv9/ld
LIBS=-lrt
LIBTOOL_M4=/opt/bw/share/aclocal/libtool.m4
LINES=48
LOGNAME=dclarke
M4=/opt/bw/bin/m4
MAIL=/usr/mail/dclarke
MAKE=/opt/bw/bin/gmake
NM=/usr/xpg4/bin/nm -p
OLDPWD=/opt/bw/build/grep-3.5_sunos5.10_sparcv9.002/gnulib-tests
OPENSSL=/opt/bw/bin/openssl
PAGER=/usr/xpg4/bin/more
PATH=/opt/bw/bin:/opt/bw/sbin:/usr/xpg6/bin:/usr/xpg4/bin:/usr/ccs/bin:/usr/jdk/latest/bin:/opt/developerstudio12.6/bin:/sbin:/bin:/usr/bin:/usr/sbin:/usr/dt/bin:/usr/openwin/bin:/usr/X11/bin:/opt/schily/bin
PCRE_CONFIG=/opt/bw/bin/pcre-config
PERL=/opt/bw/bin/perl
PKG_CONFIG_PATH=/opt/bw/lib/pkgconfig
POSIXLY_CORRECT=1
PWD=/opt/bw/build/grep-3.5_sunos5.10_sparcv9.002
PYTHON=/opt/bw/bin/python3
SED=/opt/bw/bin/sed
SHELL=/opt/bw/bin/bash
SHLVL=0
SSH_CLIENT=99.253.170.241 39901 22
SSH_CONNECTION=99.253.170.241 39901 66.225.151.252 22
SSH_TTY=/dev/pts/1
SSL_CERT_DIR=/opt/bw/ssl/certs
TERMINFO=/usr/share/lib/terminfo
TERM=xterm
TMPDIR=/var/tmp/dclarke
TZ=GMT0
USER=dclarke
_=/usr/xpg4/bin/env
VISUAL=/usr/xpg6/bin/vi
XTERM_LOCALE=en_US.UTF-8
YACC=/opt/bw/bin/yacc
alpha$
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
On 9/28/20 4:46 AM, Paul Eggert wrote:
> On 9/27/20 11:43 PM, Dennis Clarke via Bug reports for GNU grep wrote:
>> FAIL: test-nl_langinfo-mt
>> =
>>
>> FAIL test-nl_langinfo-mt (exit status: 139)
>>
>> FAIL: test-stdalign
>>
rt.h:112: note: macro "static_assert" defined here
112 | #define static_assert(x, y) __CTASSERT(x)
|
Maybe I need some prerequisite somewhere ?
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
On 10/1/23 02:50, Paul Eggert wrote:
On 2023-09-30 20:30, Dennis Clarke via Bug reports for GNU grep wrote:
I was trying to build GNU grep on a NetBSD 9.3 machine when I saw this
nasty bit of business :
I just now built grep 3.11 on NetBSD 9.3 x86-64, and didn't run into any
problems.
On 10/1/23 02:50, Paul Eggert wrote:
On 2023-09-30 20:30, Dennis Clarke via Bug reports for GNU grep wrote:
I was trying to build GNU grep on a NetBSD 9.3 machine when I saw this
nasty bit of business :
I just now built grep 3.11 on NetBSD 9.3 x86-64, and didn't run into any
pro
On 10/4/23 18:30, Paul Eggert wrote:
On 10/4/23 13:09, Dennis Clarke via Bug reports for GNU grep wrote:
/opt/bw/build/grep-3.11_netbsd_9.3_sparcv9.002/src/dfasearch.c:159:
undefined reference to `re_set_syntax'
So, you didn't build the regex library that came with grep ...
l as ISO/IEC 9899 (C Standard) Amendment 1.
Anyways, this is just a crusty old grey beard here putting yet another
layer of paint onto the bikeshed ( https://www.bikeshed.com/ ) and I do
apologize for the messy paintwork.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
[1] the ma
On 3/22/24 17:12, Paul Eggert wrote:
On 3/22/24 12:25, Dennis Clarke via Bug reports for GNU grep wrote:
Old Solaris 8, once fully patched, was definately
compliant with SUSv2 which is all of POSIX.1b-1993, POSIX.1c-1996
POSIX does not specify the behavior of grep when the input is not a text
On 3/22/24 16:42, David G. Pickett via Bug reports for GNU grep wrote:
>
> Most users consider a line at EOF lacking a trailing newline as
> still a line, but perhaps some do not?
>
Good ol "wc" says it is not a line. I would go with what "wc" claims.
--
De
just pass the decompressed
bits along a pipe.
Done.
--
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
ts of the file.
>
> What do people think?
>
> Dale
I think I want to setup an experiment and test this problem.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
le situations *should* return a non-zero error status
that helps silly old UNIX people like me.
If someone needs to write if-then-else-what? clause stuff in code
then that is correct behavior. Why fix that which works fine?
--
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux s
29 matches
Mail list logo
