Админам, пишущим на bash..

[qkowlew]

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

Однажды отец Онуфрий опытный админ написал кусок кода, обходящий окрестности онежского дерево каталогов, и стал его применять везде где ни попадя:

SqTree(){
[ -z "${1}" ] && return
for i in *.html
 do
 [ -s "${i}" ] && (тут обработка строк файла, не важно какая)
 done
for i in *
 do
 [ -d "${i}" ] || continue
 cd "${i}"
 SqTree "${1}"
 cd ..
 done
}

Скажите, собратия по написанию скриптов на bash и многих других шеллах - чего не хватает конкретно в выделенной полужирным строке, и почему? :)

UPD 2017-02-01 15:53 : пока из 6 участвующих в о[б|]суждении обнаружил "самую интересную" ошибку только один (в ирц, не здесь). :)

UPD 2017-02-01 19:05 : чтобы избавить данный вопрос от претензии "почему не find" - та же самая "недостача" в такой же выделенной строке скрипта вида:

#!/bin/bash
# Show subdirectory listing
[ -z "$1" ] && return
[ -d "$1" ] || return
cd "$1"
ls
cd ..

Comments

[filin]

Там не только в выделенной строке не хватает.

А вот find неспортивно применить?

[qkowlew]

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

[filin]

Да. Два абзаца моего комментария - два разных утверждения, а не две части одного.

Строка "cd .." ничуть не менее чревата боком, чем cd без проверки успеха. И в ней проверка успеха не поможет.

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

[qkowlew]

таракан с .* да, присутствует в этом насмерть ужасном коде.
но он не зависит от выделенной полужирным строки. :)

[qkowlew]

Да, вспомнил "почему не find" ;-)

Вот у нас есть в ./1/3/3/abba.html ссылка на файл вида '../../img/55/3.jpg'

Мне ТОГДА показалось ПРОЩЕ найти-определить правильные URI к таким файлам для скачивания при обходе "с погружением в текущие каталоги", нежели разбором получающихся путей.

Те, кто скажут, что "wget прекрасно справляется" - никогда не теряли картинок, которые упомянуты только в OnMouseOver

[filin]

Понятно. Я тоже не сразу узнал про существование realpath.

wget, кстати, до сих пор с такими не справляется? Он со временем прогрессирует, и раньше у него не было --page-requisites, а теперь есть.

Впрочем, жабоскрипты он, конечно, не парсит... Если в OnMouseOver жабоскрипт, который меняет картинку, как хочет, то да, конечно.

[qkowlew]

wget не справляется с последовательностью вида

@import(../css/file.css)
И уже в ентом file.css - ОТНОСИТЕЛЬНЫЕ ссылки на картинки.
Внимание вопрос - относительные ссылки мерять относительно чего? :)

Не справляется с яваскриптами
Не справляется с src=download.php?id=flgkkfff если uri не заключён в кавычки.

Не понимает картинки без расширений, если они отдаются сервером с вот такого запроса с query при content-type графики, но не той, что на самом деле.

Не справляется с некоторыми редиректами (недавно вот смотрел на конструкцию "если превьюшка ещё не сгенерена - движок редиректит получившуюся 404 ошибку на скрипт генерации превьюшки" - лечит "обойти ровно два раза").


И т.п.

[filin]

Угу.

Ну, по первому надо смотреть в спецификацию CSS. Вообще, насколько я понимаю, относительно того CSS, из которого ссылки. Иначе оно работать не будет.

> Не понимает картинки без расширений, если они отдаются сервером с вот такого запроса с query при content-type графики, но не той, что на самом деле.

Ась? Итоговое расширение при convert-links не соответствует действительному, не соответствует указанному, не соответствует ни тому, ни другому, или картинка вообще не сохраняется?

Про остальное понятно. Ну, в общем, да, "если вы хотите, чтобы ваш динамический сайт можно было сохранять как статический, думать надо было раньше, и головой, а не наемным веб-дизайнером". А если хотите РИАЛЬНА динамический, то репозиторий и регулярный бэкап базы, да.

Это хорошо, что wget не оснастили противоестественным интеллектом.

[qkowlew]

"если вы хотите, чтобы ваш динамический сайт можно было сохранять как статический, думать надо было раньше, и головой, а не наемным веб-дизайнером"

Никто из владельцев сайтов ничего не хочет.

Все живут так, как будто их компы вечны, никакие пароли не проёбываются, домены вечны, интернет вечен, w3c не творит новых хитростей и не позволяет неожиданно всякие извращения, а гугль и Яндекс никогда никаких своих сервисов не закрывали, не продавали всяким хуям и не портили неожиданно какой-нибудь хитрожопой гадостью.

Потому если пытаешься сохранить когда-то благородный статический сайт с окончанием .narod.ru - в нём обнаруживается гора мутной хрени и какие-то совершенно угробищные искажения любимого HTML.

Потому если мне хочется решения задачи http://mirrorpg.arda.ru/ - этого класса для хотя бы десяти сайтов, приходится "роджать неестественный интеллект" после того, как облом с wget стал очевиден.

[vitus_wagner]

set -e
в начале скрипта помогает. А вообще код завершения команды cd не проверять бывает очень больно.

[qkowlew]

Всё верно.
Но тут прикол - что не так в САМОЙ КОМАНДЕ cd "${i}"

[vitus_wagner]

Неужели именно в самой? А не в вышележащей команде for?

Можно же написать for i in ./*; do

[filin]

Витус, можно, но так точно никто не пишет :)

[vitus_wagner]

Ну я по крайней мере так пишу в аргументе find. Привык уже, что пустой файлик с именем -rf где-то да существует, поэтому все пути в текущем поддереве должны начинаться с ./

[qkowlew]

именно в ней самой.

Ну чтобы избавить данный вопрос от претензии "почему не find" - та же самая недостача в такой же строке скрипта вида:

#!/bin/bash
# Show subdirectory listing
[ -z "$1" ] && return
[ -d "$1" ] || return
cd "$1"
ls
cd ..

[vitus_wagner]

Тогда претензия "почему не прочитать man ls и не сделать это одной командой ls "$1""?

Ну и вообще, кто пишет скрипты на баше, тот сам себе буратина. Если тебе не хватает стандартного sh, то надо уже нормальный скриптовывй язык брать. Ты ж вроде BSD-шник. Откуда у тебя bash в /bin?

[qkowlew]

Тогда претензия "почему не прочитать man ls и не сделать это одной командой ls "$1""?

Хотя бы потому, что эта проблема точно так же вылазит и в ls "$1"

Так как Кир Злобин (в ЖЖ) уже озвучил суть, демонстрируем:

ns$ mkdir -- -x
ns$ ls "-x"
листинг текущего каталога, а не каталога -x/
ns$ mkdir -- -l
ns$ ls "-l"
листинг текущего каталога в -l виде.
ns$

с командами mv cp rm mkdir rmdir ессно всё это тоже заметно...

Если тебе не хватает стандартного sh
Это просто набор скриптов, который как тот поросёночек - рос-рос... из ~шести строк тривиального запуска wget'a... И дорос до того, чо умные люди называют "рефакторинг". :(

Откуда у тебя bash в /bin?

А почему ты решил, что проблема только во FreeBSD?
Вышеприведённый пример исполнялся в CentOS, а напоролся я в дебиане.
И разницы в поведении bash'ей по этому пункту пока не увидел.

[vitus_wagner]

Ку, на табличке твоим же собственным голосом написано "Ты невнимателен"
Я тебе еще сколько комментариев назад предложил заменить * в for на ./*
Это решает все проблемы с именами файлов, начинающимися с минусов. И решает их на этапе генерации списка имен, а не на этапе его использования.

Человек, имеющий дело с FreeBSD, по крайней мере знает, что на свете бывает настоящий sh, который не баш.
В отличие от человека, который никаких POSIX-систем кроме GNU не видал, а GNU, как известно is not Unix.
FreeBSD в общем-то тоже is not Unix, поскольку там весть закопирайченный код AT&T давным-давно переписали,
но она хотя бы похожа. Более того, если мне не изменяет память, ты же сам с месяц назад в какой-то дискуссии утверждал что не надо полагаться на наличие в системе bash, а то вдруг /usr/local не смонтировался корректно, и надо залогиниться, чтобы это исправить.

Но вообще я специально держал виртуалку с solaris, чтобы тестировать кое-какие вещи в настоящем Unix, который на базе system V-вской codebase. Сейчас у меня все равно настоящий спарк под рукой есть, поскольку тестировать сишный код на big-endian со strict-alignment тоже крайне полезно.

Мое мнение (кстати, практически выстраданное, и много кем разделяемое) - шелловские скрипты надо писать на /bin/sh.
И его же в шебанг прописывать. И как только тебе неудержимо захотелось упоребить в скрипте башизм, это повод переписать его c shell на perl или python. bash - только для интерактивной работы. По поводу zsh у тех, кто его активно используют может быть другое мнение. Там вроде немножко поаккуратнее это сделано.

[qkowlew]

Я тебе еще сколько комментариев назад предложил заменить * в for на ./*

О том и речь, что этого самого for может и не оказаться! А каталог с минусом попасться.

bash - только для интерактивной работы

Интерактивной, да!

Так в том и дело, что "в этой истории началось всё с одной команды в интерактиве". То есть с wget -m, очередной попытки отзеркалить очередной сайт. Потом - поднимаемый из хистори for и длиннейший регексп на перле. И вот "пока я в интерактиве с удобственнейшим башем" - тут то и врастает в меня-погромизда набор неправильных шаблонов, часть из которых - именно "башизмы", а часть - "порождение всего пространства шеллов", для меня то начиная с command.com MSDOS 3.30 аж, а не то что POSIX!

Поэтому прикол в данном случае получился не чисто технический (хотя башизм в конкретной ситуации и есть), а больше психологический.

[dmarck]

for не может не оказаться, for -- это shell builtin!

[qkowlew]

Да, именно что может и не быть.
Но вот привык к башу.
Как когда-то к command.com, хехе

[dmarck]

не-не. for является непременно реализованной функцией любого korn-style POSIX шелла.

А chdir (cd) -- единственная функция, которая не может быть реализованной как внешний бинарник -- потому что внешний бинарник не может поменять working directory вызывающему. ;-P

[filin]

Ты имел в виду ./?

Так сразу и говори: "в этом коде проблемы через строку, но я хочу, чтобы вы угадали некоторую конкретную именно в этой строке. Да, я знаю, что и в ней их тоже больше одной."

Или ты не знаешь, что в этой строке больше одной проблемы типа "не хватает"?

[qkowlew]

Нет, я вполне буду рад перечислению ВСЕХ проблем.
Забавно то, что пока - перечислили НЕ ВСЕ.
Даже для этой одной строки - НЕ ВСЕ.

[filin]

Четвертая проблема мне пока в голову не приходит. Но я еще попробую на свежую голову...