grep - Patches: patch #7147, Recursive should default to...
You are not allowed to post comments on this tracker with your current authentication level.
patch #7147: Recursive should default to current dir instead of stdin
Submitter: | Egmont Koblinger <egmont> | ||
Submitted: | Wed 31 Mar 2010 08:52:07 AM UTC | ||
Category: | None | Priority: | 5 - Normal |
Status: | Wont Do | Privacy: | Public |
Assigned to: | None | Open/Closed: | Closed |
Fri 16 Apr 2010 02:10:54 PM UTC, comment #2: |
Egmont Koblinger <egmont> |
Wed 31 Mar 2010 09:07:06 AM UTC, comment #1: In principle it's possible that someone has GREP_OPTIONS=-r so the proposed change would break too many scripts.
|
Paolo Bonzini <bonzini> |
Wed 31 Mar 2010 08:52:07 AM UTC, original submission:
If no file is specified, grep defaults to reading the standard input, even if recursion is enabled. Recursively grepping the stdin doesn't make any sense to me, it would be much more reasonable to default to the current directory.
|
Egmont Koblinger <egmont> |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 3 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2010-03-31 | bonzini | Status | None | Wont Do | |
Open/Closed | Open | Closed | |||
2010-03-31 | egmont | Attached File | - | Added grep-2.6.2-default-is-current-dir-if-recursive.patch, #20072 |
Powered by Savane 3.13-d3ae.
Corresponding source code
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.