Локальный полнотекстовый поиск в Linux

Tracker

http://www.htdig.org
http://searchmonkey.embeddediq.com/index.php
?

Lucene?

sphinx

Он все пункты умеет?

Нужно готовое решение, а не полуфабрикат в виде поискового движка.

Терзают сомнению насчет морфологии русского языка и распознавания кодировок.

Это на что-то похоже уже. Спасибо. Хотя отзывы о нем как-то не очень.

Lucene? Поддержка есть в KDE.

recoll http://www.lesbonscomptes.com/recoll/

как вариант google desktop

В KDE только из-за него переходить... А есть вариант с запуском из под Gnome или в нормальном виде оно жестко интегрировано?

recoll

Спасибо, тоже гляну.

как вариант google desktop

Он же закрыт с 2011-го, не? Да и раньше его использование чем-то эксгибиционизм напоминало, если правильно понял насчет интеграции с основным поиском.

recoll

Лорчую Индексую.

кроме кучи форматов, детекции языка и морфологии

Но тогда просто не подойдет, нужен не индексатор для СУБД, а локальный поисковик для десктопа среди кучи самых разных файлов. Эти пункты фактически ключевые.

kde ballo уже предлогали?

В нем есть баги, но фиксятся

http://richfriedeman.com/blog/2010/02/choosing-an-open-source-desktop-search-...

Если ты такой хейтер, можешь попробовать beagle. (It is written in C# using Mono and uses a port of Lucene to C# called Lucene.net as its indexer. Beagle includes a Gtk#-based user interface, and integrates with Galago for presence information.)

расскажешь тогда, на чем остановишься.

[offtop]
А для чего подобное может понадобиться?
[/offtop]

а grep чем не устраивает? :)

В итоге остановился на recoll. Из всех, он мне показался наиболее хорошо обрабатывающим разные документы. Однако существенный минус - довольно медленно работает и вывод результатов поиска не очень удобный: постраничный по 8 штук.

Ну вот допустим, если сохранять периодически интересные статьи из интернета, то через какое-то время в них становится трудно рыться.

Систематизируй и пользуйся grep'ом.

На практике систематизация не работает. recoll проиндексировал 140 тысяч файлов разного хлама. Из них, конечно очень много всяких попутных файлов, но даже реально полезных тысяч 10 - это уже много для систематизации. Ну не возможно все аккуратно разложить по полочкам. Могла бы здорово выручить теговая файловая система, в которой при сохранении файла можно было бы назначить несколько тегов, но такого нет.

grep не работает с произвольными файлами, вернее он бессмыслен для этого. Как ты grep применишь сразу для doc, odt, pdf, djvu, fb2 ?

grep не умеет семантический поиск.

recoll проиндексировал 140 тысяч файлов разного хлама

А какой получается размер индексов по сравнению с оригиналами?

На практике систематизация не работает

Ну, ХЗ. У меня вполне свежие мануалы и даташиты разложены логично: категория → подкатегория → субкатегория → специфика → даташит. А старье можно и удалить, все равно в этих трех десятков гигов файлов я разбираться не буду — проще скачать заново, чем старый хлам ворошить.

Как ты grep применишь сразу для doc, odt, pdf, djvu, fb2 ?

из этих форматов реально документация бывает только в pdf и djvu, однако, т.к. в дежавю никогда нет текстового слоя (иначе сделали бы pdf), текстовый поиск возможен лишь по pdf. И очень просто: pdftext file.pdf | less и ищешь что надо.

grep не умеет семантический поиск

Я вообще сомневаюсь, что какое-нибудь десктопное чудо это умеет. Да и на кой оно нужно? Чтобы найти, в каком файле у тебя лежит описание микроконтроллера ХЫЗЫ-шмяк-шмяк, достаточно грепа!

P.S. Я думаю, в твоей файлопомойке 99% шлака. Просто нажми F8 в mc на этой директории (или сделай rm -rf директория, если любишь командную строку), а потом заново собери материал, уже по-человечески его структурируя.

Точно не помню (я сейчас за другим компом), но вроде 3Гб по сравнению с 38 Гб. Но из этих 38 очень много не текстовых файлов вообще (рисунков и т.д). Предполагаю, что реалистичнее где-то 30% от исходной информации.

Ну, ХЗ. У меня вполне свежие мануалы и даташиты разложены логично:

Так ведь у меня не только мануалы и даташиты, а вообще любая информация, которая почему-то показалась интересной. Например, про историю живописи, новости, чьи-то рассказы, обсуждение бизнеса и т.п.

из этих форматов реально документация бывает только в pdf и djvu, однако, т.к. в дежавю никогда нет текстового слоя (иначе сделали бы pdf),

Полно djvu файлов с текстовым слоем, в некоторых я даже сам его добавлял.

Я вообще сомневаюсь, что какое-нибудь десктопное чудо это умеет. Да и на кой оно нужно?

recoll умеет. Правда не очень хорошо, но красивый по запросу красота находит.

Я думаю, в твоей файлопомойке 99% шлака.

Возможно. Поэтому и понадобился поиск :)

А мне рекурсивный греп норм. Кроме индекса все описанное умеет. Но для индекса есть locate и find. Юниксвей, типа. И на серверах удобно - ничего доставлять не надо. Портабельно, типа.

Вы тут явно недооцениваете греп. Он и в бинарнике текст найдет, и в блочном девайсе, и где угодно.

Например, про историю живописи, новости, чьи-то рассказы, обсуждение бизнеса и т.п.

Ставь локальную вики и заполняй.

Полно djvu файлов с текстовым слоем...

А смысл?

не очень хорошо

Во-во.

Он и в бинарнике текст найдет, и в блочном девайсе, и где угодно.

В произвольной кодировке? (хоть utf-8, хоть utf-16 le, хоть Koi8-r )Тогда действительно недооцениваю.

ЕМНИП, греп предполагает кодировку файлов основываясь на environment (LANG, LC_*). Можно подпихивать желаемые кодировки туда.

Но да, сам перебирать кодировки он не умеет.
:(

Ставь локальную вики и заполняй.

Это будет просто перенос с уровня файловой системы на уровень вики-движка. Поиск все-равно понадобится :) А хранить в вики очень разнородные файлы не совсем понятно как.

Хотя идея интересная, может мне действительно локальной вики для лучшей систематизации не хватает.

А смысл?

Такой же как и для pdf - искать текст, хотя бы по Ctrl+F. pdf тоже бывают из текста, а бывают с наложенным слоем поверх изображений.

Во-во.

Ну тем не менее, grep и этого не умеет. Вообще grep хорош для поиска среди исходников и внутри любого файла, но для файлопомойки, мне кажется не очень годен и в смысле удобства и качества.

И вообще, хранить инфу в не-юникоде - себя не уважать.

Просто для разных целей разные инструменты. Кстати, надо будет этот recoll повнимательнее изучить, а то есть подозрение, что он именно grep и использует при составлении индекса. После утилиты file, что даже где-то в описании есть. iconv тоже используется.

Так ведь в 99% случаев не я выбираю кодировку инфы. Можно конечно заняться ее перекодированием, но это уже лишним кажется.

Поиск все-равно понадобится :)

В вики-движке он уже есть.

А хранить в вики очень разнородные файлы не совсем понятно как.

Ну зачем? Зачем разнородные файлы-то качать?

гыгыгы

Ок, хранить инфу в не-юникоде - быть Эдиком.

Ну зачем? Зачем разнородные файлы-то качать?

Странный вопрос, да потому что она вот так в разнородном виде. Что-то в html, что-то в pdf, что-то в djvu, doc, даже бывают и более экзотические форматы.

Преимущества КОИ8: 1) минимум в 2 раза меньший объем файла; 2) элементарная работа со скриптами; 3) элементарная работа с сишными файлами (таки strlen равен длине строки в байтах — мегаудобно); 4) ну и, естественно, когда файлы имеют другую кодировку, нежели системная локаль, это жутко неудобно и приходится при помощи enconv преобразовывать их в кошерную однобайтную кодировку.

Да, я знаю что у тебя целая хитрая система для ведения холивара на любимую тему про КОИ8 :)

Ну так объективно хрюникод нужен лишь в pdf'ках каких-нибудь. И то, не всегда. В plain text от него 0 толку; даже наоборот: хуже с хрюникодом, нежели с любой 1-байтной кодировкой.