Normal Linux commands to Locate your system files, INSTANTLY
Normal Linux commands to Locate your system files, INSTANTLY
Commands which should be added back into the system's terminal commands: "updatedb" and "locatedb" or "slocate".
Linux commands whose benefits is explained here.
Over the years many of us have found our "find" command to be taking longer and longer. This is due to the very fact that more and more data is on our HDD/USB/SSD/etc storage media than ever before.
Many of us home users have music, family pictures, videos, documents, etc where our PUPs have been useful in our housing this content.
Its no wonder that locating data whose name and location we've forgot, is taking longer and longer.
Linux, for many years has addressed this, but, in PUPs beginnings, this was not considered.
Today, with so much data in the home we need every element of assistance to quickly find data, as is possible.
In this thread, there are 7 individual solutions which allows the PUP user to locate any files of theirs, instantly. Several of these are related, either directly or indirectly. None of these exist today in any 32bit PUPs but is available in a few 64bit PUPs. As you navigate thru this thread, pay attention, in reverse alphabetic order, to:[list]
[*]a solution referenced by @Uten ===> found in this thread, here
[*]a solution by @StemSee===> found in this thread, here
[*]a solution by @Slavvo67===> found in this thread, here
[*]a solution from @Seacyd offered by @Semme===> found in this thread, here
[*]a solution by @Musher0===> found in this thread, here
[*]a solution by @MikeB===> found in this thread, here
[*]a solution which exist in the FATDOG64/LIghtHouse64 distros[/list]This is a formal request asking developers of WOOFCE/WOOFQ/WOOF/etc, the PUP builder systems, to please consider add slocate or updatedb-locatedb-locate so that these can benefit users in finding files quickly in their PUP systems. These commands are not new to Linux, rather, they have been overlooked in Puppy Linux.
The members, in this thread, have certified the benefit to its use, have participated providing feedback in their findings, and have develop extended solutions of command-use facilitating file searches.[/color]
PUPPY WOOFCE & WOOFQ developer consideration requested.[/b]
Linux commands whose benefits is explained here.
Over the years many of us have found our "find" command to be taking longer and longer. This is due to the very fact that more and more data is on our HDD/USB/SSD/etc storage media than ever before.
Many of us home users have music, family pictures, videos, documents, etc where our PUPs have been useful in our housing this content.
Its no wonder that locating data whose name and location we've forgot, is taking longer and longer.
Linux, for many years has addressed this, but, in PUPs beginnings, this was not considered.
Today, with so much data in the home we need every element of assistance to quickly find data, as is possible.
In this thread, there are 7 individual solutions which allows the PUP user to locate any files of theirs, instantly. Several of these are related, either directly or indirectly. None of these exist today in any 32bit PUPs but is available in a few 64bit PUPs. As you navigate thru this thread, pay attention, in reverse alphabetic order, to:[list]
[*]a solution referenced by @Uten ===> found in this thread, here
[*]a solution by @StemSee===> found in this thread, here
[*]a solution by @Slavvo67===> found in this thread, here
[*]a solution from @Seacyd offered by @Semme===> found in this thread, here
[*]a solution by @Musher0===> found in this thread, here
[*]a solution by @MikeB===> found in this thread, here
[*]a solution which exist in the FATDOG64/LIghtHouse64 distros[/list]This is a formal request asking developers of WOOFCE/WOOFQ/WOOF/etc, the PUP builder systems, to please consider add slocate or updatedb-locatedb-locate so that these can benefit users in finding files quickly in their PUP systems. These commands are not new to Linux, rather, they have been overlooked in Puppy Linux.
The members, in this thread, have certified the benefit to its use, have participated providing feedback in their findings, and have develop extended solutions of command-use facilitating file searches.[/color]
PUPPY WOOFCE & WOOFQ developer consideration requested.[/b]
Last edited by gcmartin on Mon 02 Mar 2015, 20:31, edited 12 times in total.
What's the problem? This old dog works fine.
Aside from adding /usr/var/mlocate, /etc/group should list "mlocate1001:" after the addgroup bit.
The binary's about 30k. The db file depends on your systems root size.
Mine @ 1.3+ gigs registers about 5.2mbs.. Not bad considering..
And Oh Boy.. >> *Lightning* Fast!
Aside from adding /usr/var/mlocate, /etc/group should list "mlocate1001:" after the addgroup bit.
Code: Select all
$ locate -V
mlocate 0.24
Copyright (C) 2007 Red Hat, Inc. All rights reserved.
This software is distributed under the GPL v.2.
Mine @ 1.3+ gigs registers about 5.2mbs.. Not bad considering..
And Oh Boy.. >> *Lightning* Fast!
Hello, World!
(Continued from previous post)
... On the other hand, slocate works great on my slacko-6.0b! slocate is a "cousin"
of mlocate and locate, and serves the same purpose.
http://pkgs.org/slackware-14.1/slackwar ... 4.txz.html
(description)
http://slackware.cs.utah.edu/pub/slackw ... i486-4.txz
(download)
I unpacked and installed the above, and it ran "out of the box".
Once installed, the first (and essential) thing for you to do is to create its database
with the following command:
This will
If needed, I'll create a separate package for older Lucid, etc., Pups, But this slocate
is far from new, so the glibc version of the Puppy should have no effect, it shouldn't
be an hindrance for running this CLI program. Don't hesitate to let me know.
Attached is the slocate README as reference.
~~~~~~~~
One peculiarity of slocate, as I understand it, is that is does the job of locate and
updatedb. It has no need for those utilities, although they are sym-linked to slocate
in this slackware package.
~~~~~~~~
How-to.
This little guy slocate packs quite a punch, so most of the time, you'll want to
pipe it to grep. Have a look at this picture, starting backwards:
Let's take geany, for example. Now on my Pup, I've installed the geany plug-ins, so
there are lots of files with "geany" in their filename.
If I want to search for the executable only, issuing the command
is a waste of time. I get over a thousand lines.
I can start with filtering out anything present in the /initrd folder. Now that's better,
only 300 something results.
So I continue and now I "filter in" any "geany" line with "/bin" in it. And here we
go: 3 results. We're home !
~~~~~~~~~~~~
I must say that I'm impressed by the speed of this little utility, after all the waiting
often associated with working with pfind (but pfind is still a must, no doubt about
it!)
It goes without saying: many thanks to gcmartin for "putting a question mark over
my head" ! And I agree with him: given its very small size, -- vs its usefulness --,
slocate should be included in each and every Puppy.
I hope that this slocate tool will help you find your files faster on your Puppy.
BFN.
musher0
(Continued from previous post)
... On the other hand, slocate works great on my slacko-6.0b! slocate is a "cousin"
of mlocate and locate, and serves the same purpose.
http://pkgs.org/slackware-14.1/slackwar ... 4.txz.html
(description)
http://slackware.cs.utah.edu/pub/slackw ... i486-4.txz
(download)
I unpacked and installed the above, and it ran "out of the box".
Once installed, the first (and essential) thing for you to do is to create its database
with the following command:
Code: Select all
slocate -e "/proc,/dev/,/tmp" -l0 -u
- * create the files database,
* excluding anything in folders /proc, /dev and /tmp;
* make it available for all users (-l0 parameter; we don't need to specify
__ security levels for users, since a Puppy user always runs as "root");
* The -u parm is for updating, but at fist run, it means "create".
If needed, I'll create a separate package for older Lucid, etc., Pups, But this slocate
is far from new, so the glibc version of the Puppy should have no effect, it shouldn't
be an hindrance for running this CLI program. Don't hesitate to let me know.
Attached is the slocate README as reference.
~~~~~~~~
One peculiarity of slocate, as I understand it, is that is does the job of locate and
updatedb. It has no need for those utilities, although they are sym-linked to slocate
in this slackware package.
~~~~~~~~
How-to.
This little guy slocate packs quite a punch, so most of the time, you'll want to
pipe it to grep. Have a look at this picture, starting backwards:
Let's take geany, for example. Now on my Pup, I've installed the geany plug-ins, so
there are lots of files with "geany" in their filename.
If I want to search for the executable only, issuing the command
Code: Select all
slocate geany
I can start with filtering out anything present in the /initrd folder. Now that's better,
only 300 something results.
So I continue and now I "filter in" any "geany" line with "/bin" in it. And here we
go: 3 results. We're home !
~~~~~~~~~~~~
I must say that I'm impressed by the speed of this little utility, after all the waiting
often associated with working with pfind (but pfind is still a must, no doubt about
it!)
It goes without saying: many thanks to gcmartin for "putting a question mark over
my head" ! And I agree with him: given its very small size, -- vs its usefulness --,
slocate should be included in each and every Puppy.
I hope that this slocate tool will help you find your files faster on your Puppy.
BFN.
musher0
- Attachments
-
- slocate_README.zip
- (2.36 KiB) Downloaded 381 times
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
Try Recoll from the repos.nic007 wrote:Does Linux have anything as good as the programme, "Everything", which I use with Windows. That's finding files in real-time. Excellent and a must have.
Is a big big for puppy standards as it rewires both python and webkit but is probably the best of what is currently available in linux.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
Hello, all.
Just a note: it would be unfair not to mention that by default, Puppy already has
three "file detectives" in command line mode: find, whereis and which.
You can "man" all three to learn in detail what they do, but in a nutshell:
get to work on some gtk-dialog form for slocate, like the one zigbert wrote
for find/pfind?
Don't ask me. I'm horrible at XML, the stuff actually gives me allergies! I get
goose bumps just thinking about it. Brrr. However...
I'll gladly use it once done!
Bye for now.
musher0
Just a note: it would be unfair not to mention that by default, Puppy already has
three "file detectives" in command line mode: find, whereis and which.
You can "man" all three to learn in detail what they do, but in a nutshell:
- * find is slow at first search, but you can give it very elaborate parameters:
e.g. find a certain executable or document or db or whatever, in a certain folder,
starting at a certain mount point, and then launch it with executable X, Y or Z,
this way, but not that way,
* whereis will report anything that has to do with an executable under /usr
You can type < whereis geany > and you'll get all folders under /usr where the
name geany appears. Useful to locate a man file, a jpg, a script, etc. related to
the executable.
* which is the quickest, no-nonsense, to-the-point guy in this CLI team.
It only finds executables. Type < which geany >, and which answers :
/usr/bin/geany. Period.
However simple, this can be used to advantage. An untold use of which is as a
shortcut to launch an executable which you don't know for sure exists in your
Puppy, by typing it surrounded by tics, like so: < `which geany` >. which will
check if geany exists, and the tics will launch the executable when found.
If no executable, no launch.
The above form is much shorter and quicker than typing
< [ -e /usr/bin/geany ] && /usr/bin/geany >
and it does exactly the same thing.
get to work on some gtk-dialog form for slocate, like the one zigbert wrote
for find/pfind?
Don't ask me. I'm horrible at XML, the stuff actually gives me allergies! I get
goose bumps just thinking about it. Brrr. However...
I'll gladly use it once done!
Bye for now.
musher0
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
Hi musher0.
Thank you very much for improving my education with:
whereis
which
'which'
My personal favourite is <which>.
As regards your <'which geany'> example, merely typing <geany> in my urxvt terminal will launch geany (as last used) - though perhaps all tests are not so simple.
Using gRun [see screen shot] typing <gea> is sufficient to choose "geany" prior to clicking OK. To test, type <grun> then <gea>.
My regards
Thank you very much for improving my education with:
whereis
which
'which'
My personal favourite is <which>.
As regards your <'which geany'> example, merely typing <geany> in my urxvt terminal will launch geany (as last used) - though perhaps all tests are not so simple.
Using gRun [see screen shot] typing <gea> is sufficient to choose "geany" prior to clicking OK. To test, type <grun> then <gea>.
My regards
- Attachments
-
- gRun.png
- (9.94 KiB) Downloaded 938 times
If you don't want databases lying around and you like guis then searchmonkey I found to be as fast as anything I tried unless you go to gtk1 land .... content search and regular expressions too... invaluable for compiling I find to look for those 'lost' functions.
No bias...I did not write it...just tidied up the interface because I liked it
Indeed I turn off those indexing daemons in windows as they are a drag...and after all I am looking for stuff in unknown places like kernel sources, devx and app sources...NON of which would be in a recent database..... seems odd to search for stuff you already know about...but thats just me.
Mike
No bias...I did not write it...just tidied up the interface because I liked it
Indeed I turn off those indexing daemons in windows as they are a drag...and after all I am looking for stuff in unknown places like kernel sources, devx and app sources...NON of which would be in a recent database..... seems odd to search for stuff you already know about...but thats just me.
Mike
Hi, jasper.Jasper wrote:Hi musher0.
Thank you very much for improving my education with:
whereis
which
'which'
My personal favourite is <which>.
As regards your <'which geany'> example, merely typing <geany> in my urxvt terminal will launch geany (as last used) - though perhaps all tests are not so simple.
Using gRun [see screen shot] typing <gea> is sufficient to choose "geany" prior to clicking OK. To test, type <grun> then <gea>.
My regards
I agree. The form < `which geany` > would only used to replace the longer line I
mentioned. It would be used typically by a developer in the context of a bash script,
NOT by a user who simply wants to launch his program.
You wouldn't use the < `which geany` > form in a launcher such as grun or gexec.
BFN.
musher0
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
Hi, mike.mikeb wrote:If you don't want databases lying around and you like guis then searchmonkey I found to be as fast as anything I tried unless you go to gtk1 land .... content search and regular expressions too... invaluable for compiling I find to look for those 'lost' functions.
No bias...I did not write it...just tidied up the interface because I liked it
Indeed I turn off those indexing daemons in windows as they are a drag...and after all I am looking for stuff in unknown places like kernel sources, devx and app sources...NON of which would be in a recent database..... seems odd to search for stuff you already know about...but thats just me.
Mike
So you brushed up searchmonkey's interface for Puppy, eh?
As to db's, slocate takes a very long second to build its own... And it updates once
a day, not every minute.
In Linux, we're fast and intelligent, remember?! (A luxury under WhineDose...)
BFN.
musher0
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
no for me ...puppy (and anyone else) just happens to get the benefitSo you brushed up searchmonkey's interface for Puppy, eh?
http://www.murga-linux.com/puppy/viewto ... 57&t=90257
My windows is fast ...but yet I am not intelligent.... hmmm
I use linux for interest not need....
mike
So we have 2 ideal command level approaches for immediate response to the location of any file search from the linux command-line.
Thus, any new WOOFCE/WOOFQ/other PUP builders such that everyone has this benefit built in. The benefit is enormous, the penalty (called a "db", herein this thread) is too insignificant to consider as having any negligible impact on the system's download size (ISO/IMG).
Can we appeal again for PUP builder's considerations to benefit....
Edited: Boolean change
- The older updatedb (done once a day, say) and its companion locatedb (locate)
- OR slocate which uses switches to accomplish what is done by the above commands
Thus, any new WOOFCE/WOOFQ/other PUP builders such that everyone has this benefit built in. The benefit is enormous, the penalty (called a "db", herein this thread) is too insignificant to consider as having any negligible impact on the system's download size (ISO/IMG).
Can we appeal again for PUP builder's considerations to benefit....
Edited: Boolean change
Last edited by gcmartin on Tue 10 Feb 2015, 05:44, edited 1 time in total.
@gcmartin
How do we get a petition going?
-- Afterthought --
gc,
If I may, the AND in your post above should be an OR: both applications do the same
thing, it's the same approach. The difference between the two is that slocate appears
to be more compact, relying only on itself plus two symlinks (not full applications),
BFN.
musher0
How do we get a petition going?
-- Afterthought --
gc,
If I may, the AND in your post above should be an OR: both applications do the same
thing, it's the same approach. The difference between the two is that slocate appears
to be more compact, relying only on itself plus two symlinks (not full applications),
BFN.
musher0
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
I think Find works just fine and even if my scripts take 10+ minutes to find all the files that I'm trying to extract, the customizations (as mentioned earlier in this thread) make it suitable for most needs.
It works fairly well for finding items by mime type (I do get false positives here), files changed or modified between certain dates and specific or all file extensions.
Always nice to try new things, though. Speed is always nice to have.
Best,
Slavvo67
It works fairly well for finding items by mime type (I do get false positives here), files changed or modified between certain dates and specific or all file extensions.
Always nice to try new things, though. Speed is always nice to have.
Best,
Slavvo67
Indexing is turned off on my computer. "Everything" is lightning quick. When you start it the first time the database will obviously be built first (which doesn't take long). On my 80GB drive which is full (mostly mp3's), the data base is 300kb big. You don't notice the updates to the data base (too quick). I only start the programme when I need it so it does not run in the background. Makes no difference to the speed though.mikeb wrote:If you don't want databases lying around and you like guis then searchmonkey I found to be as fast as anything I tried unless you go to gtk1 land .... content search and regular expressions too... invaluable for compiling I find to look for those 'lost' functions.
No bias...I did not write it...just tidied up the interface because I liked it
Indeed I turn off those indexing daemons in windows as they are a drag...and after all I am looking for stuff in unknown places like kernel sources, devx and app sources...NON of which would be in a recent database..... seems odd to search for stuff you already know about...but thats just me.
Mike
I have quite a large music collection. The songs of a particular artists may be all over the show in seperate directories/sub-directories. Very easy to find and play directly with Everything. Get results whilst typing so most of the time you already have what you are looking for after typing only a few characters. The search string is also very "wide" so if searching for a song like "under the moon of love" eg. entering moo lov will give instantaneous results (in fact the search results change as you are typing).