GNU bug report logs -
#31705
five grep / egrep issues
Previous Next
Full log
Message #8 received at 31705 <at> debbugs.gnu.org (full text, mbox):
Phillip Feldman wrote:
> I would like to report the following unrelated issues:
>
> (1) `grep --help` and `egrep --help` should report the version number.
'grep --version' should do what you want. That behavior is specified in the GNU
coding standards.
> (2) `egrep [abc]+ *.txt` works as expected, but if I try to do `egrep
> ^[abc]+ *.txt`, which anchors the pattern to the start of the line, I get
> no results,
> even though there are lines that match the pattern.
The command works for me. For example:
$ echo 'apple' | egrep ^[abc]+
apple
If it doesn't work for you, please supply a complete self-contained test case.
> (3) Specifying a pattern for FILE seems to work just fine unless one does a
> recursive search.
Sorry, I don't understand the problem here. Can you supply a complete,
self-contained test case?
> (4) If one attempts to do a recursive search and omits the starting
> directory, it would be helpful if the default were the current working
> directory.
grep does that; at least grep 3.1 does. Perhaps you have an older version; if
so, please upgrade. For example:
$ mkdir d
$ echo x >d/x
$ cd d
$ grep -r x
x:x
> (5) If one provides an invalid regex, e.g., something like '*xyz' (a regex
> can't begin with '*'), one should get a fatal error (grep and egrep accept
> such a
> regex without complaint, and simply return no results).
The longstanding (i.e., since the late 1970s) tradition here is to treat those
strings as valid regular expressions, e.g., '*' at the start of a regular
expression is treated as if it were '\*'. Many users expect this behavior now,
so we're unlikely to change it. POSIX allows this behavior as an extension.
This bug report was last modified 5 years and 139 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.