bug#31705: five grep / egrep issues

[Paul Eggert]

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.