grep: diagnose and exit-2 for bogus REs like [:space:], [:digit:], etc.

When I make a mistake like this:
  grep '[:lower:]' ...
be it in a script or on the command line, I want to know about
it as soon as possible.  I don't want grep to print a mere warning
that it is interpreting this suspicious and almost guaranteed-wrong
regular expression as a set of just 6 bytes.  And I certainly don't
want grep to silently do the wrong thing, even if that would be
officially standards-conforming.  It's obvious that I intended
[[:lower:]], and I want my error to be diagnosed in a way that is
most likely to get my attention.  Thus, with this change, grep now
prints a diagnostic and exits with status 2 the moment it
encounters an offending [:char_class:] construct.

This changes the way grep works by default, rather than
putting this new behavior on an option.  A new option
would seldom be used in scripts (not portable), and would
probably be used only rarely by those who need it the most.
This new functionality provides a valuable safety measure
and incurs truly negligible risk.

For strict POSIX compliance, set POSIXLY_CORRECT in
your environment.  That disables this new feature.

Revert the changes from commit 2cd3bcea, "grep: add
--warnings={always,never,auto}.", and then do the following:

* src/dfasearch.c (dfawarn): Call getenv("POSIXLY_CORRECT") here;
Remove "warning: " from the diagnostic, now that it's more than
a warning, and exit with status 2.
* NEWS (New features): Describe the new semantics.
* tests/warn-char-classes: Adjust one test to accommodate this change.
* doc/grep.texi (Character Classes and Bracket Expressions): Document.
(Environment Variables): Cross-reference it.
Remove reference to obsolete getopt illegal vs. invalid difference.
Thanks to Paul Eggert for suggestions and an initial prod.

1 files changed, 9 insertions, 6 deletions

diff --git a/doc/grep.texi b/doc/grep.texi
index 890ba1b2..da103c49 100644
--- a/doc/grep.texi
+++ b/doc/grep.texi
@@ -935,12 +935,8 @@ follow file names must be treated as file names;
 by default,
 such options are permuted to the front of the operand list
 and are treated as options.
-Also,
-@sc{posix.2} requires that unrecognized options be diagnosed as ``illegal'',
-but since they are not really against the law the default
-is to diagnose them as ``invalid''.
-@code{POSIXLY_CORRECT} also disables @code{_@var{N}_GNU_nonoption_argv_flags_},
-described below.
+Also, @code{POSIXLY_CORRECT} disables special handling of an
+invalid bracket expression.  @xref{invalid-bracket-expr}.
 
 @item _@var{N}_GNU_nonoption_argv_flags_
 @vindex _@var{N}_GNU_nonoption_argv_flags_ @r{environment variable}
@@ -1269,6 +1265,13 @@ encoding, whereas the former is independent of locale and character set.
 part of the symbolic names, and must be included in addition to
 the brackets delimiting the bracket expression.)
 
+@anchor{invalid-bracket-expr}
+If you mistakenly omit the outer brackets, and search for say, @samp{[:upper:]},
+GNU @command{grep} prints a diagnostic and exits with status 2, on
+the assumption that you did not intend to search for the nominally
+equivalent regular expression: @samp{[:epru]}.
+Set the @code{POSIXLY_CORRECT} environment variable to disable this feature.
+
 Most meta-characters lose their special meaning inside bracket expressions.
 
 @table @samp