Jeff King <peff@xxxxxxxx> writes:
> On Fri, Nov 06, 2009 at 02:00:11AM -0800, Junio C Hamano wrote:
>
>> But I didn't try hard to find out what _else_ we are depending on.
>
> It is not really _us_ depending on it. It is "things the user wants to
> do that _we_ support, but that their grep might not." So I don't think
> there is much point in enumerating features. If their system grep
> doesn't handle options that they want to use, then it won't work for
> them. If they don't use them, then they will be fine.
>
> Though "-e" might be the exception, as I think we might use it
> unconditionally. But something like "-F -i" really depends on whether
> the user wants to use it.
Yes and no.
Even though we currently punt on a few platforms for simplicity and build
with NO_EXTERNAL_GREP, we could check if the set of options given are
within the feature set of what the platform's grep understands and choose
to spawn "grep" unless some options that are unsupported are used, in
which case we fall back to the internal one.
We could certainly do something like this if it turns out to be a problem.
An invocation that does not use -F and -i together can still spawn
external grep if that is faster.
You are correct about "-e". Our NO_EXTERNAL_GREP on SunOS cannot be
avoided.
builtin-grep.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index 1df25b0..2905f64 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -357,6 +357,9 @@ static int external_grep(struct grep_opt *opt, const char **paths, int cached)
if (opt->extended || (opt->relative && opt->prefix_length))
return -1;
+ if (NO_GREP_FIXED_IGNORE_CASE &&
+ opt->fixed && (opt->regflags & REG_ICASE))
+ return -1;
len = nr = 0;
push_arg("grep");
if (opt->fixed)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html