bug-grep
[Top][All Lists]
Advanced

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

Re: [PATCH] grep: -r with no args now searches "."


From: Paolo Bonzini
Subject: Re: [PATCH] grep: -r with no args now searches "."
Date: Wed, 04 Jan 2012 10:51:47 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0

On 01/04/2012 12:00 AM, Paul Eggert wrote:
We should first warn about this, and then change it after a year or so.

I'm not sure that'd be helpful.  Ordinary users won't see the warning.
Had we followed this procedure when making our recent incompatible change to
the behavior for "grep '[:space:]'", I expect that the year or so's delay
would not have helped appreciably.

Indeed I changed my mind on "grep '[:space"]'". It's good to warn about it. But the difference here is that GREP_OPTIONS=-r, no matter how debatable it is, is not an unintentional mistake. Mistyping character classes is.

>  In addition, it seems to me that while this behavior would be fine for -r/-R,
>  keeping a default of stdin would be better for --directories=recurse,
>  which is currently a synonym.
Another possibility might be to enable the new behavior only for -R,
and to have a new option --directories=recurse-dot that corresponds
to -R.

That's an interesting alternative. It has some appeal, except that I would not tie it to a new --directories= keyword. That is, I would do something like:

       case 'R':
+        default_to_dot = true;
       case 'r':
         directories = RECURSE_DIRECTORIES;
         break;

The main disadvantages are:

1) typing "-R" is slower than "-r" (due to the shift key), possibly even slower than typing "-r .".

2) there wouldn't be a long option matching -R. I don't think this is a large problem, since this is just a shortcut and people using long options can tolerate typing the extra space-dot pair.

I must add that I rarely use "-r" nowadays, since most of my programming is done in a git or git-svn repository, and "git grep" provides the same functionality as "grep -r <FOO> .". Not having to specify the path wouldn't change that very much.

I'm still leaning towards reverting your patch, but it's good to discuss alternatives.

Paolo



reply via email to

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