Hello, Thomas!
On Thu, 31 Aug 2000, Thomas Dickey wrote:
On Thu, Aug 31, 2000 at 03:50:48PM -0400, Pavel Roskin wrote:
4) Somebody has already been confused by an unquoted plus while having
problems with ncurses headers.
...but we never did find the root cause -- but found some
Hello, Mathieu!
I have tried the same code with egcs-2.91.66 and the errors (GCC_* and
families missing) are not reported. So the problem come from gcc. gcc -v
reports: 2.96 2724 (experimental). Oops, I didn't see the experimental
thing... The difference is in the -Wundef flag given to
Hello, Alexandre!
`+' isn't a portable literal. Some implementations seem to use it as
a meta-character with the usual meaning, but without support for it
after `*'.
Alexandre, could you be more exact?
No. I seem to recall some comments about non-portability of `+', and
certainly
Date: Thu, 31 Aug 2000 14:41:48 -0400 (EDT)
From: Pavel Roskin [EMAIL PROTECTED]
If Paul said it's
ok to assume `+' is not a meta-character in `grep', I believe it.
You shouldn't believe it. The answer is Plan 9.
OK, but Plan 9 grep is not the same as traditional grep at all.
Date: Thu, 31 Aug 2000 14:41:48 -0400 (EDT)
From: Pavel Roskin [EMAIL PROTECTED]
If Paul said it's
ok to assume `+' is not a meta-character in `grep', I believe it.
You shouldn't believe it. The answer is Plan 9.
OK, that's news to me. But you should be careful: Plan 9 grep
If Paul said it's
ok to assume `+' is not a meta-character in `grep', I believe it.
You shouldn't believe it. The answer is Plan 9.
OK, but Plan 9 grep is not the same as traditional grep at all. It
uses a syntax that is almost an extension of POSIX egrep (i.e. it uses
EREs,
On Thu, Aug 31, 2000 at 03:50:48PM -0400, Pavel Roskin wrote:
4) Somebody has already been confused by an unquoted plus while having
problems with ncurses headers.
...but we never did find the root cause -- but found some suggested workarounds
that only lead into further discussion.
--
On Thu, Aug 31, 2000 at 12:19:56PM -0700, Paul Eggert wrote:
OK, but Plan 9 grep is not the same as traditional grep at all. It
uses a syntax that is almost an extension of POSIX egrep (i.e. it uses
EREs, not BREs). Unfortunately it's not a pure extension: the bracket
expression syntax is
On Wed, 30 Aug 2000, Mathieu Chouquet-Stringer wrote:
/usr/include/curses.h:360:9: warning: "GCC_PRINTF" is not defined
/usr/include/curses.h:366:9: warning: "GCC_SCANF" is not defined
thing... The difference is in the -Wundef flag given to the preprocessor
(gcc -E). Without it, the results
On Aug 29, 2000, Pavel Roskin [EMAIL PROTECTED] wrote:
`+' isn't a portable literal. Some implementations seem to use it as
a meta-character with the usual meaning, but without support for it
after `*'.
Alexandre, could you be more exact?
No. I seem to recall some comments about
On Tue, 29 Aug 2000, Earnie Boyd wrote:
But is egrep portable? Is the grep in question here GNU grep? AFAIK '^ *+' is
a regular expression and not an extended regular expression.
that's my impression (from reading the description yesterday).
--
T.E.Dickey [EMAIL PROTECTED]
On Aug 29, 2000, Earnie Boyd [EMAIL PROTECTED] wrote:
AFAIK '^ *+' is a regular expression and not an extended regular
expression.
`+' after `*' isn't portable, IIRC. In fact, I don't understand what
we're trying to accomplish with that construct. It makes no sense at
all to me.
--
Hello, Earnie!
On Tue, 29 Aug 2000, Earnie Boyd wrote:
But is egrep portable? Is the grep in question here GNU grep? AFAIK '^ *+' is
a regular expression and not an extended regular expression.
egrep is portable. It is used by autoconf several times without checking
its existance.
I tried
On Aug 29, 2000, "Thomas E. Dickey" [EMAIL PROTECTED] wrote:
On 29 Aug 2000, Alexandre Oliva wrote:
On Aug 29, 2000, Earnie Boyd [EMAIL PROTECTED] wrote:
AFAIK '^ *+' is a regular expression and not an extended regular
expression.
`+' after `*' isn't portable, IIRC. In fact, I don't
On Aug 29, 2000, Pavel Roskin [EMAIL PROTECTED] wrote:
# Capture the stderr of cpp. eval is necessary to expand ac_cpp. We
# used to copy stderr to stdout and capture it in a variable, but that
# breaks under sh -x, which writes compile commands starting with ` +'
# to stderr in eval and
Hello!
`+' after `*' isn't portable, IIRC. In fact, I don't understand what
we're trying to accomplish with that construct. It makes no sense at
all to me.
If it's not portable let's use '^ *[+]' to be on the safe side. Both grep
and egrep 2.4.2 interpret is in the way it was intended -
On Aug 29, 2000, Pavel Roskin [EMAIL PROTECTED] wrote:
The only shell I found that outputs pluses to conftest.out (not only to
config.log) is zsh
Isn't it a coincidence that that's the shell Akim uses? :-)
+ * acgeneral.m4 (AC_TRY_CPP): Quote literal plus by square
+ brackets.
Ok
--- Lars Hecking [EMAIL PROTECTED] wrote:
Alexandre Oliva writes:
On Aug 29, 2000, Earnie Boyd [EMAIL PROTECTED] wrote:
AFAIK '^ *+' is a regular expression and not an extended regular
expression.
`+' after `*' isn't portable, IIRC. In fact, I don't understand what
we're
On 29 Aug 2000, Alexandre Oliva wrote:
The `*' is the metacharacter: `+' is literal.
`+' isn't a portable literal. Some implementations seem to use it as
a meta-character with the usual meaning, but without support for it
after `*'.
unless I missed a response, so far all that's been
Hello, Thomas!
`+' isn't a portable literal. Some implementations seem to use it as
a meta-character with the usual meaning, but without support for it
after `*'.
This was about grep, not egrep. GNU grep 2.4.2 (without -E) behaves
correctly, but the point was that some other
Date: Tue, 29 Aug 2000 10:15:13 -0400 (EDT)
From: Pavel Roskin [EMAIL PROTECTED]
grep-2.4.2 is sufficient to reproduce the problem. No need to upgrade libc
- glibc-2.1.1 is fine.
$ grep --version
grep (GNU grep) 2.4.2
[Copyright etc skipped]
$ echo foo infile
$ grep
Date: Tue, 29 Aug 2000 13:27:10 -0400 (EDT)
From: "Thomas E. Dickey" [EMAIL PROTECTED]
unless I missed a response, so far all that's been demonstrated is that a
newer version of GNU grep doesn't behave the same as other versions of
grep.
I don't even see where that has been
On Tue, 29 Aug 2000, Pavel Roskin wrote:
Hello, Thomas!
`+' isn't a portable literal. Some implementations seem to use it as
a meta-character with the usual meaning, but without support for it
after `*'.
This was about grep, not egrep. GNU grep 2.4.2 (without -E) behaves
Hello!
$ grep -vE '^ *+' infile
$
That behavior is correct for GNU grep, but it is an extension to POSIX.2.
POSIX.2 does not specify the behavior for + after * in an extended
regular expression (i.e. the type of regular expression used by grep
-E). So a portable script should
Date: Tue, 29 Aug 2000 14:20:12 -0400 (EDT)
From: Pavel Roskin [EMAIL PROTECTED]
I haven't checked the older versions, but this behaviour of GNU grep is
weird (it may or may not be a bug, dependent on the standard):
$ echo foo |./grep -E ' *+'
foo
It is not a bug. GNU grep
On Tue, Aug 29, 2000 at 03:28:06PM -0700, Paul Eggert wrote:
Date: Tue, 29 Aug 2000 14:20:12 -0400 (EDT)
From: Pavel Roskin [EMAIL PROTECTED]
I haven't checked the older versions, but this behaviour of GNU grep is
weird (it may or may not be a bug, dependent on the standard):
Date: Tue, 29 Aug 2000 19:07:03 -0400
From: Thomas Dickey [EMAIL PROTECTED]
It is not a bug. GNU grep extends the semantics of regular
expressions so that 'x*+' is equivalent to '(x*)+'. POSIX does not
I wouldn't call it an extension, since it breaks some existing scripts
Here is a bug report about Autoconf. I have checked 2.13 and the
2.49a, but both have the same problem. I don't know which should be
blamed, grep or autoconf, though.
Okuji
Ok, I have found the guilty program. My problem was to be able to
compile grub with gcc 2.96 and the glibc 2.9.
28 matches
Mail list logo
