Hello!
On Wednesday 10 February 2010 21:17:24 Serhiy Storchaka wrote:
> >> В идеале программа должна уметь принимать список файлов как из командной
> >> строки, так и из файла или stdin (при указании специального ключа).
> >
> > poisk-cmdline file1 ... fileN | poisk-files-add
>
> Чем это лучше
>
Alexey Pechnikov wrote:
> On Saturday 06 February 2010 12:01:25 Serhiy Storchaka wrote:
>> В идеале программа должна уметь принимать список файлов как из командной
>> строки, так и из файла или stdin (при указании специального ключа).
>
> poisk-cmdline file1 ... fileN | poisk-files-add
Чем это лу
Hello!
On Saturday 06 February 2010 12:01:25 Serhiy Storchaka wrote:
> В идеале программа должна уметь принимать список файлов как из командной
> строки, так и из файла или stdin (при указании специального ключа).
poisk-cmdline file1 ... fileN | poisk-files-add
$ cat poisk-cmdline
#!/bin/dash
#
Hello!
On Sunday 07 February 2010 17:20:04 Feata`lion Nyere`` wrote:
> Спасибо за ответ, я какраз думал о том, чтобы при невозможности расширения
> до http делать зеркало интересующих ресурсов.
Расширить-то можно, но полученное решение значительно проиграет связке
файлового индексатора + wget. В
Hello!
On Sunday 07 February 2010 15:14:23 Feata`lion Nyere`` wrote:
> Господин Печников, не могли бы Вы уточнить, возможна ли опция индексирования
> удалённых файлов по http или простой способ добавления её?
Индексирование списка html-страниц проблемы не представляет. Что касается
прочих
форма
Hello!
On Saturday 06 February 2010 17:49:24 Yuriy Kaminskiy wrote:
> впрочем, я в своих скриптах на существование таких файлов тоже забиваю ;-)
> [но одно дело мои скрипты для локального использования, другое - программа для
> пользования другими в непредсказуемом окружении; как минимум, непонима
Hello!
On Saturday 06 February 2010 18:15:00 Alexander Galanin wrote:
> > Если сделать поддержку \n в именах, придется и здесь в выводе использовать
> > \0,
> > и сделать даже простой греп будет весьма проблематично. Получаемые же
>
> Можно экранировать \n так, как это делает ls -b. Тогда лишне
Hello!
On Saturday 06 February 2010 12:01:25 Serhiy Storchaka wrote:
> В идеале программа должна уметь принимать список файлов как из командной
> строки, так и из файла или stdin (при указании специального ключа).
Об этом я тоже думаю, можно сделать так:
find | poisk-add file1 file2 ... fileN
Artem Chuprina wrote:
> Serhiy Storchaka -> debian-russian@lists.debian.org @ Sat, 06 Feb 2010
> 09:57:21 +0200:
> SS> Достаточно -exec poisk-add.
>
> Я тоже сначала так подумал. Но это будет, вообще говоря, другая модель
> использования.
>
> В stdin ты ему их сможешь передать сразу все, а чер
Artem Chuprina wrote:
> Serhiy Storchaka -> debian-russian@lists.debian.org @ Sat, 06 Feb 2010
> 10:04:19 +0200:
> SS> Нет-нет. Если это пользовательская утилита, то она должна быть
> SS> простой в использовании для типичных применений. Указал в кронтабе
> SS> poisk-scanner /var/www/mysite — и
Serhiy Storchaka -> debian-russian@lists.debian.org @ Sat, 06 Feb 2010
09:57:21 +0200:
>> AP> find "$@" 2>/dev/null | poisk-add "$POISKDB"
>>
>> Ох... Вот бы не так топорно, а хотя бы find "$@" -print0, и poisk-add
>> обучить по нуль-символу видеть границу имени файла. Ибо про перевод
>
Serhiy Storchaka -> debian-russian@lists.debian.org @ Sat, 06 Feb 2010
10:04:19 +0200:
>> SS> poisk-scanner-у нужно иметь возможность указать не только, что
>> SS> индексировать, но и что пропускать. По маске имени, явно указывая
>> SS> пути.
>>
>> Пусть сделает poisk-add. А poisk-scan
Artem Chuprina wrote:
> Serhiy Storchaka -> debian-russian@lists.debian.org @ Fri, 05 Feb 2010
> 23:22:07 +0200:
> SS> poisk-scanner-у нужно иметь возможность указать не только, что
> SS> индексировать, но и что пропускать. По маске имени, явно указывая
> SS> пути.
>
> Пусть сделает poisk-add.
Artem Chuprina wrote:
> Alexey Pechnikov -> debian-russian@lists.debian.org @ Sat, 6 Feb 2010
> 00:51:38 +0300:
> AP> find "$@" 2>/dev/null | poisk-add "$POISKDB"
>
> Ох... Вот бы не так топорно, а хотя бы find "$@" -print0, и poisk-add
> обучить по нуль-символу видеть границу имени файла. Ибо
Alexey Pechnikov -> debian-russian@lists.debian.org @ Fri, 5 Feb 2010 23:27:00
+0300:
>> AP> А вот это не годится. Данные могут быть перемещены на другой диск
>> AP> или даже на другой компьютер, это не повод их переиндексировать.
>>
>> А у тебя переиндексация точно существенно дороже, че
Alexey Pechnikov -> debian-russian@lists.debian.org @ Sat, 6 Feb 2010 00:51:38
+0300:
>> > А, понял. В таком случае утилиту обработки файлов переименую в poisk-add,
>> > велю ей список файлов принимать на stdin, а poisk-scanner сделаю оберткой.
>>
>> poisk-scanner-у нужно иметь возможность
Serhiy Storchaka -> debian-russian@lists.debian.org @ Fri, 05 Feb 2010
23:22:07 +0200:
>> А, понял. В таком случае утилиту обработки файлов переименую в
>> poisk-add, велю ей список файлов принимать на stdin, а poisk-scanner
>> сделаю оберткой.
SS> poisk-scanner-у нужно иметь возможность ук
Hello!
On Saturday 06 February 2010 00:22:07 Serhiy Storchaka wrote:
> > А, понял. В таком случае утилиту обработки файлов переименую в poisk-add,
> > велю ей список файлов принимать на stdin, а poisk-scanner сделаю оберткой.
>
> poisk-scanner-у нужно иметь возможность указать не только, что
> ин
Alexey Pechnikov wrote:
> А, понял. В таком случае утилиту обработки файлов переименую в poisk-add,
> велю ей список файлов принимать на stdin, а poisk-scanner сделаю оберткой.
poisk-scanner-у нужно иметь возможность указать не только, что
индексировать, но и что пропускать. По маске имени, явно у
Hello!
On Friday 05 February 2010 22:22:01 Artem Chuprina wrote:
> AP> А вот это не годится. Данные могут быть перемещены на другой диск
> AP> или даже на другой компьютер, это не повод их переиндексировать.
>
> А у тебя переиндексация точно существенно дороже, чем md5?
Убрал подсчет md5 сумм
Hello!
On Friday 05 February 2010 22:58:10 Victor Wagner wrote:
> > Откуда стремление засунуть эту логику обязательно в индексатор?
> > Пожалуй, и проверку
>
> Ну юзерский это подход. Индексатор это та штука, вызов которой надо
> засунуть в crontab, чтобы потом поиск работал.
>
> А вовсе не то
On 2010.02.05 at 22:14:15 +0300, Alexey Pechnikov wrote:
>
> Откуда стремление засунуть эту логику обязательно в индексатор?
> Пожалуй, и проверку
Ну юзерский это подход. Индексатор это та штука, вызов которой надо
засунуть в crontab, чтобы потом поиск работал.
А вовсе не то, что кладет в баз
Alexey Pechnikov -> debian-russian@lists.debian.org @ Fri, 5 Feb 2010 19:03:57
+0300:
>> >> Можно проверять дату последней модификации файла до вычисления хэша и
>> >> определения типа mime. Это значительно ускорит повторное сканирование.
>> >
>> > Проверка по mtime имхо совершенно ненадежн
Hello!
On Friday 05 February 2010 21:34:35 Dmitri V. Ivanov wrote:
> > Хэш - он не для поиска новых файлов, а для проверки необходимости
> > переиндексировать. Если хэш совпадает, индексатор с чистой совестью может
> > игнорировать файл.
>
> Если система у нас - linux или freebsd (есть тонкие м
On Fri, Feb 05, 2010 at 08:36:11PM +0300, Alexey Pechnikov wrote:
> Hello!
>
> On Friday 05 February 2010 20:15:18 Dmitri V. Ivanov wrote:
> > Вообще-то я писал на эту тему скриптик (поиск файлов, измененных с
> > предыдущего
> > прохода в posix-овой файловой системе) и могу поделиться, если инте
Hello!
On Friday 05 February 2010 20:15:18 Dmitri V. Ivanov wrote:
> Вообще-то я писал на эту тему скриптик (поиск файлов, измененных с предыдущего
> прохода в posix-овой файловой системе) и могу поделиться, если интересно.
> На perl.
Да, интересно, в качестве обертки к индексатору.
> А хэш IMH
On Fri, Feb 05, 2010 at 07:11:29PM +0300, Alexey Pechnikov wrote:
> Стоит решать названную задачу совсем другим методом. А именно - команда find
> с нужными параметрами выбирает файлы, к примеру, изменившиеся за последние
> 24 часа и скармливает их список индексатору. Задача последнего - обновить
On Fri, Feb 05, 2010 at 06:18:57PM +0300, Alexey Pechnikov wrote:
> Hello!
>
> On Friday 05 February 2010 18:13:24 Serhiy Storchaka wrote:
> > Можно проверять дату последней модификации файла до вычисления хэша и
> > определения типа mime. Это значительно ускорит повторное сканирование.
>
> Прове
Hello!
On Friday 05 February 2010 19:25:15 Victor Wagner wrote:
> > > Можно ещё размер проверять (всё равно хранится). Или, для параноиков,
> > > idev:inode.
> >
> > А вот это не годится. Данные могут быть перемещены на другой диск или даже
> > на
> > другой компьютер, это не повод их переиндекс
On 2010.02.05 at 19:03:57 +0300, Alexey Pechnikov wrote:
> Hello!
>
> On Friday 05 February 2010 18:47:19 Serhiy Storchaka wrote:
> > > On Friday 05 February 2010 18:13:24 Serhiy Storchaka wrote:
> > >> Можно проверять дату последней модификации файла до вычисления хэша и
> > >> определения типа
On 2010.02.05 at 17:54:25 +0200, Serhiy Storchaka wrote:
> Victor Wagner wrote:
> > On 2010.02.05 at 18:18:57 +0300, Alexey Pechnikov wrote:
> >> Проверка по mtime имхо совершенно ненадежна, предпочитаю по хэшу.
> >
> > Зато - быстра. И то недостаточно Вот FBReader при старте делает mtime
> > вс
Hello!
On Friday 05 February 2010 18:25:46 Victor Wagner wrote:
> > Проверка по mtime имхо совершенно ненадежна, предпочитаю по хэшу.
>
> Зато - быстра. И то недостаточно Вот FBReader при старте делает mtime
> всем файлам, которые уже видел, так если его на миррор lib.rus.ec
> напустить, будет н
Hello!
On Friday 05 February 2010 18:47:19 Serhiy Storchaka wrote:
> > On Friday 05 February 2010 18:13:24 Serhiy Storchaka wrote:
> >> Можно проверять дату последней модификации файла до вычисления хэша и
> >> определения типа mime. Это значительно ускорит повторное сканирование.
> >
> > Проверк
Victor Wagner wrote:
> On 2010.02.05 at 18:18:57 +0300, Alexey Pechnikov wrote:
>> Проверка по mtime имхо совершенно ненадежна, предпочитаю по хэшу.
>
> Зато - быстра. И то недостаточно Вот FBReader при старте делает mtime
> всем файлам, которые уже видел, так если его на миррор lib.rus.ec
> напу
Alexey Pechnikov wrote:
> On Friday 05 February 2010 18:13:24 Serhiy Storchaka wrote:
>> Можно проверять дату последней модификации файла до вычисления хэша и
>> определения типа mime. Это значительно ускорит повторное сканирование.
>
> Проверка по mtime имхо совершенно ненадежна, предпочитаю по х
On 2010.02.05 at 18:18:57 +0300, Alexey Pechnikov wrote:
> Проверка по mtime имхо совершенно ненадежна, предпочитаю по хэшу.
Зато - быстра. И то недостаточно Вот FBReader при старте делает mtime
всем файлам, которые уже видел, так если его на миррор lib.rus.ec
напустить, будет несколько минут в
Hello!
On Friday 05 February 2010 18:13:24 Serhiy Storchaka wrote:
> Можно проверять дату последней модификации файла до вычисления хэша и
> определения типа mime. Это значительно ускорит повторное сканирование.
Проверка по mtime имхо совершенно ненадежна, предпочитаю по хэшу.
> И разве в tcllib
Можно проверять дату последней модификации файла до вычисления хэша и
определения типа mime. Это значительно ускорит повторное сканирование.
И разве в tcllib нет реализации md5, что дёргается внешний бинарник?
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject o
Hello!
On Friday 05 February 2010 13:59:21 Artem Chuprina wrote:
> AP> Это похоже на правду. Но в таком случае от использования exec весьма
> AP> сомнительная польза, а на серверах так и вовсе.
>
> На двух четырехъядерниках (в смысле один сервер с двумя
> четырехъядерниками) все тот же самый з
Alexander Galanin wrote:
> On Thu, 4 Feb 2010 22:17:31 +0300
> Alexey Pechnikov wrote:
>
>> Итого с exec почти вдвое медленнее.
>>
>> cpu cores: 2
> ^^^ --- наверно, тут собака зарыта
>
> Потому как я на однопроцессорных машинах проверял и exec закономерно
> выигрывал.
У ме
Alexey Pechnikov wrote:
> =
> $ cat ./x-c
> #!/bin/dash
>
> exec /bin/cat
>
> $ time seq 1000 | xargs -n 1 ./x-c /dev/null
а) 1, а не 1000.
б) Куда делся "$1"?
в) Отсутствует >/dev/null.
У меня это на тенденцию не влияет, а как у вас — не знаю.
--
To UNSUBSCRIBE, email to debian-
Hello!
On Thursday 04 February 2010 22:25:12 Alexander Galanin wrote:
> > Итого с exec почти вдвое медленнее.
> >
> > cpu cores : 2
> ^^^ --- наверно, тут собака зарыта
>
> Потому как я на однопроцессорных машинах проверял и exec закономерно
> выигрывал.
Это похоже на правду
Hello!
On Thursday 04 February 2010 22:09:23 Alexander Galanin wrote:
> On Thu, 4 Feb 2010 22:03:38 +0300
> Alexey Pechnikov wrote:
>
> > Hello!
> >
> > On Thursday 04 February 2010 21:37:49 Alexander Galanin wrote:
> > > cat в некоторых шеллах встроенный, потому и может оказаться быстрее. Для
Hello!
On Thursday 04 February 2010 21:37:49 Alexander Galanin wrote:
> cat в некоторых шеллах встроенный, потому и может оказаться быстрее. Для
> чистоты эксперимента надо вызывать /bin/cat.
Да как ни вызывай, с exec медленнее:
=
$ cat ./x-c
#!/bin/dash
exec /bin/cat
$ time seq 1000
Alexander Galanin wrote:
> cat в некоторых шеллах встроенный, потому и может оказаться быстрее. Для
> чистоты эксперимента надо вызывать /bin/cat.
Да, это бы объяснило.
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas
Alexey Pechnikov wrote:
> On Thursday 04 February 2010 21:28:23 Serhiy Storchaka wrote:
>> > Еще какая разница - с exec _втрое медленнее_.
>>
>> Не верю. Можно объяснить ускорение, можно понять отсутствие заметной
>> разницы, — замедление объяснить нельзя.
>
> Попробуйте свой же тест выполнить, с
On Thu, 04 Feb 2010 20:28:23 +0200
Serhiy Storchaka wrote:
> Alexey Pechnikov wrote:
> > On Thursday 04 February 2010 19:43:40 Serhiy Storchaka wrote:
> >> Не только. Вероятно сам fork (за которым потом всё равно следует exec)
> >> всё же дорог. Попробуйте
> >>
> >> time seq 1 | xargs -n 1 .
On Thu, 4 Feb 2010 20:32:39 +0300
Alexey Pechnikov wrote:
> Hello!
>
> On Thursday 04 February 2010 20:15:48 Alexander Galanin wrote:
> > > > > Recommends и depends нынче эквивалентны. Разве что в Suggests
> > > > > поставить.
> > > >
> > > > От Recommends отказаться можно. От Depends — нет.
>
Hello!
On Thursday 04 February 2010 21:28:23 Serhiy Storchaka wrote:
> > Еще какая разница - с exec _втрое медленнее_.
>
> Не верю. Можно объяснить ускорение, можно понять отсутствие заметной
> разницы, — замедление объяснить нельзя.
Попробуйте свой же тест выполнить, сами увидите.
Best regards
Alexey Pechnikov wrote:
> On Thursday 04 February 2010 19:48:25 Serhiy Storchaka wrote:
>> > Recommends и depends нынче эквивалентны. Разве что в Suggests
>> > поставить.
>>
>> От Recommends отказаться можно. От Depends — нет.
>
> Э-э-э, по дефолту они ведут себя одинаково, так что разница неощут
Alexey Pechnikov wrote:
> On Thursday 04 February 2010 19:43:40 Serhiy Storchaka wrote:
>> Не только. Вероятно сам fork (за которым потом всё равно следует exec)
>> всё же дорог. Попробуйте
>>
>> time seq 1 | xargs -n 1 ./x-c /dev/null >/dev/null
>>
>> и то же с exec в x-c. Разница есть.
>>
Hello!
On Thursday 04 February 2010 20:15:48 Alexander Galanin wrote:
> > > > Recommends и depends нынче эквивалентны. Разве что в Suggests поставить.
> > >
> > > От Recommends отказаться можно. От Depends — нет.
> >
> > Э-э-э, по дефолту они ведут себя одинаково, так что разница неощутима.
>
>
On Thu, 4 Feb 2010 19:59:42 +0300
Alexey Pechnikov wrote:
> Hello!
>
> On Thursday 04 February 2010 19:48:25 Serhiy Storchaka wrote:
> > > Recommends и depends нынче эквивалентны. Разве что в Suggests поставить.
> >
> > От Recommends отказаться можно. От Depends — нет.
>
> Э-э-э, по дефолту он
Hello!
On Thursday 04 February 2010 19:43:40 Serhiy Storchaka wrote:
> Не только. Вероятно сам fork (за которым потом всё равно следует exec) всё
> же дорог. Попробуйте
>
> time seq 1 | xargs -n 1 ./x-c /dev/null >/dev/null
>
> и то же с exec в x-c. Разница есть.
>
Еще какая разница - с ex
Hello!
On Thursday 04 February 2010 19:48:25 Serhiy Storchaka wrote:
> > Recommends и depends нынче эквивалентны. Разве что в Suggests поставить.
>
> От Recommends отказаться можно. От Depends — нет.
Э-э-э, по дефолту они ведут себя одинаково, так что разница неощутима.
> > Suggests придется ру
Alexey Pechnikov wrote:
> Recommends и depends нынче эквивалентны. Разве что в Suggests поставить.
От Recommends отказаться можно. От Depends — нет.
> Suggests придется ручками доставлять, а мне бы хотелось автоматизма.
Вот sqlite3, насколько я понимаю, можно в Suggests или вообще убрать.
--
Artem Chuprina wrote:
> Alexey Pechnikov -> debian-russian@lists.debian.org @ Thu, 4 Feb 2010
> 16:28:42 +0300:
> AP> А можете подробнее рассказать? Я не в курсе, что с exec может быть
> быстрее.
>
> На самом деле быстрее - вряд ли. Это потеря скорее в памяти. exec -
> запуск без fork, с заме
Hello!
On Thursday 04 February 2010 17:36:32 Artem Chuprina wrote:
> Alexey Pechnikov -> debian-russian@lists.debian.org @ Thu, 4 Feb 2010
> 16:28:42 +0300:
>
> >> Тогда уж exec cat — ещё 20% выигрыша.
>
> AP> А можете подробнее рассказать? Я не в курсе, что с exec может быть
> быстрее.
>
Hello!
On Thursday 04 February 2010 15:20:45 Serhiy Storchaka wrote:
> Тогда уж exec cat — ещё 20% выигрыша.
А можете подробнее рассказать? Я не в курсе, что с exec может быть быстрее.
> От untex, unrtf и т.п. зависимость должна быть мягкой.
Это можно, поправлю.
> А кое где даже
> вариативной
Alexey Pechnikov wrote:
> On Thursday 04 February 2010 11:29:40 Serhiy Storchaka wrote:
>> Разве dash распространён за пределами Дебиана?
>
> Не могу сказать. Но запускается он вдвое быстрее, чем bash,
> и на обработке большого количества небольших документов
> выигрыш при использовании dash весьм
Hello!
On Thursday 04 February 2010 11:29:40 Serhiy Storchaka wrote:
> Разве dash распространён за пределами Дебиана?
Не могу сказать. Но запускается он вдвое быстрее, чем bash,
и на обработке большого количества небольших документов
выигрыш при использовании dash весьма заметен. Так что для
запу
Разве dash распространён за пределами Дебиана?
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Hello!
On Thursday 04 February 2010 01:44:58 Artem Chuprina wrote:
> Эээ... А ты не мог бы это описание по-русски написать? Я б тогда тебе
> его на английский перевел... А то... нет, по большей части можно
> догадаться, что ты имел в виду. Но смысл из этой грамматики приходится
> выковыривать.
Alexey Pechnikov -> debian-russian@lists.debian.org @ Wed, 3 Feb 2010 23:48:34
+0300:
AP> Ранее я уже упоминал, почему меня не устраивают существующие.
AP> Вот добрался сделать краткое описание своей разработки,
AP> используемой для некоторых коммерческих веб-проектов. Пакет
AP> содержит наб
Hello!
Ранее я уже упоминал, почему меня не устраивают существующие.
Вот добрался сделать краткое описание своей разработки,
используемой для некоторых коммерческих веб-проектов. Пакет
содержит набор из нескольких утилит, каждая из которых выполняет
определенную задачу. Все утилиты, кроме файловог
65 matches
Mail list logo
