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
