[Top][All Lists]

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

Re: Using `call-process-shell-command' in `process-lines'

From: Lennart Borgman (gmail)
Subject: Re: Using `call-process-shell-command' in `process-lines'
Date: Mon, 26 Nov 2007 23:16:05 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20071031 Thunderbird/ Mnenhy/

Eli Zaretskii wrote:
Date: Mon, 26 Nov 2007 22:25:43 +0100
From: "Lennart Borgman (gmail)" <address@hidden>
CC: address@hidden, address@hidden, address@hidden

   find -name *l.el
   find -name m*.el
   find -name "*.el"
Sheer luck, the first tow ones.  You _must_ quote the wildcard to get
predictable behavior.

Is anyone able to understand what is going on?
I explained that in another message.
I think there is more to it. I suspect that the find arg parsing code handles a single "*" differently and that this is a bug.

What do you mean by ``find arg parsing code''?  Quoted wildcards are
parsed by the application code called from `find's `main' function,
while unquoted wildcards are parsed by the startup code which runs
before `main'.  These two are different: the former uses GNU `fnmatch'
function (and thus you can use wildcards like "[a-d]*.el"), while the
latter uses a function from Microsoft' runtime, which supports only
the limited Windows semantics of wildcards.

I mean the code that it is called from find's main function. But I am not sure what runs when. Actually the two calls below

   find -name "[ni]*.el"
   find -name [ni]*.el

both works for me when I run them in cmd.exe. So both this seems to be parsed by find's main function. The case that fails is

   find -name *.el

See also above for the two cases that might be "sheer luck".

But all this has no direct relation to the problem at hand.  The
problem at hand is that we pass the "*.el" arg incorrectly to `find',
not what `find' does with it.

reply via email to

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