Subject: Re: bug#19998: GREP_OPTIONS alternative?

From: Christian Kujau <[email-masked]>
Date: Fri, 13 Mar 2015 13:27:55 -0700 (PDT)

On Wed, 11 Mar 2015 at 17:58, Paul Eggert wrote:
> On my Ubuntu 14.10 system, fgrep lives in /bin and is a separate executable
> (actually a shell script), but it invokes 'grep'.  Likewise for Fedora 21,
> where fgrep lives in /usr/bin.  So what you write doesn't necessarily
> contradict what I said.

While it invokes "grep", it does not seem to invoke my $HOME/bin/grep, 
thus it will not honor the grep options set in $HOME/bin/grep.

> On the other hand, now that I've tested it, I see that when I type 'fgrep'
> Bash invokes it as '/bin/fgrep', which surprises me and which defeats the
> purpose of having 'fgrep' look at $0.  I installed the attached patch, which
> should fix that.

I hope that make is clear now why a helper script gets increasingly more 
complex if not complicated than a single environment variable.

>> Why is GREP_OPTIONS random and LESS or ZIPOPT or GZIP are not?
> 
> For starters, none of the other variables are used by standard utilities.

I'd consider gzip, zip, or less pretty "standard". I'd cite more standard 
utilities, but I don't want to put out any more ideas here...

> Admittedly some judgment is needed here.  As LESS is merely a user-interface
> thing it's less worrisome.  I don't know what ZIPOPT is.

>From zip(1):

> The environment variable ZIPOPT can be used to change the default
> options. 

So, pretty much what GREP_OPTIONS is^Wused to be.

> GZIP is worrisome and probably should go -- an attacker can use GZIP to 
> cause 'gzip' to remove /etc/passwd, for example.  So it looks like I 

An "attacker" can set $PATH to /tmp and do stuff too. If an attacker can 
modify a user's environment, all is lost anyway.

> should add removing GZIP to my list of things to do too....

I was afraid you'd say something like this :-\

Christian.
-- 
BOFH excuse #277:

Your Flux Capacitor has gone bad.