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

[Lennart Borgman (gmail)]

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.