After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 332673 - support wildcard query: search on foo should also match barfoobar
support wildcard query: search on foo should also match barfoobar
Status: RESOLVED FIXED
Product: beagle
Classification: Other
Component: General
0.2.1
Other Linux
: Normal normal
: ---
Assigned To: Beagle Bugs
Beagle Bugs
: 340089 347243 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-02-26 21:14 UTC by Luis Villa
Modified: 2006-08-16 19:21 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Luis Villa 2006-02-26 21:14:58 UTC
Nautilus search not built against beagle (presumably just find -name \*foo\*) finds jonathanzittrain.jpg when I search for 'zittrain'. Beagle does not, and should.
Comment 1 Debajyoti Bera 2006-02-26 22:23:05 UTC
beagle doesnt support wildcard query (*foo*) currently. Its underlying lucene however does. Not sure why beagle doesnt support wildcard query. Changing summary to reflect reason.
Comment 2 ron 2006-03-06 14:48:15 UTC
Apparently voting is not enabled in this bugzilla setup, but I wish to second the opinion that wildcard searches would be a very welcome feature.

As an example I have been looking like crazy for a Gaim log in which I know that a  certain e-mail address was mentioned, but as I was only searching for the username part (only look for user iso user@example.com) Beagle did not come up with an answer although the file was indexed
Comment 3 Debajyoti Bera 2006-06-07 18:49:20 UTC
*** Bug 340089 has been marked as a duplicate of this bug. ***
Comment 4 Debajyoti Bera 2006-07-11 20:40:16 UTC
*** Bug 347243 has been marked as a duplicate of this bug. ***
Comment 5 Debajyoti Bera 2006-07-11 20:40:41 UTC
From #347243,

Beagle search ability is great. But the lack of search based on partial
filename seems to be a serious deficiency to me.

I tried Beagle on and off for few months now, and I always have to go back to
use "locate" 90% of the time. In statistical terms, I would say locate is not
specific, but it is very sensitive. Which means yes there is plenty of wrong
answers but it - almost - always contain the rigth one.

I think it is more important to be sensitive than specific for Beagle to gain
momentum.

Search about content is a great evolution of search tool but filename will
still remain the more likely element the user will remember - at least
partially.

----
Example :
I have a file named : myapplication.pdf

query with "application" or "myapp" should return a hit even if the word
"application" or "myapp" are not in the document.
Comment 6 Brian 2006-07-13 15:07:15 UTC
Beagle is a nice application, but this really needs to be fixed.
Comment 7 owen-bugs 2006-07-13 15:21:30 UTC
I agree with Debajyoti above, I use locate instead of beagle for file searches because it more reliably returns the file I'm looking for.  It should not be necessary to specify wildcards.
Comment 8 Brian 2006-07-13 15:27:06 UTC
There is no reason to use two applications when beagle could easily satisfy both requirements.
Comment 9 Joe Shaw 2006-08-09 20:42:01 UTC
I've just added support for wildcards to CVS.  For a file named "foobarbaz.txt", you'll need to type in "foobar*" for it to match.
Comment 10 Christophe Jouny 2006-08-09 21:47:06 UTC
Thanks. This is a nice addition.

To be thorough would "*foobar*" be an allowed search term ? so my example in #5 would be cover too.



Comment 11 Max Wiehle 2006-08-12 00:09:21 UTC
Looks like foo*.txt is also not supported yet - at least it does not work for me. That's something people are very used to from the shell. So i think it's important to get it working, too.

Reopening so we don't forget about it.
Comment 12 André Klapper 2006-08-12 13:23:11 UTC
reopening as per last comment.
Comment 13 Max Wiehle 2006-08-12 14:19:06 UTC
Checked again and it looks like it was the properties vs. content issue. Meta*ta will not return Metadata.cs but Meta* and Meta*ta* will just as it should be.

Sorry folks...
Comment 14 Joe Shaw 2006-08-16 19:21:51 UTC
Fixed now in CVS.