Puppy Linux Discussion Forum

[gcmartin]

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:

• 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
  

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.

PUPPY WOOFCE & WOOFQ developer consideration requested.
_________________
Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Engines or use DogPile

Last edited by gcmartin on Mon 02 Mar 2015, 16:31; edited 12 times in total

[Semme]

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

Aside from adding /usr/var/mlocate, /etc/group should list "mlocate:x:1001:" after the addgroup bit.

[musher0]

Hi, Semme

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

Back to the workbench, I suppose...

BFN.

musher0

[musher0]

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/slackware-i486/slocate-3.1-i486-4.txz.html
(description)

http://slackware.cs.utah.edu/pub/slackware/slackware-14.1/slackware/a/slocate-3.1-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:

[nic007]

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.

[mavrothal]

[musher0]

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

[Jasper]

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

[mikeb]

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

[musher0]

[musher0]

[mikeb]

[musher0]

You're too modest!

[gcmartin]

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

[musher0]

@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