bug-grep
[Top][All Lists]
Advanced

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

[patch #7147] Recursive should default to current dir instead of stdin


From: Egmont Koblinger
Subject: [patch #7147] Recursive should default to current dir instead of stdin
Date: Fri, 16 Apr 2010 14:10:54 +0000
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100217 Firefox/3.5.8

Follow-up Comment #2, patch #7147 (project grep):

Let me please politely disagree with you.

Unix scripts are not designed to be hermetically sealed. There are dozens of
environment variables that influence the behavior of either the shell itself,
or any of its child commands. Basically nearly every shell script breaks if
executed with weird env vars, no developer is able to test all possible
environments and make their scripts fool proof.

Shell scripts containing a grep command can already break by adding -F, -G,
-i, --color=always or anything like this to GREP_OPTIONS. The only thing
scripts can do against this is to unset GREP_OPTIONS if they really want to be
fool proof - but in practice, they just simply assume you didn't mess up with
your env variables in insane ways.

You may or may not like that the behavior of shell scripts can be altered
(often: broken) by setting weird env vars. If you don't like it, GREP_OPTIONS
shouldn't exist at all. If you accept that simply this is the way many Unix
utilities are designed, I think it's perfectly reasonable to say: it's the
user's responsibility not to set weird defaults that'd break scripts.

Moreover, I don't think there are so many users who have -r in their
GREP_OPTIONS. And even if they have: they had to explicitly put it there, so
they might easily remove it too. It's not that you'd break existing scripts,
it's just that we'd break some existing setups. (Just like when I had to
change from GREP_COLOR to GREP_COLORS a couple of years ago, because grep
changed. Same story, isn't it?)

Grep keeps on slightly changing its behavior, sometimes in incompatible ways
(e.g. certain Unicode corner case or weird regex breaks and then gets fixed in
a later version). I don't think being afraid of breaking something for a very
small user base (who have a questionable setup anyway) is a good reason to
prevent fixing a broken design.

To be more constructive:

If you're about to add a warning anyways, could you phrase the warning so
that it says the default might change in the future? And then maybe in a year
or two we could change the default...

Moreover, once we have that GREP_OPTIONS anyway, maybe a new option
--current-dir-if-recursive-and-no-file-given could be the solution? Of course
setting this variable could also break certain scripts, but at least nothing
would break for those who had set their GREP_OPTIONS a long time ago.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/patch/?7147>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/





reply via email to

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