Bugzilla Bug 189257

Using environment variables to personalize the output of common utilities, like
grep and du, often breaks clueless scripts.

My GREP_OPTIONS is set to "--color=auto --directories=recurse -E" and this
causes problems with revdep-rebuild: it correctly finds many broken binaries
(and their packages) but it later quits, saying there's nothing to do (e.g.
"There are no dynamic links to libexpat.so.0... All done.").

I'm posting a trivial patch that fixes the problem.

Created an attachment (id=128415) [details]
Proposed patch

Maybe:
unset GREP_OPTIONS

Yep, that's cleaner.

Created an attachment (id=128481) [details]
Proposed patch v2

Cleaner line by Arfrever.

I don't think this is a valid fix. If users want to break revdep-rebuild by
setting unusual environment variables, there's nothing we can do to stop it. We
could start wrapping coreutils like this:
grep() { /bin/env - /bin/grep "$@"; }, but even after we do that for every
tool, someone will find another way to break it. GREP_OPTIONS isn't the only
environment variable that can be set to affect GNU utilities.

In my opinion it would just be a good idea to have a sane environment before
running bash scripts.

Hi Michael,
I wanted to point out that this fix wasn't made to prevent users from breaking
scripts. After all, if they really want to, they can modify the scripts
themselves and see what happens. So this is not about "security" or "perfect
robustness".

My fix just tries to avoid some frustration for those few users that actually
read manpages and discover that some well documented environment variables can
be used to modify default behavior for some commands. I really don't know how
unusual this is, but I think you will agree that this is not completely
unreasonable. Some users don't understand the subtleties of shell programming
and would probably expect scripts to work anyway (maybe protecting themselves
somehow). And the problem is: 90% of them will! (They either don't use grep or
they use it in a way that doesn't involve those specific GREP_OPTIONS). For
this reason, problems could arise a long time after a user made this
modification to the environment (and has probably forgotten about it).
Yes, expert users will expect some breakage and be on guard. Unfortunately, not
everybody is an expert.

What this fix tries to accomplish is to save developers' time (i.e. people that
think revdep-rebuild doesn't work anymore and file bug reports) and/or some
headache of said users. I think it does its job.

I agree with you on the fact that it is not a complete fix: there are many
tools that rely on environment variables and make other assuptions. Your
solutions would solve the general case in an elegant way. Another solution
would be to use "env" to give a clean environment to the shell process that
runs the script. Unfortunately that requires to identify all variables that are
actually useful for the script (e.g. PATH) and a lot of testing.

Of the many solutions that could solve the general problem, none of them is
probably worth the effort. My solution is trivial (doesn't break anything) and
catches a common case. After all, grep is probably one of the most used
utilities, especially as far as scripts are concerned.

It's useful for me and maybe will be for someone else too.

Created an attachment (id=141615) [details]
revdep-rebuild_r453_unset_GREP_OPTIONS.patch

Patch against r453 in SVN -- I've registered my reservations against patching
every esoteric GNU extension. Clearing the entire environment isn't an option
either.

$ svn commit -m "unset GREP_OPTIONS to prevent problems with grep. (Bug
189257)"
Sending        revdep-rebuild/revdep-rebuild
Transmitting file data .
Committed revision 464.

Released in gentoolkit-0.2.4_rc2