Re: new snapshot tomorrow. anything pending?

[Jim Meyering]

On Tue, Nov 3, 2020 at 11:11 AM Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 11/2/20 12:33 PM, Jim Meyering wrote:
> > Maybe add some perspective like this to the commit log?
> > "Since Nov 2014's grep-2.21, any attempt to make grep use GREP_OPTIONS
> > has caused it to fail, saying that that envvar is no longer
> > supported".
>
> Sure, except grep didn't fail, it just issued a warning on stderr. I installed
> this NEWS item instead:
>
>    The GREP_OPTIONS environment variable no longer affects grep's behavior.
>    The variable was declared obsolescent in grep 2.21 (2014), and since
>    then any use had caused grep to issue a diagnostic.

Thanks for correcting. I tested too hastily and misinterpreted.

Thus, this change will break any code that requires grep honor
GREP_OPTIONS (presumably because stderr is suppressed or missed).

Not used to causing potential breakage via a new release. Am I being
too cautious? At first, I wondered: is there some noisier way to
signal the deletion? And the answer seems to be "No". It's already
undesirable that we allow this envvar to influence behavior and cause
grep to write that diagnostic to stderr. Don't want to try to write to
a tty. We cannot let the setting of this envvar cause all grep
invocations to fail. I guess we could retain the stderr diagnostic and
stop parsing the envvar value, but that doesn't seem worthwhile.

Options:
1. make this potentially-breaking change in a release all by itself,
separate from bug fixes
2. delay even more
3. go ahead as-is.

I'm leaning towards 3 and expect to make a snapshot including this
change later today.