Ориентировочное время выполнения — 1,5 — 2 часа.
Вам необходимо создать докер образ для проведения соревнования типа CTF(https://en.wikipedia.org/wiki/Capture_the_flag) на тему IPC в системах UNIX. Образ должен содержать в себе приложение(-я) реализующие следующие задания:
1) Серверное приложение, слушает UDP порт 7777 и при любом запросе выдает ФЛАГ №1 и текстовую информацию где искать второй флаг (shmkey).
2) Приложение использует IPC Shared memory и записывает по адресу shmkey ФЛАГ №2 и инструкции по поиску флага №3.
3) Приложение использует IPC Signals, при поступлении сигнала SIGUSR2 выдает ФЛАГ3.
Результатом выполнения тестового задания является Docker/docker-compose файл и образ с проброшеным 7777 портом + исходные коды задач.
Можете использовать любой язык программирования.
Это похоже на техзадание? Спецификацию? Объяснение на пальцах? Нет, это похоже на поток сознания.
Серверное приложение, слушает UDP порт 7777 и при любом запросе выдает ФЛАГ №1 и текстовую информацию где искать второй флаг (shmkey).
Что значит «приложение выдаёт ФЛАГ №1»? Что за сущность такая, «ФЛАГ №1»? В каком формате приложение выдаёт его клиенту? Как вообще в CTF может быть более одного флага? Что за «текстовая информация, где искать второй флаг»? Каким образом удалённый клиент найдёт «shmkey», если он находится в разделяемой памяти?
Я тут посмотрел в википедии — этот порт биндится неким «Unreal Tournament series default server». Соискателю предлагается реализовать серверный протокол UT?
Приложение использует IPC Shared memory и записывает по адресу shmkey ФЛАГ №2 и инструкции по поиску флага №3.
Речь идёт о сервере, или нужно написать отдельное приложение? Что за безграмотная формулировка «IPC Shared memory»? Что такое «ФЛАГ №2» и чем он отличается от флага №1? Какое отношение ко всему этому имеет клиент, подключившийся по UDP? Какие «инструкции по поиску флага»? Что вообще значит, «найти флаг»?
Приложение использует IPC Signals, при поступлении сигнала SIGUSR2 выдает ФЛАГ3.
Ещё одна безграмотная формулировка «IPC Signals», написали бы хотя бы «POSIX signals», раз простое слово «сигналы» недостаточно профессионально выглядит. Как именно удалённый клиент должен отправить на сервер SIGUSR2? Куда приложение должно «выдать» флаг 3 — в логи, stdout/stderr, отправить кому-то (кому?) по сети?
UEFI Boot manager прекрасно запускает EFISTUB linux kernel.
Прекрасно запускает с LVM-тома?
Статья из разряда: придумать себе проблему и пытаться решить ее.
Нет, статья из разрядов «железка будет делать так, как я хочу, а не так, как ей удобно» и «кажется, теперь действительно пора лечиться от перфекционизма». С точки зрения автора, MBR (или GPT) — лишняя абстракция, не нужная для его целей, поэтому он её исключил. Благо ядро Linux не имеет ничего против.
Будущим разработчикам мы отправляли следующее тестовое задание
Вы всегда даёте тестовое задание в такой запутанной формулировке, что даже после третьего прочтения непонятно, что именно оно требует сделать? Я работал со всеми задействованными в описании технологиями, но его смысл и логика от меня ускользают.
Согласен с первым комментатором, что отдавать весь диск под LVM может быть опасно. Если есть хотя бы небольшой шанс случайного подключения этого диска к Windows-компьютеру неквалифицированным пользователем — лучше не надо, от данных могут остаться только оправдания «Да он же пустой был!». (Думаю, это одна из причин, почему GPT-разметка диска имитирует наличие MBR.)
Но минуточку, для системных администраторов, где уже все давно виртуализировано, это обычно нонсенс. Нужно просто загружать систему с минимальной болью.
Ну так загрузите Grub по сети. В этой ситуации отдельный загрузчик на диске просто не нужен — можно хоть LVM, хоть LVM поверх LUKS, хоть Btrfs.
А ведь паренёк молодец, нашёл решение. Но зачем же писать его на линуксе?
Почему некто, решая вставшую перед ним проблему, должен сделать так, как удобнее вам, а не ему? Лично я вижу сильно более, чем одну причину ориентировать продукт в первую очередь на Linux-системы:
это что-то серверное (потому что серверы часто работают на Linux);
это что-то научно-вычислительное (потому что суперкомпьютеры часто работают на Linux);
это что-то для встраиваемых систем (потому что там часто ставят Linux).
В итоге ни на одной другой системе его не запустить, переписывать библиотеку — слишком затратно.
Насколько я могу судить по своему опыту, в Linux-сообществе принято при любой возможности использовать кросслатформенные технологии: языки, фреймворки и библиотеки, следовать отраслевым стандартам. Куча Linux-софта имеет готовые сборки для Windows (а часто и для OS X, FreeBSD и «прочих хайку»), потому что разработчики с самого начала понимали, что их любимая ОС не единственная в мире. Распространён ли этот подход в мире Windows? Вы лично готовы отказаться от WinAPI, DirectX, WPF, UWP (или что там теперь модно?) в пользу POSIX, OpenGL и Qt/Gtk ради хайку-пользователей? Или ваша «чёткая позиция без внутренних противоречий» направлена лишь на обеспечение вашего личного комфорта?
Кстати, многие «серьёзные» вендоры, оказывается, вполне готовы идти навстречу пользователям не-Windows: у Altera и Xilinx есть официальные версии их сред разработки для Linux (они работают, хотя иной раз и не без проблем), а также у Synopsis — несмотря на то, что их софт стоит на пару порядков дороже лицензии Windows.
Если бы все сконцентрировали усилия на одной платформе, а не распылялись бы на линукс и прочие хайку, и чего там ещё — мы могли бы достичь большего.
Нечто подобное сейчас и происходит, только усилия концентрируются не не той системе, к которой вы привыкли. Или вы правда хотите видеть все десктопы, серверы, вычислительные кластеры и смартфоны мира намертво связанными гигантским vendor lock-in'ом?
Ещё вопрос возник: если я вдруг захочу генерировать числа точности выше двойной (например, такие, как в boost::multiprecision), ваша библиотека справится? А то я посмотрел исходники класса NormalRand, а там везде double захардкожен. И если такая возможность есть, просто я проглядел, не пострадают ли при этом статистические характеристики распределений?
Я не специалист в матстатистике, но если бы мне понадобилась подобная библиотека для чего-то серьёзного, то первым делом я бы поинтересовался качеством полученных распределений. Они какие-нибудь тесты на случайность проходят? Всякие NIST и Die Hard там.
И ещё: в C++17 точно никак нельзя было обойтись без макросов? Вы бы их хотя бы префиксом RANDLIB_ снабдили, а всё остальное запихнули в неймспейс.
Можно попробовать запускать их как chromium --disable-extensions(источник) и firefox --safe-mode(источник), но я не обещаю, что это сработает. Ещё можно посмотреть, нет ли возможности выключить ненавистные расширения на этапе компиляции и сделать свой билд.
Простите, но ОТКУДА в моем примере дефисы? Вы же видите скрипт целиком? В нем в 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 требует детального обоснования. Особенно в задачах разработки десктопных программ с нетривиальным пользовательским интерфейсом.
Не может, а признает: договор стажировка и есть срочный трудовой договор. Какие ещё могут быть варианты-то?
Я имел в виду вот этот опус:
Ориентировочное время выполнения — 1,5 — 2 часа.
Вам необходимо создать докер образ для проведения соревнования типа CTF(https://en.wikipedia.org/wiki/Capture_the_flag) на тему IPC в системах UNIX. Образ должен содержать в себе приложение(-я) реализующие следующие задания:
1) Серверное приложение, слушает UDP порт 7777 и при любом запросе выдает ФЛАГ №1 и текстовую информацию где искать второй флаг (shmkey).
2) Приложение использует IPC Shared memory и записывает по адресу shmkey ФЛАГ №2 и инструкции по поиску флага №3.
3) Приложение использует IPC Signals, при поступлении сигнала SIGUSR2 выдает ФЛАГ3.
Результатом выполнения тестового задания является Docker/docker-compose файл и образ с проброшеным 7777 портом + исходные коды задач.
Можете использовать любой язык программирования.
Это похоже на техзадание? Спецификацию? Объяснение на пальцах? Нет, это похоже на поток сознания.
Что значит «приложение выдаёт ФЛАГ №1»? Что за сущность такая, «ФЛАГ №1»? В каком формате приложение выдаёт его клиенту? Как вообще в CTF может быть более одного флага? Что за «текстовая информация, где искать второй флаг»? Каким образом удалённый клиент найдёт «shmkey», если он находится в разделяемой памяти?
Я тут посмотрел в википедии — этот порт биндится неким «Unreal Tournament series default server». Соискателю предлагается реализовать серверный протокол UT?
Речь идёт о сервере, или нужно написать отдельное приложение? Что за безграмотная формулировка «IPC Shared memory»? Что такое «ФЛАГ №2» и чем он отличается от флага №1? Какое отношение ко всему этому имеет клиент, подключившийся по UDP? Какие «инструкции по поиску флага»? Что вообще значит, «найти флаг»?
Ещё одна безграмотная формулировка «IPC Signals», написали бы хотя бы «POSIX signals», раз простое слово «сигналы» недостаточно профессионально выглядит. Как именно удалённый клиент должен отправить на сервер SIGUSR2? Куда приложение должно «выдать» флаг 3 — в логи, stdout/stderr, отправить кому-то (кому?) по сети?
Что вообще за кафкианский бред?
Прекрасно запускает с LVM-тома?
Нет, статья из разрядов «железка будет делать так, как я хочу, а не так, как ей удобно» и «кажется, теперь действительно пора лечиться от перфекционизма». С точки зрения автора, MBR (или GPT) — лишняя абстракция, не нужная для его целей, поэтому он её исключил. Благо ядро Linux не имеет ничего против.
Вы всегда даёте тестовое задание в такой запутанной формулировке, что даже после третьего прочтения непонятно, что именно оно требует сделать? Я работал со всеми задействованными в описании технологиями, но его смысл и логика от меня ускользают.
Согласен с первым комментатором, что отдавать весь диск под LVM может быть опасно. Если есть хотя бы небольшой шанс случайного подключения этого диска к Windows-компьютеру неквалифицированным пользователем — лучше не надо, от данных могут остаться только оправдания «Да он же пустой был!». (Думаю, это одна из причин, почему GPT-разметка диска имитирует наличие MBR.)
Ну так загрузите Grub по сети. В этой ситуации отдельный загрузчик на диске просто не нужен — можно хоть LVM, хоть LVM поверх LUKS, хоть Btrfs.
Почему некто, решая вставшую перед ним проблему, должен сделать так, как удобнее вам, а не ему? Лично я вижу сильно более, чем одну причину ориентировать продукт в первую очередь на Linux-системы:
Насколько я могу судить по своему опыту, в Linux-сообществе принято при любой возможности использовать кросслатформенные технологии: языки, фреймворки и библиотеки, следовать отраслевым стандартам. Куча Linux-софта имеет готовые сборки для Windows (а часто и для OS X, FreeBSD и «прочих хайку»), потому что разработчики с самого начала понимали, что их любимая ОС не единственная в мире. Распространён ли этот подход в мире Windows? Вы лично готовы отказаться от WinAPI, DirectX, WPF, UWP (или что там теперь модно?) в пользу POSIX, OpenGL и Qt/Gtk ради хайку-пользователей? Или ваша «чёткая позиция без внутренних противоречий» направлена лишь на обеспечение вашего личного комфорта?
Кстати, многие «серьёзные» вендоры, оказывается, вполне готовы идти навстречу пользователям не-Windows: у Altera и Xilinx есть официальные версии их сред разработки для Linux (они работают, хотя иной раз и не без проблем), а также у Synopsis — несмотря на то, что их софт стоит на пару порядков дороже лицензии Windows.
Нечто подобное сейчас и происходит, только усилия концентрируются не не той системе, к которой вы привыкли. Или вы правда хотите видеть все десктопы, серверы, вычислительные кластеры и смартфоны мира намертво связанными гигантским vendor lock-in'ом?
Ещё вопрос возник: если я вдруг захочу генерировать числа точности выше двойной (например, такие, как в
boost::multiprecision), ваша библиотека справится? А то я посмотрел исходники классаNormalRand, а там вездеdoubleзахардкожен. И если такая возможность есть, просто я проглядел, не пострадают ли при этом статистические характеристики распределений?Я не специалист в матстатистике, но если бы мне понадобилась подобная библиотека для чего-то серьёзного, то первым делом я бы поинтересовался качеством полученных распределений. Они какие-нибудь тесты на случайность проходят? Всякие NIST и Die Hard там.
И ещё: в C++17 точно никак нельзя было обойтись без макросов? Вы бы их хотя бы префиксом
RANDLIB_снабдили, а всё остальное запихнули в неймспейс.Можно попробовать запускать их как
chromium --disable-extensions(источник) иfirefox --safe-mode(источник), но я не обещаю, что это сработает. Ещё можно посмотреть, нет ли возможности выключить ненавистные расширения на этапе компиляции и сделать свой билд.Если входные данные подразумеваются неизменными, то просто напишите вместо этого всего скрипта
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 требует детального обоснования. Особенно в задачах разработки десктопных программ с нетривиальным пользовательским интерфейсом.