[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: [Controversial Patch for Bug 18180] kfind sloppy match for simple search strings
From:       Klas Kalass <klas.kalass () gmx ! de>
Date:       2002-07-19 21:40:53
[Download RAW message or body]

Am Saturday 20 July 2002 00:41 schrieb Martin Konold:
> On Friday 19 July 2002 06:24 pm, Kurt Granroth wrote:
> > On Friday 19 July 2002 03:47 am, konold@mail.kde.org wrote:
> > > On Fri, Jul 19, 2002 at 12:36:05PM +0200, Klas Kalass wrote:
> > > > > > k?ind -> kfind.cpp is NOT FOUND
> > > > > > k?ind* -> kfind.cpp is FOUND
> > > >
> > > > I am not quite sure I understand: The syntax *is* command line
> > > > wildcards plus the special case that no wildcards specified is
> > > > interpreted as "*<searchstring>*" so that users not knowing about
> > > > wildcards have an easier
> > >
> > > At least the example says that k?find.cpp does not match kfind.cpp but
> > > k?find* does match. This example contradicts your explaination.
> >
> > No, he said that 'k?find' does not match 'kfind.cpp' (which is right).
Actually I said that 'k?ind' does not match 'kfind.cpp' (sorry for the 
nitpicking)

>
> this is fine but he also said (look above!) that k?ind* does match
> 'kfind.cpp' which of course is inconsistent simply because
> anythingnonmatching* should never match.
Why do you think that k?ind* is anythingnonmatching*? We are not talking about 
regular expressions but about shell - style wildcards. The meaning of "?" is 
"any one" character, not "one or none of the previous". So k?ind matches 
kfind wonderfully and kfind* matches kfind.cpp wonderfully. 
But this has nothing to do with my proposed patch because it is the current 
behaviour of bash, kfind and many other tools using wildcards.


Cheers,
Klas
[prev in list] [next in list] [prev in thread] [next in thread]