189257 2007-08-17 17:05 0000 revdep-rebuild silently fails if GREP_OPTIONS is set 2008-02-21 01:52:05 0000 1 1 1 Unclassified Portage Development Tools unspecified All Linux RESOLVED FIXED InSVN P2 minor --- 170220 1 matteo.sasso@gmail.com tools-portage@gentoo.org david.bonnafous@math.ups-tlse.fr matteo.sasso@gmail.com 2007-08-17 17:05:16 0000 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. matteo.sasso@gmail.com 2007-08-17 17:11:04 0000 Created an attachment (id=128415) Proposed patch arfrever@gentoo.org 2007-08-17 21:51:18 0000 Maybe: unset GREP_OPTIONS matteo.sasso@gmail.com 2007-08-17 22:18:20 0000 Yep, that's cleaner. matteo.sasso@gmail.com 2007-08-18 14:16:05 0000 Created an attachment (id=128481) Proposed patch v2 Cleaner line by Arfrever. michael@smith-li.com 2007-08-23 19:55:01 0000 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. matteo.sasso@gmail.com 2007-08-23 23:59:29 0000 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. michael@smith-li.com 2008-01-22 22:24:19 0000 Created an attachment (id=141615) 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. fuzzyray@gentoo.org 2008-02-18 18:09:58 0000 $ svn commit -m "unset GREP_OPTIONS to prevent problems with grep. (Bug 189257)" Sending revdep-rebuild/revdep-rebuild Transmitting file data . Committed revision 464. fuzzyray@gentoo.org 2008-02-21 01:52:05 0000 Released in gentoolkit-0.2.4_rc2 128415 2007-08-17 17:11 0000 Proposed patch revdep-rebuild.patch text/plain LS0tIC91c3IvYmluL3JldmRlcC1yZWJ1aWxkCTIwMDctMDQtMDQgMTQ6NDA6MjMuMDAwMDAwMDAw ICswMjAwCisrKyAvdXNyL2xvY2FsL2Jpbi9yZXZkZXAtcmVidWlsZAkyMDA3LTA4LTE3IDE4OjUw OjExLjAwMDAwMDAwMCArMDIwMApAQCAtNTQsNiArNTQsOSBAQAogCiBlY2hvICJDb25maWd1cmlu ZyBzZWFyY2ggZW52aXJvbm1lbnQgZm9yIHJldmRlcC1yZWJ1aWxkIgogCisjIENsZWFyIEdSRVBf T1BUSU9OUworZXhwb3J0IEdSRVBfT1BUSU9OUz0iIgorCiAjIE9iZXkgUE9SVEFHRV9OSUNFTkVT UwogUE9SVEFHRV9OSUNFTkVTUz0kKHBvcnRhZ2VxIGVudnZhciBQT1JUQUdFX05JQ0VORVNTKQog aWYgWyAhIC16ICIkUE9SVEFHRV9OSUNFTkVTUyIgXQo= 128481 2007-08-18 14:16 0000 Proposed patch v2 revdep-rebuild.patch text/plain LS0tIC91c3IvYmluL3JldmRlcC1yZWJ1aWxkCTIwMDctMDQtMDQgMTQ6NDA6MjMuMDAwMDAwMDAw ICswMjAwCisrKyAvdXNyL2xvY2FsL2Jpbi9yZXZkZXAtcmVidWlsZAkyMDA3LTA4LTE3IDE4OjUw OjExLjAwMDAwMDAwMCArMDIwMApAQCAtNTQsNiArNTQsOSBAQAogCiBlY2hvICJDb25maWd1cmlu ZyBzZWFyY2ggZW52aXJvbm1lbnQgZm9yIHJldmRlcC1yZWJ1aWxkIgogCisjIENsZWFyIEdSRVBf T1BUSU9OUwordW5zZXQgR1JFUF9PUFRJT05TCisKICMgT2JleSBQT1JUQUdFX05JQ0VORVNTCiBQ T1JUQUdFX05JQ0VORVNTPSQocG9ydGFnZXEgZW52dmFyIFBPUlRBR0VfTklDRU5FU1MpCiBpZiBb ICEgLXogIiRQT1JUQUdFX05JQ0VORVNTIiBdCg== 141615 2008-01-22 22:24 0000 revdep-rebuild_r453_unset_GREP_OPTIONS.patch revdep-rebuild_r453_unset_GREP_OPTIONS.patch text/plain LS0tIHJldmRlcC1yZWJ1aWxkX3I0NTMJMjAwOC0wMS0yMSAxNDozMDoxOS4wMDAwMDAwMDAgLTA1 MDAKKysrIHJldmRlcC1yZWJ1aWxkCTIwMDgtMDEtMjIgMTc6MjE6NDguMDAwMDAwMDAwIC0wNTAw CkBAIC0xMyw2ICsxMyw5IEBACiAjIwogIyBHbG9iYWwgVmFyaWFibGVzOgogCisjIE11c3QtYmUt YmxhbmsgdmFyaWFibGVzOgordW5zZXQgR1JFUF9PUFRJT05TCisKICMgUmVhZG9ubHkgdmFyaWFi bGVzOgogZGVjbGFyZSAtciBBUFBfTkFNRT0iJHswIyMqL30iICMgVGhlIG5hbWUgb2YgdGhpcyBh cHBsaWNhdGlvbgogZGVjbGFyZSAtciBPSUZTPSIkSUZTIiAgICAgICAgICMgU2F2ZSB0aGUgSUZT Cg==