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 attachment 128415 [details, diff] Proposed patch
Maybe: unset GREP_OPTIONS
Yep, that's cleaner.
Created attachment 128481 [details, diff] 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 attachment 141615 [details, diff] 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
