Есть такой сабреддит — /r/nononoyes, где публикуют видео, в которых происходит что-то такое, что, на первый взгляд, кажется ужасно неправильным, идущим к катастрофе. Но в конце всё, чудесным образом, заканчивается хорошо.
В том сабреддите хорошо смотрелась бы команда [ -z $var ].
Если вы когда-нибудь пробовали воспользоваться в цикле чтения while командой ssh, или, точно так же, командами ffmpeg или mplayer, это значит, что вы сталкивались с неожиданным поведением такого цикла: он, после первой итерации, таинственным образом прекращал работать!
Решение этой проблемы, в случае с ssh, заключается в использовании конструкций ssh -n или ssh < /dev/null, на которые мгновенно «ругается» ShellCheck (тут можно посмотреть на результаты анализа кода с этими конструкциями). На этом можно было бы и остановиться, ведь проблема решена, но мы этого делать не будем. Лучше — детально разберём причины этой проблемы.
Читать полностью »
Рано или поздно очередной «исследователь» бюджетных альтернатив MS Exchange сталкивается с почтовым сервером из Германии – mailcow. Кто-то, не замечая, «проносится» мимо, кто-то, «притормаживая», знакомится ближе. Находятся и те, кто идёт дальше и разворачивает данное почтовое решение в своей ИТ-инфраструктуре. Например – я, который в середине 2020 года мигрируя с сервисов Google, внедрил «почтовую корову» у себя, разместив основную и резервную площадки на виртуальных вычислительных ресурсах географически разнесённых дата-центров RUVDS.
Читать полностью »
Сегодня хочу рассказать об одном случае из жизни, когда невинная ошибка при написании скрипта командной оболочки привела к удалению базы данных, используемой в продакшне. Расскажу я и о том, как ShellCheck (инструмент для линтинга и анализа скриптов, выходящий под лицензией GPLv3) мог бы обнаружить эту ошибку и предотвратил бы катастрофу. Да, сразу скажу, что я — автор ShellCheck.
Знали ли вы о том, что следующий bash-скрипт способен выполнять произвольный код, который предоставит ему пользователь в ответ на запрос скрипта о вводе данных?
Недавно я мимоходом отметил, что errno был, в целом, хорошим интерфейсом в Unix-системах до появления в них многопоточности. Кого-то подобное высказывание может удивить, поэтому сегодня предлагаю поговорить о сильных и слабых сторонах errno в традиционных Unix-окружениях, таких, как V7 Unix.
Сильной стороной errno является тот факт, что этот интерфейс представляет собой простейший механизм, способный возвращать несколько значений из системных вызовов C, в которых нет непосредственной поддержки возврата нескольких значений (особенно — в ранних вариантах C). Использование глобальной переменной для «возврата» второго значения — это практически идеал того, что можно сделать в обычном C, если только не планировать передачу из C-библиотеки указателя на каждый системный вызов и функцию, которые собираются возвращать значение errno (при таком подходе придётся, например, интенсивно пользоваться stdio). Постоянная передача подобного указателя приводит не только к ухудшению внешнего вида кода. Такой подход увеличивает объём кода, и, из-за использования дополнительного параметра, приводит к повышению нагрузки на стек (или на регистры).
Читать полностью »
В материале о том, что в наши дни find, как правило, не нуждается в xargs, я отметил, что в конструкции '-exec ... {} +' скобки ('{}') (для имён файлов, генерируемых find) должны находиться в конце команды. В комментарии к той публикации анонимный читатель сказал, что это неприменимо к -exec-версии, которая запускает отдельную команду для каждого имени файла. В результате можно поместить заменяемое имя файла в любом месте команды. Это, как оказалось, относится не только к GNU Find, являясь стандартной возможностью, и я полагаю, что этого даже требует Single Unix Specification (SUS) для find.
Сегодня я хочу рассказать о том, как командные оболочки zsh и fish обнаруживают пропущенные символы перевода строки и выделяют соответствующие места в выводе программ, делая это в условиях, когда модель программирования Unix не даёт им возможности исследовать то, что выводят программы.
Большинство командных оболочек, включая bash, ksh, dash и ash, выводят приглашение командной строки в той позиции, в которой остался курсор после завершения работы предыдущей команды.
То, что приглашение (почти) всегда выводится в известном всем месте, в самой левой колонке следующей строки, объясняется тем фактом, что Unix-программы единодушно сотрудничают в деле размещения курсора именно в этой позиции после завершения их работы.
Читать полностью »
На днях мне пришло сообщение от портала Госуслуги с предложением поучаствовать в тестировании дистанционного электронного голосования (ДЭГ). Стало интересно, начал гуглить и поисковик сразу же выдал ссылку на хабровскую статью «Обзор системы дистанционного электронного голосования ЦИК РФ». Ознакомился…и…после прочтения, испытал противоречивые чувства, которые вылились в эту статью, созданную на базе идеи, описанной мной еще в 2018 году на сайте change.org.
![О неоправданно хорошей работе [ -z $var ] - 1](https://www.pvsm.ru/images/2021/05/30/o-neopravdanno-horoshei-rabote-z-var.jpeg "О неоправданно хорошей работе [ -z $var ] - 1")
![В bash безобидная с виду конструкция [[ $var -eq 42 ]] умеет выполнять и произвольный код - 1](https://www.pvsm.ru/images/2021/05/15/v-bash-bezobidnaya-s-vidu-konstrukciya--var-eq-42-umeet-vypolnyat-i-proizvolnyi-kod.jpeg "В bash безобидная с виду конструкция [[ $var -eq 42 ]] умеет выполнять и произвольный код - 1")
