(old)Puppy Linux Discussion Forum

Posted: **Sat 31 Jan 2015, 00:16**

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]

Posted: **Sat 31 Jan 2015, 01:25**

What's the problem? This old dog works fine.

Aside from adding /usr/var/mlocate, /etc/group should list "mlocate

1001:" 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.

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!

Posted: **Sat 07 Feb 2015, 00:26**

Hi, Semme

... except "this old package" aborts because it can't find its stuff...

Back to the workbench, I suppose...

BFN.

musher0

Posted: **Sat 07 Feb 2015, 02:24**

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:

Code: Select all

slocate -e "/proc,/dev/,/tmp" -l0 -u

This will

* 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".

That's it. You're ready to go.

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

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

Posted: **Sat 07 Feb 2015, 05:08**

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.

Posted: **Sat 07 Feb 2015, 05:46**

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.

Try Recoll from the repos.
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.

Posted: **Sat 07 Feb 2015, 08:31**

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:

* 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.

In answer to mavrothal and nic007, may I suggest that some talented Puppyist
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

Posted: **Sat 07 Feb 2015, 09:39**

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

Posted: **Sat 07 Feb 2015, 10:03**

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

Posted: **Sat 07 Feb 2015, 12:46**

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

Hi, jasper.

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

Posted: **Sat 07 Feb 2015, 12:52**

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

Hi, 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

Posted: **Sat 07 Feb 2015, 13:00**

So you brushed up searchmonkey's interface for Puppy, eh?

no for me

...puppy (and anyone else) just happens to get the benefit

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

Posted: **Sat 07 Feb 2015, 13:10**

You're too modest!

Posted: **Sat 07 Feb 2015, 17:29**

So we have 2 ideal command level approaches for immediate response to the location of any file search from the linux command-line.

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

Considering the vast amounts of files any given system has today, we should ask developers to consider returning these Linux commands back into newly released versions of PUPs. This single addition provides great merit to all whether doing command line searches (where answers are returned immediately) or in script speed increases that chase filesystem for locations of elements (now there is now wait when such is perform).

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

Posted: **Sat 07 Feb 2015, 18:01**

@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

Posted: **Sat 07 Feb 2015, 18:55**

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

Posted: **Sun 08 Feb 2015, 05:33**

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

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.

Posted: **Sun 08 Feb 2015, 12:14**

I suppose I only search for things now and then.... and filename searches seem fast anyway...a few seconds on a 1TB external drive. ...only content takes a while.

What is everyone losing?

mike

Posted: **Sun 08 Feb 2015, 13:31**

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).

Posted: **Sun 08 Feb 2015, 14:25**

How do we get a petition going? Smile

thanks for the chuckle

Je ne suis pas intelligent, je suis agile.
Il m'aide à éviter les dagues.

mike

(old)Puppy Linux Discussion Forum

Normal Linux commands to Locate your system files, INSTANTLY

Normal Linux commands to Locate your system files, INSTANTLY