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 -v '^ *+' infile
foo
That is the correct behavior, since "foo" does not match "^ *+".
"+" is not a metacharacter in plain grep, and never has been.
$ 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 never do this.
1) What '^ *+' is supposed to filter out?
"grep -v '^ *+' is supposed to output a copy of its input, other than
lines starting with a "+" that is possibly preceded by spaces.
This command is needed in case someone invokes "sh -x configure".
On many hosts, "sh -x configure" causes the variable to contain
a copy of the executed command, preceded by "+" or " +".
2) Can it be rewritten is a more portable form?
It should be portable as-is. I've never seen a grep where it didn't
work. I suspect that the problem lies elsewhere.
From: Alexandre Oliva <[EMAIL PROTECTED]>
Date: 29 Aug 2000 11:50:08 -0300
`+' 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 `*'.
`+' is not portable for egrep or grep -E, but it is portable for plain
grep. Yes, it shouldn't hurt to replace `+' with `[+]', but I suspect
that would mask the real problem. Let's figure out what the real
problem is and fix that instead.
