Probably wishful thinking on my part, but is there something akin
to Apple's SpotLight file finder on RasPiOS? I know about find and
grep -r, but those require operator skill and some patience.

Apt search locates mdfinder.app, but it's part of GNUstep and
I think that's a whole separate GUI by itself.

Thanks for reading!

bob prohaska

On 10/11/2022 18:36, bob prohaska wrote:
> I know about find and
> grep -r, but those require operator skill

find <starting point of search> -name <file name to search for>

Yes, it certainly does require some skill to use.

bob prohaska <bp@www.zefox.net> wrote:
> Probably wishful thinking on my part, but is there something akin
> to Apple's SpotLight file finder on RasPiOS? I know about find and
> grep -r, but those require operator skill and some patience.
>
> Apt search locates mdfinder.app, but it's part of GNUstep and
> I think that's a whole separate GUI by itself.

I've never had much to do with Apple stuff, so I just looked up
"Spotlight MacOS" and it sounds much more like the "locate" command
from GNU findutils, than "grep -r".

Personally I very rarely do whole-system file searches, so I just
use "find -name" in particular directories. But locate should be
much quicker for a system-wide search, you just have to run
"updatedb" regularly.

http://www.gnu.org/software/findutils/

--
__ __
#_ < |\| |< _#

Computer Nerd Kev <not@telling.you.invalid> wrote:
> I've never had much to do with Apple stuff, so I just looked up
> "Spotlight MacOS" and it sounds much more like the "locate" command
> from GNU findutils, than "grep -r".
>
> Personally I very rarely do whole-system file searches, so I just
> use "find -name" in particular directories. But locate should be
> much quicker for a system-wide search, you just have to run
> "updatedb" regularly.
>
> http://www.gnu.org/software/findutils/

Correct me if I'm wrong, but I think locate (and find(1) ) search file
*names*, while Spotlight (and grep) search file *contents*. Spotlight knows
how to interpret PDF, Word, etc files, not just plain text.

For similar searching of contents on Linux, there's an indexing library
called xapian and various frontends, eg
https://en.wikipedia.org/wiki/Recoll
(I think some desktop environments build this in, not sure about PiOS)

I can't really recommend a frontend, in fact the only reason I know about
Xapian is because I saw it eating CPU one day and worked out how to turn it
off.

Theo

Theo <theom+news@chiark.greenend.org.uk> writes:
> Computer Nerd Kev <not@telling.you.invalid> wrote:
>> I've never had much to do with Apple stuff, so I just looked up
>> "Spotlight MacOS" and it sounds much more like the "locate" command
>> from GNU findutils, than "grep -r".
>>
>> Personally I very rarely do whole-system file searches, so I just
>> use "find -name" in particular directories. But locate should be
>> much quicker for a system-wide search, you just have to run
>> "updatedb" regularly.
>>
>> http://www.gnu.org/software/findutils/
>
> Correct me if I'm wrong, but I think locate (and find(1) ) search file
> *names*, while Spotlight (and grep) search file *contents*. Spotlight knows
> how to interpret PDF, Word, etc files, not just plain text.

Yes. It also continuously maintains its index in response to file system
events, so the searching is fast. find, locate & grep are not a great
comparison.

--
http://www.greenend.org.uk/rjk/

Theo <theom+news@chiark.greenend.org.uk> wrote:
> Computer Nerd Kev <not@telling.you.invalid> wrote:
>> I've never had much to do with Apple stuff, so I just looked up
>> "Spotlight MacOS" and it sounds much more like the "locate" command
>> from GNU findutils, than "grep -r".
>>
>> Personally I very rarely do whole-system file searches, so I just
>> use "find -name" in particular directories. But locate should be
>> much quicker for a system-wide search, you just have to run
>> "updatedb" regularly.
>>
>> http://www.gnu.org/software/findutils/
>
> Correct me if I'm wrong, but I think locate (and find(1) ) search file
> *names*, while Spotlight (and grep) search file *contents*. Spotlight knows
> how to interpret PDF, Word, etc files, not just plain text.

Ah right, I didn't pick that up from skimming the Wikipedia page,
but in that case it's quite different. It must gemerate a very big
database if it covers file contents as well.

--
__ __
#_ < |\| |< _#

On 10-11-2022 23:08, Theo wrote:
> For similar searching of contents on Linux, there's an indexing library
> called xapian and various frontends, eg
> https://en.wikipedia.org/wiki/Recoll
> (I think some desktop environments build this in, not sure about PiOS)
>
> I can't really recommend a frontend, in fact the only reason I know about
> Xapian is because I saw it eating CPU one day and worked out how to turn it
> off.

Ha! A utility that works about the same as grep but much faster is
ripgrep which is in the RaspiOS repos under that name (so, sudo apt
install ripgrep), or https://github.com/BurntSushi/ripgrep . It installs
as 'rg' and there's a man page 'man rg'. Similarly, try fd-find as a
replacement for find. It installs a binary called fdfind, for which I
make an alias 'fd' but that could clash if you already have something
called fd. Man fd and man fdfind both work out of the box, confusingly.

Apt info of ripgrep:

> Recursively searches directories for a regex pattern
> ripgrep is a line-oriented search tool that recursively searches your current
> directory for a regex pattern while respecting your gitignore rules and
> automatically skip hidden files/directories (smart filtering) and binary files.
> ripgrep is similar to other popular search tools like The Silver Searcher, ack
> and grep.
> .
> ripgrep is generally faster than both The Silver Searcher and GNU grep. It
> defaults to recursive directory search and won't search files ignored by your
> `.gitignore` files. Use ripgrep if you like speed, filtering by default, fewer
> bugs, and Unicode support.
> .
> On the other hand, if you like multiline search, then ripgrep may not quite
> meet your needs (yet), and it will never support fancy regex features such as
> backreferences or lookaround
> .
> This package contains the following binaries built from the Rust crate
> "ripgrep":
> - rg

And fd-find:

> Simple, fast and user-friendly alternative to find
> While it does not seek to mirror all of find's powerful functionality,
> fd provides sensible (opinionated) defaults for 80% of the use cases.
> .
> Features:
> .
> * Convenient syntax: ‘fd PATTERN’ instead of ‘find -iname '*PATTERN*'’.
> * Colorized terminal output (similar to ls).
> * It's fast, often faster than find.
> * Smart case.
> * Ignores hidden directories and files, by default.
> * Ignores patterns from your .gitignore, by default.
> * Regular expressions.
> * Unicode-awareness.
> * Parallel command execution with a syntax similar to GNU Parallel.
> .
> Please note: the executable and the associated manpage were renamed
> from ‘fd’ to ‘fdfind’ because of a file name clash.

On 11-11-2022 08:10, A. Dumas wrote:
> [...] ripgrep:
> And fd-find:

I learned about those from https://www.youtube.com/c/MissingSemester
which also had other useful things. Their git lecture was a bit crap; as
always too slow at the start and then followed by "eh, this should've
worked *clippety clop* ok I fixed it". And I hate them all jerking off
to vim like they are in a secret society keeping the riff raff out.

Computer Nerd Kev <not@telling.you.invalid> wrote:
> Theo <theom+news@chiark.greenend.org.uk> wrote:
> > Correct me if I'm wrong, but I think locate (and find(1) ) search file
> > *names*, while Spotlight (and grep) search file *contents*. Spotlight knows
> > how to interpret PDF, Word, etc files, not just plain text.
>
> Ah right, I didn't pick that up from skimming the Wikipedia page,
> but in that case it's quite different. It must gemerate a very big
> database if it covers file contents as well.

Yes it does. With grep and friends you're doing the processing at the time
of search, while with Spotlight and Xapian you're doing it ahead of time so
that the search is faster.

The downside of building that database is it takes CPU cycles - which is
fine for some use cases. Personally using laptops they are either in use on
battery or sleeping, so there's no time when there are 'free' CPU cycles
that don't waste battery. A Pi is probably less worried about that.

Theo

On Fri, 11 Nov 2022 08:57:07 +0100, A. Dumas wrote:

> On 11-11-2022 08:10, A. Dumas wrote:
>> [...] ripgrep:
>> And fd-find:
>
> I learned about those from https://www.youtube.com/c/MissingSemester
> which also had other useful things. Their git lecture was a bit crap; as
> always too slow at the start and then followed by "eh, this should've
> worked *clippety clop* ok I fixed it". And I hate them all jerking off
> to vim like they are in a secret society keeping the riff raff out.

Its worth remembering 'apropos' for when you're looking for a command or
library function to do a specific task. It searches manpage's heading
lines for matching words and phrases, so its fast.

"apropos 'search tree'" returns 6 hits:

tdelete (3) - manage a binary search tree
tdestroy (3) - manage a binary search tree
tfind (3) - manage a binary search tree
tsearch (3) - manage a binary search tree
twalk (3) - manage a binary search tree
twalk_r (3) - manage a binary search tree

in 79mS and they're all relevant manpages for functions you'd use to walk
an in-memory binary tree structure.

--

Martin | martin at
Gregorie | gregorie dot org

Theo <theom+news@chiark.greenend.org.uk> wrote:
> Computer Nerd Kev <not@telling.you.invalid> wrote:
>> Theo <theom+news@chiark.greenend.org.uk> wrote:
>> > Correct me if I'm wrong, but I think locate (and find(1) ) search file
>> > *names*, while Spotlight (and grep) search file *contents*. Spotlight knows
>> > how to interpret PDF, Word, etc files, not just plain text.
>>
>> Ah right, I didn't pick that up from skimming the Wikipedia page,
>> but in that case it's quite different. It must gemerate a very big
>> database if it covers file contents as well.
>
> Yes it does. With grep and friends you're doing the processing at the time
> of search, while with Spotlight and Xapian you're doing it ahead of time so
> that the search is faster.
>
> The downside of building that database is it takes CPU cycles - which is
> fine for some use cases. Personally using laptops they are either in use on
> battery or sleeping, so there's no time when there are 'free' CPU cycles
> that don't waste battery. A Pi is probably less worried about that.

I tried installing xapian-omega, since this is a desktop machine with
lots of unused cpu time. The install seems successful, but I can't make
heads nor tails of how to use it. Bash can't find an executable by that
name, there's no manpage and no obvious additions to the main menu list.
I also installed xapian-tools, which added more software but not obvious
user interface.

Anybody got a hint? The machine is running buster. One inexplicable
oddity is that the main menu icon is the Gnome footprint, which appeared
unbidden after an upgrade a longish time ago.

Thanks for reading,

bob prohaska

additions to the

bob prohaska <bp@www.zefox.net> wrote:
>
> I tried installing xapian-omega, since this is a desktop machine with
> lots of unused cpu time. The install seems successful, but I can't make
> heads nor tails of how to use it. Bash can't find an executable by that
> name, there's no manpage and no obvious additions to the main menu list.
> I also installed xapian-tools, which added more software but not obvious
> user interface.
>
> Anybody got a hint?

Just a generic solution:
dpkg -L [package name] | grep /bin

You can also use "apt-file list" to list files in packages that
aren't already installed (you may need to install apt-file).

--
__ __
#_ < |\| |< _#

Computer Nerd Kev <not@telling.you.invalid> wrote:
> bob prohaska <bp@www.zefox.net> wrote:
>>
>> I tried installing xapian-omega, since this is a desktop machine with
>> lots of unused cpu time. The install seems successful, but I can't make
>> heads nor tails of how to use it. Bash can't find an executable by that
>> name, there's no manpage and no obvious additions to the main menu list.
>> I also installed xapian-tools, which added more software but not obvious
>> user interface.
>>
>> Anybody got a hint?
>
> Just a generic solution:
> dpkg -L [package name] | grep /bin

That gave a hint to the doc files. Looks like xapian is a search
engine intended for websites. Not quite what I was looking for,
but maybe the only game in town. I'll explore further.

Thank you very much!

bob prohaska

bob prohaska <bp@www.zefox.net> wrote:
> Computer Nerd Kev <not@telling.you.invalid> wrote:
> > bob prohaska <bp@www.zefox.net> wrote:
> >>
> >> I tried installing xapian-omega, since this is a desktop machine with
> >> lots of unused cpu time. The install seems successful, but I can't make
> >> heads nor tails of how to use it. Bash can't find an executable by that
> >> name, there's no manpage and no obvious additions to the main menu list.
> >> I also installed xapian-tools, which added more software but not obvious
> >> user interface.
> >>
> >> Anybody got a hint?
> >
> > Just a generic solution:
> > dpkg -L [package name] | grep /bin
>
> That gave a hint to the doc files. Looks like xapian is a search
> engine intended for websites. Not quite what I was looking for,
> but maybe the only game in town. I'll explore further.

xapian is a library for indexing files. Where you choose to use it is up to
whatever frontend you use. I mentioned Recoll before, and:

sudo apt install recollgui
recoll

and up pops up a dialogue saying 'do I want to index my home directory?'. I
say yes, and then I can search for things - eg I searched for the word 'the' and
it found it in a PDF in my Downloads.

Theo

Theo <theom+news@chiark.greenend.org.uk> wrote:
I mentioned Recoll before, and:
>
> sudo apt install recollgui
> recoll
>
> and up pops up a dialogue saying 'do I want to index my home directory?'. I

Indeed you did, and I missed it.

Recoll is indexing now.

Thank you!

bob prohaska

On Fri, 11 Nov 2022 08:10:47 +0100, "A. Dumas"
<alexandre@dumas.fr.invalid> wrote:

> A utility that works about the same as grep but much faster is
> ripgrep which is in the RaspiOS repos under that name (so, sudo apt
> install ripgrep), or https://github.com/BurntSushi/ripgrep

Yet another one, also available in RaspiOS :
sudo apt install silversearcher-ag

Described as "very fast grep-like program, alternative to
ack-grep"

The executable is called ag.

From the man page:
"By default, ag will ignore files whose names match patterns in
..gitignore, .hgignore, or .ignore. These files can be anywhere
in the directories being searched. Binary files are ignored by
default as well. Finally, ag looks in $HOME/.agignore for ignore
patterns."
"Use the -t option to search all text files; -a to search all
files; and -u to search all, including hidden files."

Example ~/.agignore:
..bash_history
..fslckout
*.~*
*.log
*.pdf
*.sqlite
*.sqlite-shm
*.sqlite-wal
*.zip
/fcgi/**/*ico
/fcgi/**/*png
/tmp/**
/var/**

I use it via this alias:
ag='/usr/bin/ag --context=1 --hidden'

--
Kees Nuyt

bob prohaska <bp@www.zefox.net> wrote:
> Theo <theom+news@chiark.greenend.org.uk> wrote:
> I mentioned Recoll before, and:
>>
>> sudo apt install recollgui
>> recoll
>>
>> and up pops up a dialogue saying 'do I want to index my home directory?'. I

Seems to work just fine. Amazing what rubbish chromium saves!

Thanks for your help!

bob prohaska