Does anyone else find that 'locate' does all the wrong things for them? It's not that it's incapable of doing what I want but the defaults seem to be set up to be purposely the opposite of what I actually need it to do.
The defaults for 'find' on the other hand are almost exactly what I want to do when searching for files.
When you give 'locate' a name to search for it finds everything with that string of characters in it, this nearly always results in zillions of hits I don't want. However 'find' only finds exact matches unless you specify an RE explicitly. Yes, I know that you can tell 'locate' to find only exact matches but the default is wrong for me.
Secondly 'locate' searches the whole file system, I very rarely want to do this especially as there are incremental backups which produce dozens of near identical hits. With 'find' I can specify (have to specify in fact) the root of the search which again is nearly always exactly what I want to do. In this case it's much more difficult to make 'locate' work the same way as 'find' because you'd have to rebuild the database (I did do that once but my changes got lost in an upgrade I think).
So, is there an alternative out there that works (by default preferably) like 'find' but uses a pre-built database like 'locate' so is reasonably fast?
On 16/05/14 14:57, Chris Green wrote:
Does anyone else find that 'locate' does all the wrong things for them? It's not that it's incapable of doing what I want but the defaults seem to be set up to be purposely the opposite of what I actually need it to do.
Have you tried "whereis"?
The whereis utility checks the standard binary, manual page, and source directories for the specified programs, printing out the paths of any it finds.
See: http://en.wikipedia.org/wiki/Whereis
Also, locate uses a database IIRC, which on my Gentoo systems is maintained nightly (cron) by a tool called updatedb. Consequently it's very fast.
Cheers, Laurie.
On Fri, May 16, 2014 at 03:13:51PM +0100, Laurie Brown wrote:
On 16/05/14 14:57, Chris Green wrote:
Does anyone else find that 'locate' does all the wrong things for them? It's not that it's incapable of doing what I want but the defaults seem to be set up to be purposely the opposite of what I actually need it to do.
Have you tried "whereis"?
The whereis utility checks the standard binary, manual page, and source directories for the specified programs, printing out the paths of any it finds.
Yes, I know about 'whereis', useful sometimes (though 'man -k' is more often what I'm after on that front).
It's no good for finding that letter I wrote last year, or the laserjet 1320 PDF manual I know I saved somewhere (it was trying to find the 1320 manual that brought on this rant!).
Also, locate uses a database IIRC, which on my Gentoo systems is maintained nightly (cron) by a tool called updatedb. Consequently it's very fast.
Exactly! What I want is a 'find' that uses a database like 'locate'. For me 'find' is perfect in what it does and how it allows me to tune the search but it's too slow if one is searching across a big disk.
On 16/05/14 16:19, Chris Green wrote:
Exactly! What I want is a 'find' that uses a database like 'locate'. For me 'find' is perfect in what it does and how it allows me to tune the search but it's too slow if one is searching across a big disk.
Back in the late 1990s when I used to work at Suffolk County Council, we used to run a nightly cronjob which simply did "find / -print > /files.txt". It would then be trivial to do a virtually-instant "grep" for something in this file index, with the understanding that any files added that day would obviously not be included. But then you'd have only just created them, so you'd probably remember, or your application's "open recent" would still have a reference.
You could even write a "locate" wrapper that did both a conventional locate and appended results from a grep in your file index.
KDE also has things like Nepomuk, which index most user-space files for searching (presumably including by file name), but I always turn them off as they always seem to hammer my system at start up.
Simon
On Fri, May 16, 2014 at 04:36:04PM +0100, Simon Ransome wrote:
On 16/05/14 16:19, Chris Green wrote:
Exactly! What I want is a 'find' that uses a database like 'locate'. For me 'find' is perfect in what it does and how it allows me to tune the search but it's too slow if one is searching across a big disk.
Back in the late 1990s when I used to work at Suffolk County Council, we used to run a nightly cronjob which simply did "find / -print > /files.txt". It would then be trivial to do a virtually-instant "grep" for something in this file index, with the understanding that any files added that day would obviously not be included. But then you'd have only just created them, so you'd probably remember, or your application's "open recent" would still have a reference.
That's actually not a bad idea at all, I may try it. I wonder how long that find would take - it would give my computer something to do overnight though! :-)
Have you thought about aliasing the locate command to something including the switches you need?
Sent from my BlackBerry 10 smartphone on the EE network. Original Message From: Chris Green Sent: Friday, 16 May 2014 16:19 To: main@lists.alug.org.uk Subject: Re: [ALUG] Is there a better 'locate' anywhere?
On Fri, May 16, 2014 at 03:13:51PM +0100, Laurie Brown wrote:
On 16/05/14 14:57, Chris Green wrote:
Does anyone else find that 'locate' does all the wrong things for them? It's not that it's incapable of doing what I want but the defaults seem to be set up to be purposely the opposite of what I actually need it to do.
Have you tried "whereis"?
The whereis utility checks the standard binary, manual page, and source directories for the specified programs, printing out the paths of any it finds.
Yes, I know about 'whereis', useful sometimes (though 'man -k' is more often what I'm after on that front).
It's no good for finding that letter I wrote last year, or the laserjet 1320 PDF manual I know I saved somewhere (it was trying to find the 1320 manual that brought on this rant!).
Also, locate uses a database IIRC, which on my Gentoo systems is maintained nightly (cron) by a tool called updatedb. Consequently it's very fast.
Exactly! What I want is a 'find' that uses a database like 'locate'. For me 'find' is perfect in what it does and how it allows me to tune the search but it's too slow if one is searching across a big disk.
-
Chris Green -
Karl Foley -
Laurie Brown -
Simon Ransome