[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#31705: five grep / egrep issues

From: Paul Eggert
Subject: bug#31705: five grep / egrep issues
Date: Mon, 4 Jun 2018 00:36:48 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

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]+

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

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

(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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]