Простите, но ОТКУДА в моем примере дефисы? Вы же видите скрипт целиком? В нем в STRING задается с одним конкретным значением, в котором есть все необходимое для демонстрации, как работает конкретная команда.
Если входные данные подразумеваются неизменными, то просто напишите вместо этого всего скрипта echo "shell" — зачем же так сложно, как у вас, делать? Или всё-таки, сущность примера состоит в том, что входные данные можно варьировать без потери работоспособности?
К тому же, основные претензии были вот к этим двум командам:
// 1
runapplication --user=user --password=$PASSWORD
// 2
for file in *.txt; do name=`basename $file .txt`;mv $name{.txt,.lst}; done
Я вижу, что вы отредактировали статью и добавили кавычки.
О чём мы тогда спорим-то?
Прежде всего, в качестве примера отсутствующего квотирования я приводил совсем другой фрагмент кода. Но и этот не без недостатков:
команда echo может иметь параметры, поэтому если STRING начинается с дефиса — все может пойти не так, как задумывалось;
без кавычек в echo "$STRING" у вас любое количество идущих подряд пробелов станет одним пробелом.
Можете мне сколько угодно говорить, что это всё глупости и просто не нужно иметь на машине имен пользователей и файловых путей с пробелами, вот только не всегда входные данные приходят в корректном виде. Их надо фильтровать и вообще обращаться с ними трепетно.
Случится то, что он нажмет «any other key». Я не вижу тут никакой катастрофы — все предусмотрено.
Вы уверены, что "test - = n" на всякой машине (в том числе в FreeBSD, OpenSolaris, QNX) отработает именно так, как у вас? Некоторые варианты test вполне могут воспринять дефис как окончание списка флагов и выдать сообщение об ошибке. Я вам не найду конкретную версию системы, где на этот баг можно нарваться, но я не с потолка это взял, а подсмотрел в ./configure-скриптах. Что бы ни говорили про Autotools, но её авторы понимали в портируемости кода.
Поэтому в этом вопросе я останусь при своем мнении — примеры должны быть максимально просты, и доносить свою основную мысль, не отвлекаясь на дополнительные вещи, которые не касаются описываемого функционала.
Согласен: примеры должны быть просты и доносить основную мысль, но также приучать людей к тому, что такие вещи как квотирование переменных должны "соскальзывать с кончиков пальцев". По-большому счёту, с этих несчастных кавычек и начинается понимание шелл-скриптинга.
Простите, вы действительно сейчас взяли и раскритиковали вводный скриншот к статье?
Ну да, взял и раскритиковал. Вы же эту команду не специально в картинку спрятали, чтобы её было сложнее раскритиковать?
В реале я использую множество приемов, [..], что может попасть под NDA, поэтому я не мог копи-пастить и специально переписал и максимально упростил все примеры в статье.
Вы хотите сказать, что забесплатно переменные можно не квотировать?
Если от упрощения примеров они становятся более хрупкими и менее корректными — не надо так упрощать. Программировать на шелл-языках сложно — пожалуйста, не внушайте людям, что это легко.
Я же прямо и пишу «часто используют cut или даже awk, чтобы просто получить значение какого-то одного столбца.
Окей, какого-то одного, но не обязательно же последнего? Давайте вытащим средний элемент: в примере с cut нужно будет поменять одну цифру, с ${##} уже придётся извратиться.
Пользователь не может ввести --help, потому что в примере в статье мы используем REPLY — как результат от команды «read -n 1»
Да, с --help я недоглядел. Но пользователь всё ещё может ввести просто дефис.
Кстати, использование [[ ]] — это гораздо больше башизм, чем стандартный test, я стараюсь его избегать.
Каждый, конечно, волен сам выбирать свою судьбу, но, как мне кажется, лучше уж честный скрипт на Bash (которому бонусом доступны массивы, хеш-таблицы, $(...) и регулярные выражения) с минимальным использованием внешних утилит, чем "портабельный" скрипт на *sh, который на эту самую портабельность никем никогда не проверялся.
вы поймете, что не обязательно в КАЖДОМ примере, в котором вы хотите объяснить что-то одно, использовать всевозможные защиты от несуществующих в данном примере проблем
Нельзя по-отдельности объяснить составляющие концепции и ожидать, что они сами сольются в монолитное знание. В каждом примере обязательно нужно использовать всевозможные защиты от якобы несущественных проблем, либо говорить "Этот пример работает неправильно в таких-то случаях". В противном случае получается, что вы именно что "учите плохому".
К сожалению, местами ваша статья тоже учит людей плохому, как и многие другие статьи о шелл-программировании.
КДПВ. То, что там написано, не поддаётся никакой критике:
ls -d * | sort -r | tr "\n" " "; echo
Кто-то так в жизни пишет скрипты? А что если:
файлов слишком много и * раскрывается в слишком длинную последовательность, которая не поместится в лимит командной строки?
где-то в имени файла затесался перевод строки (как бы ужасно это ни звучало)?
Более правильно так:
# Если на вывод будет смотреть человек.
ls --reverse
# Если это зачем-то нужно сделать в скрипте.
find -maxdepth 1 ! -path . -print0 | sort -z -r | xargs -0 echo
Разбиение строки. Как быть в случае, когда нужны все поля, или какое-то поле из середины? В этом случае ${##} не поможет, но вполне можно разбить строку в массив средствами Bash:
userInfoString="username:homedir:shell"
IFS=':'
userInfo=($userInfoString)
echo "${userInfo[0]}"
echo "${userInfo[1]}"
echo "${userInfo[2]}"
# Восстановим дефолтное значение разделителя. По-хорошему,
# следовало бы сохранить старое значение IFS, а затем восстановить.
unset IFS
Последовательности. В приведённом простом примере совсем не обязательно использовать seq, достаточно добавить ведущих нулей в оператор {..}. Не стоит также забывать про кавычки, хотя тут их отсутствие не несёт угрозы.
# Было.
for srv in `seq -w 1 10`; do echo server${srv};done
# Стало.
for srv in {01..10}; do echo "server${srv}"; done
Кавычки!. Не знаю, почему, но вы почти нигде не квотируете строки. Как насчёт файлов с пробелами в имени?
# Было.
for file in *.txt; do name=`basename $file .txt`;mv $name{.txt,.lst}; done
# Стало.
for file in *.txt; do name="$(basename "$file" .txt)"; mv "$name"{.txt,.lst}; done
Коварная команда test. Увидел у вас вот такой фрагмент кода:
[ "$REPLY" = 'n' ]
Что будет, если пользователь введёт '--help' или ещё что-то, начинающееся с дефиса? В баше (по крайней мере, новых версиях) не произойдёт ничего страшного, но в древних шеллах команда test может перепутать операнд с опцией и выдать сообщение об ошибке. Думаю, лучше так:
# Если пишем на башике и на другие шеллы не смотрим.
# (Заодно можем опустить кавычки.)
[[ $REPLY == 'n' ]]
# Если хотим, чтобы работало как можно более везде, придётся сделать
# подношение древним богам портабельности.
[ x"$REPLY" = x'n' ]
Для этого надо владеть технологией скорочтения хотя-бы на уровне «строкацеликом» и в периферийном зрении. В этом случае субтитры совершенно не отвлекают от экрана.
(Курсив в цитате мой.)
Когда большинство сабов были в SRT, любил перенести строку субтитров повыше, где-то на уровень глаз персонажей. Картинку разглядывать это особенно не мешало, но текст читался субъективно быстрее. Сейчас SRT всё реже встречается.
На аппаратном уровне компьютерная память состоит из множества триггеров.
Оперативная память современного ПК или сервера не состоит из триггеров — это было бы безумно дорого при таких объёмах. Сегодня в оперативной памяти информацию хранят конденсаторы, заряд которых периодически восстанавливается контроллером памяти, а SRAM (то, что на транзиторах) используется лишь в случаях, когда требуется действительно высокое быстродействие (например, кэш-память).
Содержимое squash ничем принципиально не отличается от обычного коммита (кроме того, что этот squash-коммит обычно недостижим из именованных веток). В этой ситуации нужно было просмотреть вывод git reflog, найти там хеш нужного коммита и вернуть его содержимое в рабочую копию при помощи git checkout.
Дискового пространства, внезапно, жалко — если под диском понимать SSD, то оказывается, что оно достаточно дорогое и хотелось бы потратить его с большей пользой, чем держать очередную копию стандартной питоновской библиотеки вместе с pyc-файлами. К тому же, эти дубликаты засоряют дисковый кэш системы. По идее, нивелировать обе эти проблемы может ФС с поддержкой активной дедупликации, но покажите мне такую для винды? (В десктопных не-виндах ситуация не лучше.)
[...] его все-таки под разные платформы необходимо собирать, а с PyQt это может быть проще.
Так-то оно так, но перед тем как станет проще нужно, чтобы кто-нибудь добрый собрал под эти платформы PyQt.
Проблемы с пакетированием мне видятся вот в чём: представьте, что вы захотели сделать самодостаточное приложение. Чтобы конечному пользователю под виндами не мучиться со всеми этими зависимостями, придётся тащить с собой питон, все питоньи библиотеки и все необходимые для них бинарные либы, да ещё и настроить при запуске интерпретатор так, чтобы он эти либы находил. Весить будет мегабайт под сотню.
Вы спрашиваете почему писать на Python удобнее чем на C++?
Как по мне, ваше (неявное) предположение о большем удобство Python по сравнению со связкой C++11 + Qt5 требует детального обоснования. Особенно в задачах разработки десктопных программ с нетривиальным пользовательским интерфейсом.
Как будто это какая-то редкость. Для PyQt нужен интерпретатор Python со своей стандартной библиотекой, сам PyQt и, вдобавок, прекомпилированные бинарники Qt. Установить всё это может быть не так уж просто, особенно если в системе нет нормального пакетного менеджера. А если вы вдруг захотите самостоятельно пересобрать PyQt из исходников, вам точно понадобится и компилятор C++.
желательно приличная среда (Qt Сreator очень хорош)
Для питона тоже неплохо бы иметь хорошую среду с диагностиками и зачатками статического анализа (PyCharm?). Более того, как мне кажется, динамически типизированные языки предъявляют намного большие требования к качеству IDE: без них последствия банальной опечатки вы увидите уже после запуска программы.
и много времени на ожидание компиляции и отладку.
В Qt практически не используется высокооктановая шаблонная магия, зато широко применяется идиома PIMPL — это здорово ускоряет компиляцию. Времени на компиляцию столь простого приложения, как описывается в статье, потребуется немного.
Но зачем ждать, если Python запускается сразу, как язык он гораздо лаконичней C++
Для того, чтобы убрать два лишних звена (Python и PyQt) из технологического стека, получив в результате более отзывчивое приложение, потенциально более кроссплатформенное, с более простым процессом развёртывания и пакетирования.
а через PyQt можно пользоваться всей мощью Qt.
Через Qt можно делать то же самое. Как фреймворк Qt очень удобен: если приложение написано целиком на Qt, необходимости думать о низкоуровневых деталях практически не появляется.
И что самое вкусное — практически без потери производительности.
Ваше приложение пока что слишком простое, чтобы заметить разницу.
Следущие шаги в черной магии процессоростроения после того, как вы освоили Харрис & Харрис
ЕМНИП, в русском языке есть интересный момент касательно склонения мужских и женских имён собственных с нулевым окончанием. Думаю, правильнее было бы написать «Харриса & Харрис».
UPD: в статье JavaScript как мыслевирус pnovikov оскорбил всё сообщество JavaScript, назвав их фанатиками.
JavaScript пока не канонизирован православной церковью, чтобы так оскорбляться в ответ на вполне невинную статью, да ещё и не лишённую справедливости. Немного самоиронии не помешало ещё ни одному сообществу.
Как вы считаете, это этично?
Считаю, что вы этой припиской только подтвердили исходный тезис о мыслевирусе.
Сама эта тема оказалась настолько для меня интересной, что я потом даже диссертацию про это написал.
По ссылке ожидал увидеть PDF, но не 120-мегабайтный архив с чем-то, похожим на профиль браузера вместе с кешем. Это точно именно то, что вы имели в виду?
Поддержу.
Вместо android: можно выбрать префикс покороче (например, a:), либо вообще установить пространством имён по умолчанию (тогда префиксы не понадобятся):
Более того, ещё пару дней назад требований о визуалстудии и недопустимости использования сторонних библиотек в условии тестовой задачи не было, как и о том, что решение должно быть оформлено в виде единственного CPP-файла и проходить автоматическую проверку.
Было весьма неприятно узнать об этом, имея на руках готовое решение, сделанное с расчётом на оценивание человеком: с Boost.Coroutine и Boost.Range, разбиением функциональности на кучу классов, комментариями и coverletter на английском. Написал им на мыло — код смотреть даже не стали.
Я перестал отвечать на его тикеты. Иногда я удалял их (а если не мог, то нажимал «редактировать» и стирал весь текст). Иногда в негодовании спрашивал, кем он себя возомнил, когда приходит в трекер и требует от меня объяснений по тем аспектам моей библиотеки, с которыми он не согласен. В конце концов я забанил его на проекте.
Даже если человек открыто называет ваши архитектурные решения неправильными, это не повод так с ним себя вести. Кто-то потратил своё время, думая над тем, как сделать ваш проект лучше, не поленился зайти в трекер и написать об этом, а вы удаляете его сообщения. Даже если его предложения абсолютно и безкомпромисно противоречат вашему видению, так делать нельзя — вам следовало закрыть тикет с «wontfix» и оставить его в истории проекта. Лично я не увидел в предоставленной вами переписке абсолютно ничего такого, что могло бы оправдать ваш модераторский произвол.
«Из диода и картошки» было бы, действительно, честнее.
Однако, как по мне, главная ценность материала — в эксперименте: про схему с картофелиной многие если не знали, то где-то слышали (пусть на правах байки), а у автора оно и правда делает «пшш-пшш». :)
Если входные данные подразумеваются неизменными, то просто напишите вместо этого всего скрипта
echo "shell"— зачем же так сложно, как у вас, делать? Или всё-таки, сущность примера состоит в том, что входные данные можно варьировать без потери работоспособности?К тому же, основные претензии были вот к этим двум командам:
Я вижу, что вы отредактировали статью и добавили кавычки.
О чём мы тогда спорим-то?
Прежде всего, в качестве примера отсутствующего квотирования я приводил совсем другой фрагмент кода. Но и этот не без недостатков:
echoможет иметь параметры, поэтому еслиSTRINGначинается с дефиса — все может пойти не так, как задумывалось;echo "$STRING"у вас любое количество идущих подряд пробелов станет одним пробелом.Можете мне сколько угодно говорить, что это всё глупости и просто не нужно иметь на машине имен пользователей и файловых путей с пробелами, вот только не всегда входные данные приходят в корректном виде. Их надо фильтровать и вообще обращаться с ними трепетно.
Вы уверены, что "
test - = n" на всякой машине (в том числе в FreeBSD, OpenSolaris, QNX) отработает именно так, как у вас? Некоторые вариантыtestвполне могут воспринять дефис как окончание списка флагов и выдать сообщение об ошибке. Я вам не найду конкретную версию системы, где на этот баг можно нарваться, но я не с потолка это взял, а подсмотрел в./configure-скриптах. Что бы ни говорили про Autotools, но её авторы понимали в портируемости кода.Согласен: примеры должны быть просты и доносить основную мысль, но также приучать людей к тому, что такие вещи как квотирование переменных должны "соскальзывать с кончиков пальцев". По-большому счёту, с этих несчастных кавычек и начинается понимание шелл-скриптинга.
Ну да, взял и раскритиковал. Вы же эту команду не специально в картинку спрятали, чтобы её было сложнее раскритиковать?
Вы хотите сказать, что забесплатно переменные можно не квотировать?
Если от упрощения примеров они становятся более хрупкими и менее корректными — не надо так упрощать. Программировать на шелл-языках сложно — пожалуйста, не внушайте людям, что это легко.
Окей, какого-то одного, но не обязательно же последнего? Давайте вытащим средний элемент: в примере с
cutнужно будет поменять одну цифру, с${##}уже придётся извратиться.Да, с
--helpя недоглядел. Но пользователь всё ещё может ввести просто дефис.Каждый, конечно, волен сам выбирать свою судьбу, но, как мне кажется, лучше уж честный скрипт на Bash (которому бонусом доступны массивы, хеш-таблицы,
$(...)и регулярные выражения) с минимальным использованием внешних утилит, чем "портабельный" скрипт на *sh, который на эту самую портабельность никем никогда не проверялся.Нельзя по-отдельности объяснить составляющие концепции и ожидать, что они сами сольются в монолитное знание. В каждом примере обязательно нужно использовать всевозможные защиты от якобы несущественных проблем, либо говорить "Этот пример работает неправильно в таких-то случаях". В противном случае получается, что вы именно что "учите плохому".
К сожалению, местами ваша статья тоже учит людей плохому, как и многие другие статьи о шелл-программировании.
КДПВ. То, что там написано, не поддаётся никакой критике:
Кто-то так в жизни пишет скрипты? А что если:
*раскрывается в слишком длинную последовательность, которая не поместится в лимит командной строки?Более правильно так:
Разбиение строки. Как быть в случае, когда нужны все поля, или какое-то поле из середины? В этом случае
${##}не поможет, но вполне можно разбить строку в массив средствами Bash:Последовательности. В приведённом простом примере совсем не обязательно использовать
seq, достаточно добавить ведущих нулей в оператор{..}. Не стоит также забывать про кавычки, хотя тут их отсутствие не несёт угрозы.Кавычки!. Не знаю, почему, но вы почти нигде не квотируете строки. Как насчёт файлов с пробелами в имени?
Коварная команда
test. Увидел у вас вот такой фрагмент кода:Что будет, если пользователь введёт '--help' или ещё что-то, начинающееся с дефиса? В баше (по крайней мере, новых версиях) не произойдёт ничего страшного, но в древних шеллах команда test может перепутать операнд с опцией и выдать сообщение об ошибке. Думаю, лучше так:
(Курсив в цитате мой.)
Когда большинство сабов были в SRT, любил перенести строку субтитров повыше, где-то на уровень глаз персонажей. Картинку разглядывать это особенно не мешало, но текст читался субъективно быстрее. Сейчас SRT всё реже встречается.
Оперативная память современного ПК или сервера не состоит из триггеров — это было бы безумно дорого при таких объёмах. Сегодня в оперативной памяти информацию хранят конденсаторы, заряд которых периодически восстанавливается контроллером памяти, а SRAM (то, что на транзиторах) используется лишь в случаях, когда требуется действительно высокое быстродействие (например, кэш-память).
А нет, простите, это не настолько просто, но всё равно возможно.
Содержимое squash ничем принципиально не отличается от обычного коммита (кроме того, что этот squash-коммит обычно недостижим из именованных веток). В этой ситуации нужно было просмотреть вывод
git reflog, найти там хеш нужного коммита и вернуть его содержимое в рабочую копию при помощиgit checkout.Дискового пространства, внезапно, жалко — если под диском понимать SSD, то оказывается, что оно достаточно дорогое и хотелось бы потратить его с большей пользой, чем держать очередную копию стандартной питоновской библиотеки вместе с pyc-файлами. К тому же, эти дубликаты засоряют дисковый кэш системы. По идее, нивелировать обе эти проблемы может ФС с поддержкой активной дедупликации, но покажите мне такую для винды? (В десктопных не-виндах ситуация не лучше.)
Так-то оно так, но перед тем как станет проще нужно, чтобы кто-нибудь добрый собрал под эти платформы PyQt.
Проблемы с пакетированием мне видятся вот в чём: представьте, что вы захотели сделать самодостаточное приложение. Чтобы конечному пользователю под виндами не мучиться со всеми этими зависимостями, придётся тащить с собой питон, все питоньи библиотеки и все необходимые для них бинарные либы, да ещё и настроить при запуске интерпретатор так, чтобы он эти либы находил. Весить будет мегабайт под сотню.
Как по мне, ваше (неявное) предположение о большем удобство Python по сравнению со связкой C++11 + Qt5 требует детального обоснования. Особенно в задачах разработки десктопных программ с нетривиальным пользовательским интерфейсом.
Позвольте не согласиться с вашими тезисами.
Как будто это какая-то редкость. Для PyQt нужен интерпретатор Python со своей стандартной библиотекой, сам PyQt и, вдобавок, прекомпилированные бинарники Qt. Установить всё это может быть не так уж просто, особенно если в системе нет нормального пакетного менеджера. А если вы вдруг захотите самостоятельно пересобрать PyQt из исходников, вам точно понадобится и компилятор C++.
Для питона тоже неплохо бы иметь хорошую среду с диагностиками и зачатками статического анализа (PyCharm?). Более того, как мне кажется, динамически типизированные языки предъявляют намного большие требования к качеству IDE: без них последствия банальной опечатки вы увидите уже после запуска программы.
В Qt практически не используется высокооктановая шаблонная магия, зато широко применяется идиома PIMPL — это здорово ускоряет компиляцию. Времени на компиляцию столь простого приложения, как описывается в статье, потребуется немного.
Для того, чтобы убрать два лишних звена (Python и PyQt) из технологического стека, получив в результате более отзывчивое приложение, потенциально более кроссплатформенное, с более простым процессом развёртывания и пакетирования.
Через Qt можно делать то же самое. Как фреймворк Qt очень удобен: если приложение написано целиком на Qt, необходимости думать о низкоуровневых деталях практически не появляется.
Ваше приложение пока что слишком простое, чтобы заметить разницу.
ЕМНИП, в русском языке есть интересный момент касательно склонения мужских и женских имён собственных с нулевым окончанием. Думаю, правильнее было бы написать «Харриса & Харрис».
JavaScript пока не канонизирован православной церковью, чтобы так оскорбляться в ответ на вполне невинную статью, да ещё и не лишённую справедливости. Немного самоиронии не помешало ещё ни одному сообществу.
Считаю, что вы этой припиской только подтвердили исходный тезис о мыслевирусе.
По ссылке ожидал увидеть PDF, но не 120-мегабайтный архив с чем-то, похожим на профиль браузера вместе с кешем. Это точно именно то, что вы имели в виду?
Поддержу.
Вместо
android:можно выбрать префикс покороче (например,a:), либо вообще установить пространством имён по умолчанию (тогда префиксы не понадобятся):С точки зрения XML — разницы никакой. Проблему с выражениями это, конечно же, не решает.
Более того, ещё пару дней назад требований о визуалстудии и недопустимости использования сторонних библиотек в условии тестовой задачи не было, как и о том, что решение должно быть оформлено в виде единственного CPP-файла и проходить автоматическую проверку.
Было весьма неприятно узнать об этом, имея на руках готовое решение, сделанное с расчётом на оценивание человеком: с Boost.Coroutine и Boost.Range, разбиением функциональности на кучу классов, комментариями и coverletter на английском. Написал им на мыло — код смотреть даже не стали.
Простите, не заметил.
Даже если человек открыто называет ваши архитектурные решения неправильными, это не повод так с ним себя вести. Кто-то потратил своё время, думая над тем, как сделать ваш проект лучше, не поленился зайти в трекер и написать об этом, а вы удаляете его сообщения. Даже если его предложения абсолютно и безкомпромисно противоречат вашему видению, так делать нельзя — вам следовало закрыть тикет с «wontfix» и оставить его в истории проекта. Лично я не увидел в предоставленной вами переписке абсолютно ничего такого, что могло бы оправдать ваш модераторский произвол.
Однако, как по мне, главная ценность материала — в эксперименте: про схему с картофелиной многие если не знали, то где-то слышали (пусть на правах байки), а у автора оно и правда делает «пшш-пшш». :)