Subject: bug#17494: closed (Re: bug#17494: "GREP_OPTIONS" allows a user to break shell script)

From: [email-masked] (GNU bug Tracking System)
Date: Fri, 12 Sep 2014 16:07:02 +0000

Your bug report

#17494: grep bug report: "GREP_OPTIONS" allows a user to break shell script

which was filed against the grep package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
17494: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17494
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#17494: "GREP_OPTIONS" allows a user to break shell script
From: Paul Eggert <[email-masked]>
To: Jim Meyering <[email-masked]>
Cc: [email-masked], Nadav Har'El <[email-masked]>
Date: Fri, 12 Sep 2014 09:05:51 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

Jim Meyering wrote:

> That looks fine. Long overdue. Thank you for writing it.

You're welcome, and I applied it and am marking this as done.  Other GNU 
utilities probably need similar changes at some point.

Subject: grep bug report: "GREP_OPTIONS" allows a user to break shell script
From: "Nadav Har'El" <[email-masked]>
To: [email-masked]
Cc: Osv Dev <[email-masked]>
Date: Thu, 15 May 2014 01:01:24 +0300
List-Id: <debbugs-submit.debbugs.gnu.org>

Hi,

An unsuspecting user who reads the grep(1) manual page and discovers
the GREP_OPTIONS environment variable, might thing it is a cool idea to
set it. For example, set GREP_OPTIONS=-n to always get numbers on the
output, great isn't it?

Well, it's actually a really bad idea to export GREP_OPTIONS=-n, or anything
similar, because this will effect not only the user's interactive work in
his shell,
but also likely break any shell-script, makefile, and so on, which happens
to
use "grep" and assume that it behaves normally. Imagine what kind a mess
a user could cause by setting GREP_OPTIONS=-v :-)

Instead of setting GREP_OPTIONS hoping it will only effect his interactive
session, what the user should have done is to use an *alias*, e.g.,

    alias grep='grep -n'

In fact on my Fedora installation, there is already a similar alias by
default:

    alias grep='grep --color=auto'

These aliases (when put in .bashrc or similar) are safe - they only effect
the user's interactive shell, and *not* shell scripts or makefiles, which
use the normal grep as they expect.

So I think it would be best if you drop the GREP_OPTIONS feature
completely. Or if for some reason you really don't want to drop it,
please at least explain in the manual page why it is dangerous
and aliases should be preferred.

An example of the kind of damage the availability of this option can do
is that today, a user of an open-source project I'm working on (OSv),
asked us to replace every use of "grep" in our makefile to calls to
"GREP_OPTIONS= grep", so that grep will continue to work normally
even for people who set GREP_OPTIONS.

A final remark: Other command-line utilities, such as "ls", "rm", "cat"
and so on, also don't have a .._OPTIONS variable of the sort grep has.
Imagine what kind of havoc users could cause to shell scripts if they
could do RM_OPTIONS=-i. Instead, what users have been doing for
many years is to alias ls, rm, and so on. They can change "rm" to "rm -i"
for themselves, but it won't mess with non-interactive shell-scripts.
There is no reason, I think, why grep needs to be any different.

Thanks,
Nadav.

-- 
Nadav Har'El
[email-masked]