Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 48
главное все молчат:D
Хочется верить что это потому, что нет изьянов! :)
Ну-ну, изъянов нет :) Если уж постите код — то постите в хабровых тэгах
По ходу текста:
Вам абсолютно не нужен bash в этом скрипте — пишите лучше
Вот зачем здесь IFS и эти внешние скобочки? Вы точно понимаете, что они делают? Они делают вызов того, что внутри в subshell. При этом у этого subshell'а будет своя копия среды (причем «обычные» переменные туда не попадут, их надо будет экспортировать с помощью export, и все созданное в subshell'е там же и останется, можно делать всякие cd /куда/нибудь/далеко и по выходу из subshell это изменение исчезнет, т.к. текущая директория менялась только там). grep сам никогда ничего не делает со строкой, ничего он не разбивает и IFS он при всем желании увидеть вообще не может — это внутренняя переменная шелла, она никуда процессам не экспортируется. Если вы хотите просто поймать строчку, как она есть, правильнее поставить просто "", т.е. без всяких трюков с IFS:
Далее, с файлом:
Во-первых, вам его не нужно очищать. Единственное, что вы с ним делаете — перезаписываете wget'ом. Опция -o (--output-file) у wget'а перезаписывает лог-файл сама, в отличие от -a (--append-output). Во-вторых, даже если вы хотите очистить файл, это делается так:
Иначе вызов echo выдаст туда newline. В-третьих, если вы захотите выдать пустую строку, echo прекрасно работает и без всяких аргументов:
Далее, собственно, сам wget. Внезапно, вполне wget умеет *сам* проверять Last-Modified и скачивать файл, только если он обновился. Дату последнего обновления проще всего хранить прямо в самом скаченном файле в качестве timestamp. В итоге хитрая конструкция с дополнительным response.out и вырезаниями заголовков превращается в совершенно банальную:
После этого можно спокойно парсить содержимое файла rssdd.xml, не опасаясь создать лишнюю нагрузку скачиванием.
Сам парсинг гораздо проще сделать так:
Опция "-e" для grep в данном случае совершенно не нужна, а вот двойные кавычки не помешают. Сами выбирающие выражения вполне можно оформить без скобочек и такой тучи эскейпов при использовании egrep:
Технически, вообще правильнее эскейпить еще и все точки, заменяя на
В самой обработке потеряны двойные кавычки:
Если вдруг в link встретится пробел или, еще хуже, какая-нибудь конструкция вида $что-нибудь — это все будет интерпретировано совсем не так, как можно было бы подумать.
В строке с «cp» совершенно не обязательно писать
Кажется, я почти все строчки затронул? :)
<source lang="язык"></source>. Я верю, что у вас не все так плохо с форматированием :)По ходу текста:
#!/bin/bash
Вам абсолютно не нужен bash в этом скрипте — пишите лучше
#!/bin/sh -ef — это будет работать быстрее и предсказуемее, чем bash. Опция "-e" нужна для того, чтобы падать при ошибке, а не продолжать дальнейшее выполнение при явно порушенных состояниях и структурах данных. Опция "-f" нужна для того, чтобы не тратить время на глоббинг и не нарваться на то, что название файла со "*", "?" или "[]" внезапно поведет себя совсем не так, как вы думали.IFS="\n"
lastmod=( $( grep Last-Modified response.out ) )
unset IFS
Вот зачем здесь IFS и эти внешние скобочки? Вы точно понимаете, что они делают? Они делают вызов того, что внутри в subshell. При этом у этого subshell'а будет своя копия среды (причем «обычные» переменные туда не попадут, их надо будет экспортировать с помощью export, и все созданное в subshell'е там же и останется, можно делать всякие cd /куда/нибудь/далеко и по выходу из subshell это изменение исчезнет, т.к. текущая директория менялась только там). grep сам никогда ничего не делает со строкой, ничего он не разбивает и IFS он при всем желании увидеть вообще не может — это внутренняя переменная шелла, она никуда процессам не экспортируется. Если вы хотите просто поймать строчку, как она есть, правильнее поставить просто "", т.е. без всяких трюков с IFS:
lastmod="$(grep Last-Modified response.out)"
Далее, с файлом:
# Очистка файла для новой записи
echo "" > response.out
Во-первых, вам его не нужно очищать. Единственное, что вы с ним делаете — перезаписываете wget'ом. Опция -o (--output-file) у wget'а перезаписывает лог-файл сама, в отличие от -a (--append-output). Во-вторых, даже если вы хотите очистить файл, это делается так:
echo -n >response.out
Иначе вызов echo выдаст туда newline. В-третьих, если вы захотите выдать пустую строку, echo прекрасно работает и без всяких аргументов:
echo
Далее, собственно, сам wget. Внезапно, вполне wget умеет *сам* проверять Last-Modified и скачивать файл, только если он обновился. Дату последнего обновления проще всего хранить прямо в самом скаченном файле в качестве timestamp. В итоге хитрая конструкция с дополнительным response.out и вырезаниями заголовков превращается в совершенно банальную:
wget -N http://www.lostfilm.tv/rssdd.xml
После этого можно спокойно парсить содержимое файла rssdd.xml, не опасаясь создать лишнюю нагрузку скачиванием.
Сам парсинг гораздо проще сделать так:
cat ../rssdd.xml | grep -io 'http.*torrent' | egrep -i "$movies" | egrep "$quality" | while read link; do
# обрабатываем ссылку
done
Опция "-e" для grep в данном случае совершенно не нужна, а вот двойные кавычки не помешают. Сами выбирающие выражения вполне можно оформить без скобочек и такой тучи эскейпов при использовании egrep:
# Фильтр сериалов
movies='House.M.D|IT.Crowd|Persons.Unknown|Legend.of.the.Seeker|Leverage|Warehouse.13|Futurama'
# Фильтр качества
quality='\.720p\.\|\.HD\.\|Persons.Unknown|Legend.of.the.Seeker|IT.Crowd'
Технически, вообще правильнее эскейпить еще и все точки, заменяя на
\., но вы это и так знаете, судя по первым 2 значениям.В самой обработке потеряны двойные кавычки:
link=${link/&аmp;/&}
name=${link#*&}
Если вдруг в link встретится пробел или, еще хуже, какая-нибудь конструкция вида $что-нибудь — это все будет интерпретировано совсем не так, как можно было бы подумать.
В строке с «cp» совершенно не обязательно писать
./$name, гораздо лучше написать "$name" — а вообще, на практике, это такая довольно опасная операция, в зависимости от степени интерактивности скрипта уж лучше либо «cp -i» использоваться, либо сделать хоть какую-то обработку ошибок.Кажется, я почти все строчки затронул? :)
Вам абсолютно не нужен bash в этом скрипте — пишите лучше #!/bin/sh -ef — это будет работать быстрее и предсказуемее, чем bash.Почему будет работать быстрее? Разве в современных система sh не линк на bash?
Не всегда. В убунту, если ничего не поменялось, это линк на dash.
Зачастую нет. Во многих системах это ksh либо dash (в Debian и его derivatives).
В Debian и Ubuntu — /bin/sh — это dash.
На *BSD — там свой sh:
This version of sh was rewritten in 1989 under the BSD license after the
Bourne shell from AT&T System V Release 4 UNIX.
Даже там, где /bin/sh => /bin/bash, как правило, это запускает bash в режиме POSIX-совместимости, что делает его радикально более другим.
На *BSD — там свой sh:
This version of sh was rewritten in 1989 under the BSD license after the
Bourne shell from AT&T System V Release 4 UNIX.
Даже там, где /bin/sh => /bin/bash, как правило, это запускает bash в режиме POSIX-совместимости, что делает его радикально более другим.
cat ../rssdd.xml | grep -io 'http.*torrent'
grep 'http.*torrent' ../rssdd.xml</source.
>лучше #!/bin/sh -ef — это будет работать быстрее
Будьте добры результаты тестов.
Вы меня так заинтриговали, что наверно даже не усну сегодня, пока не узнаю на сколько наносекунд этот конкретный скрипт из 10 строчек выполнится быстрее под sh, чем под bash. А так хоть узнаю сколько наносекунд я смогу выиграть поменяв свои скрипты. Будет больше времени на семью и спорт… красота…
Будьте добры результаты тестов.
Вы меня так заинтриговали, что наверно даже не усну сегодня, пока не узнаю на сколько наносекунд этот конкретный скрипт из 10 строчек выполнится быстрее под sh, чем под bash. А так хоть узнаю сколько наносекунд я смогу выиграть поменяв свои скрипты. Будет больше времени на семью и спорт… красота…
Если вы серьезно и хотите бенчмарков — то, пожалуйста, первое, что находится в гугле по запросу «dash bash benchmark» показывает, что один и тот же скрипт выполняется в bash примерно в 2.3 раза медленнее, чем в dash:
На самом деле спор из разряда «писать на C или C++», в том случае, когда ничего из C++ объективно не нужно и использоваться не будет.
bash 10000 0m19.689s
dash 10000 0m8.577s
На самом деле спор из разряда «писать на C или C++», в том случае, когда ничего из C++ объективно не нужно и использоваться не будет.
Ну передёргивать, так на все деньги, что уж там. Первый тест по вашей ссылке:
bash 1 0m0.002s
dash 1 0m0.001s
Т.е. баш медленнее на 1000000 нс.
С учётом того, что использовать скрипт предполагается по крону (каждые 15 минут), а всё время по сути съест io wget'а и порождение грепов, то я бы подумал… мм… что… вы наверное космические корабли запускаете, раз считаете это за оптимизацию.
bash 1 0m0.002s
dash 1 0m0.001s
Т.е. баш медленнее на 1000000 нс.
С учётом того, что использовать скрипт предполагается по крону (каждые 15 минут), а всё время по сути съест io wget'а и порождение грепов, то я бы подумал… мм… что… вы наверное космические корабли запускаете, раз считаете это за оптимизацию.
пишите лучше #!/bin/sh -ef
Не совсем согласен. Синтакс различается в зависимости от интерпретатора. Например мой вариант обработки ссылок не сработает на dash (Ubuntu 10.10). Можно конечно изменить сам алгоритм обработки на более универсальный, например на предложенный Вами. Но такое обобщение может привести к непредсказуемым результатам на разных платформах!
Вот как раз POSIX shell — это сколько-нибудь гарантия того, что оно будет плюс-минус одинаково на разных платформах. А использование #!/bin/bash — гарантия того, что на *BSD и некоторых source-based Linux оно не будет работать вообще (хотя бы потому, что там это будет #!/usr/local/bin/bash), на некоторых Windows-реализациях тоже не будет, на стандартном Android — тоже не будет и т.д.
wget -N www.lostfilm.tv/rssdd.xml
cat ../rssdd.xml | grep -io 'http.*torrent' | egrep -i "$movies" | egrep "$quality" | while read link; do
# обрабатываем ссылку
done
В данном случае экономим на создании header, но при этом всегда парсим rssdd.xml.
В моём алгоритме обработка идёт почти на лету ( надо вместо массива сделать как Вы посоветовали «while read link», чем и займусь ) и только если лента обновилась. Но в любом случае мне было интересно читать Ваш отзыв, почерпнул много полезной информации!
В вашем случае вы, во-первых, не делаете массив. *Массивы* в bash действительно есть, но их надо объявлять через
Во-вторых, если очень хочется избежать парсинга файла, то можно делать довольно тривиальную вещь: до закачивания запоминать md5 файла, сравнивать с md5 после — если контрольная сумма изменилась, значит файл нужно парсить, т.е. что-то типа:
declare -a имя, и, по большому счету, они нужны совершенно не для таких задач.Во-вторых, если очень хочется избежать парсинга файла, то можно делать довольно тривиальную вещь: до закачивания запоминать md5 файла, сравнивать с md5 после — если контрольная сумма изменилась, значит файл нужно парсить, т.е. что-то типа:
LAST_MD5=$(md5sum rssdd.xml)
wget ...
if [ "$LAST_MD5" != "$(md5sum rssdd.xml)" ]; then
парсить файл
fi
После того как несколько недель в RSS лостфильма были битые ссылки, начал парсить главную, уже 2й месяц полет нормальный.
(Так как парсер сьедает &аmp;, буква а здесь и далее по тексту была заменена на русскую. При копировании заменить!)Парсер ничего не съедает. Пишите просто &amp;, это же HTML обычный.
после написания здесь статья о «щадящим режимомо» можно забыть, сервак ляжет от хабра эффекра
используйте xmllint для парсинга самого rss
>quality='\.720p\.|\.HD\.|Persons.Unknown|Legend.of.the.Seeker|IT.Crowd'
Прозреваю копипасту в этом месте. Автор хотел ограничиться первыми двумя значениями, но уснул на клавиатуре
Прозреваю копипасту в этом месте. Автор хотел ограничиться первыми двумя значениями, но уснул на клавиатуре
movies содержит список скачиваемых сериалов. Но на Лостфильме они обычно выходят в двух версиях качества, а я лично стараюсь качать все в высоком качестве. Значит нужен дополнительный фильтр — quality. Но не все сериалы выходили в 720p или HD, поэтому добавим их в конец фильтра что-бы они могли тоже пройти проверку на качество!
Парсить XML с помощью grep — то еще извращение. Что будет если элемент разнесет на 2 строки? Или наоборот не вставят перенос строки?
Попробуйте xmlstalet — шикарный инструмент для обработки XML и вытаскивания различных данных.
Попробуйте xmlstalet — шикарный инструмент для обработки XML и вытаскивания различных данных.
А можно пример итерации по ссылкам?
Там нет понятия «итерации», там XSLT + XPath. Для вытаскивания всех ссылок будет что-то типа:
У меня это выдает что-то типа:
xmlstarlet sel -T -t -m /rss/channel/item/link -c . -n rssdd.xmlУ меня это выдает что-то типа:
http://lostfilm.tv/download.php?id=3597&Sons.of.Anarchy.S03E06.HD.rus.LostFilm.TV.mkv.torrent http://lostfilm.tv/download.php?id=3596&Sons.of.Anarchy.S03E06.rus.LostFilm.TV.avi.torrent http://lostfilm.tv/download.php?id=3595&Eureka.s04e18.rus.720p.LostFilm.TV.mkv.torrent http://lostfilm.tv/download.php?id=3594&Eureka.s04e18.rus.LostFilm.TV.avi.torrent ...
Вот ведь — чуть выше написал про xmllint — никто не заметил. Этот вроде почаще встречается и работать с ним не сложнее — те же XPath
curl http://www.lostfilm.tv/rssdd.xml | xmllint --xpath '/rss/channel/item/link/text()' -xmlstarlet только %)
И у него есть ровно 2 проблемы:
1) его обычно нифига нигде не стоит %)
2) там, где он стоит — ни разу не угадаешь, как он называется; встречал «xml», «xmlstar», «xmlstarlet»
И у него есть ровно 2 проблемы:
1) его обычно нифига нигде не стоит %)
2) там, где он стоит — ни разу не угадаешь, как он называется; встречал «xml», «xmlstar», «xmlstarlet»
Точно. Опечатался :)
1) Зато много где есть в репозиториях — можно поставить руками.
2) Это не так критично, если не собираетесь распространять скрипт. Для себя всегда можно подправить.
1) Зато много где есть в репозиториях — можно поставить руками.
2) Это не так критично, если не собираетесь распространять скрипт. Для себя всегда можно подправить.
У него есть еще одна багофича — совершенно долбанутый синтаксис и перманентная необходимость знать, уметь писать и уметь отлаживать XSLT, причем не обычный XSLT, а набранный с помощью «облегченного» набора фигнюшек типа -c, -v, -m, -n и т.п. ;) Пример выше как бы демонстрирует.
Вообще, на самом деле как-то грустно даже, что нет какого-то простого инструмента, распространяемого вместе с той же libxml, скажем, который бы везде ставился и мог элементарные штуки делать типа «вытащить элемент(ы) по XPath из заданного XML», «добавить еще один элемент такого-то вида на к элементу, заданному таким-то XPath» и т.д.
Вообще, на самом деле как-то грустно даже, что нет какого-то простого инструмента, распространяемого вместе с той же libxml, скажем, который бы везде ставился и мог элементарные штуки делать типа «вытащить элемент(ы) по XPath из заданного XML», «добавить еще один элемент такого-то вида на к элементу, заданному таким-то XPath» и т.д.
Можно использовать классический вариант XSLT. Но я скажу честно, он очень избыточен — писать долго. На самом деле, если им регулярно пользоваться, то быстро привыкаешь. Я в свое время вытаскивал им инфу из тысяч небольших XML-файликов. Например, есть лог загрузки данных от поставщика информации. И вот нужно проследить как меняласля какой-то блок во времени. Такие задачи удобно решаются с помощью xmlstalet + grep + uniq + awk.
А потом такой синтексис становится совершенно нормальным.
На самом деле все очень просто:
sel — сделать select — выборку
-t — использовать шаблон по упрощенному синтаксису
-m — match — только те элементы, которые соответсвуют XPath
-c — copy — скопировать в вывод
-n — new line — новая строка
А потом такой синтексис становится совершенно нормальным.
На самом деле все очень просто:
sel — сделать select — выборку
-t — использовать шаблон по упрощенному синтаксису
-m — match — только те элементы, которые соответсвуют XPath
-c — copy — скопировать в вывод
-n — new line — новая строка
Да это всё как раз более-менее понятно, просто когда этим регулярно пользуешься — разумеется, помнишь — а когда раз в год… XPath еще реально запомнить и использовать, а вот всю эту тучу буковок — no way.
Действительно очень жалко, что нет адекватно простого xmlgrep / xmlsed, чтобы можно было делать что-нибудь типа «xmlgrep /a/b/c» и оно бы взяло их и выдало.
В оффтопике, который начинается на букву «P» и заканчивается на «L», есть конструкция xeval для этого…
Действительно очень жалко, что нет адекватно простого xmlgrep / xmlsed, чтобы можно было делать что-нибудь типа «xmlgrep /a/b/c» и оно бы взяло их и выдало.
В оффтопике, который начинается на букву «P» и заканчивается на «L», есть конструкция xeval для этого…
> что-нибудь типа «xmlgrep /a/b/c» и оно бы взяло их и выдало.
главный вопрос в том, что имеено оно должно выдать — ведь вы имеете дело с элементами, которые ближе к объектам, чем протым строкам.
Если взять самый простой случай — выбрать значения по критерию, то можно использовать xeval.
Кстати, его очень легко сделать самому:
$ cat ./xeval
Использование:
$ ./xeval /rss/channel/item/link rss.xml
можно даже фильтровать:
$ ./xeval "/rss/channel/item/link[contains(., 'Haven')]" r.xml
главный вопрос в том, что имеено оно должно выдать — ведь вы имеете дело с элементами, которые ближе к объектам, чем протым строкам.
Если взять самый простой случай — выбрать значения по критерию, то можно использовать xeval.
Кстати, его очень легко сделать самому:
$ cat ./xeval
#!/bin/sh
xmlstarlet sel -T -t -m "$1" -v . -n "$2"
Использование:
$ ./xeval /rss/channel/item/link rss.xml
http://lostfilm.tv/download.php?id=3597&Sons.of.Anarchy.S03E06.HD.rus.LostFilm.TV.mkv.torrent http://lostfilm.tv/download.php?id=3596&Sons.of.Anarchy.S03E06.rus.LostFilm.TV.avi.torrent… — здесь все остальное, что было выше
можно даже фильтровать:
$ ./xeval "/rss/channel/item/link[contains(., 'Haven')]" r.xml
http://lostfilm.tv/download.php?id=3589&Haven.s01e09.rus.720p.LostFilm.TV.mkv.torrent http://lostfilm.tv/download.php?id=3588&Haven.s01e09.rus.LostFilm.TV.avi.torrent http://lostfilm.tv/download.php?id=3583&Haven.s01e08.rus.720p.LostFilm.TV.mkv.torrent
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Парсер RSS на bash для Лостфильма: щадящий режим для RSS сервера, проверка скачанного