patchgrep - 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

Submitted by:  Egmont Koblinger <egmont>
Submitted on:  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: 

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.

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.

There is a pending patch for posting a warning in this case.  That would also be disruptive for GREP_OPTIONS=-r, but not as much.

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.

I find myself executing the command "grep -r something ." very very often, usually during development of a large source code tree. I often end up accidentally omitting the trailing dot, and waiting for grep to do something. Even if I don't forget it, it's an unnecessary step to type that space-dot.

Egmont Koblinger <egmont>



Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by bonzini (Posted a comment)
  • -email is unavailable- added by egmont (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-03-31 bonzini StatusNone => Wont Do
        Open/ClosedOpen => Closed
    2010-03-31 egmont Attached File- => Added grep-2.6.2-default-is-current-dir-if-recursive.patch, #20072

    Back to the top

    Powered by Savane 3.5