[Top][All Lists]

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

[debbugs-tracker] bug#17494: closed (grep bug report: "GREP_OPTIONS" all

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#17494: closed (grep bug report: "GREP_OPTIONS" allows a user to break shell script)
Date: Fri, 12 Sep 2014 16:07:02 +0000

Your message dated Fri, 12 Sep 2014 09:05:51 -0700
with message-id <address@hidden>
and subject line Re: bug#17494: "GREP_OPTIONS" allows a user to break shell 
has caused the debbugs.gnu.org bug report #17494,
regarding grep bug report: "GREP_OPTIONS" allows a user to break shell script
to be marked as done.

(If you believe you have received this mail in error, please contact

17494: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17494
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: grep bug report: "GREP_OPTIONS" allows a user to break shell script Date: Thu, 15 May 2014 01:01:24 +0300

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.


Nadav Har'El

--- End Message ---
--- Begin Message --- Subject: Re: bug#17494: "GREP_OPTIONS" allows a user to break shell script Date: Fri, 12 Sep 2014 09:05:51 -0700 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
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.

--- End Message ---

reply via email to

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