Comments 41
У «bash и ко» есть интересное достоинство, про которое почему-то все забывают — процессы, связанные через pipe, могут прекрасно утилизировать все ядра. Никакой gil этому не помешает.
Шелловские скрипты становятся очень хрупкими при работе с именами файлов, которые могут содержать пробелы...
Избегаю скриптов на баше кроме разве что совсем простых на пару строк) из-за его, bash-a, синтаксиса. Простите за сквернословие, но назвать его могу только ублюдским.
Массивы, присваивание где нельзя ставить пробел между переменной и равно, все эти ne le ge , циклы - как будто против человечества всё это писалось. Понимаю, что наследие, традиции, ограничения, но прямо раздражает :)
да эт просто непривычно...это как поменять место расположения выключателя...ты привык что он в этом месте и щупаешь по привычке в темноте по стене, а он в другом месте (и как это не странно в более удобном), а потом когда привыкнешь кажется, ну ведь тут же удобнее здесь
Можно привыкнуть к тому, что чтобы воспользоваться выключателем, тебе надо присесть (потому что он на высоте 20 см от пола), и одновременно присвистнуть и у него два положения: возможно свет и возможно нет но я не гарантирую.
Но зачем к такому привыкать?)
le ge.. при чём тут баш? :D
rbro /home/mocksoul # ls -la /bin/\[
.rwxr-xr-x root 2024-10-07 08:31:09 34K -- /bin/[
rbro /home/mocksoul # /bin/\[ --help | head -n30
Usage: test EXPRESSION
or: test
or: [ EXPRESSION ]
or: [ ]
or: [ OPTION
Exit with the status determined by EXPRESSION.
--help display this help and exit
--version output version information and exit
An omitted EXPRESSION defaults to false. Otherwise,
EXPRESSION is true or false and sets exit status. It is one of:
( EXPRESSION ) EXPRESSION is true
! EXPRESSION EXPRESSION is false
EXPRESSION1 -a EXPRESSION2 both EXPRESSION1 and EXPRESSION2 are true
EXPRESSION1 -o EXPRESSION2 either EXPRESSION1 or EXPRESSION2 is true
-n STRING the length of STRING is nonzero
STRING equivalent to -n STRING
-z STRING the length of STRING is zero
STRING1 = STRING2 the strings are equal
STRING1 != STRING2 the strings are not equal
INTEGER1 -eq INTEGER2 INTEGER1 is equal to INTEGER2
INTEGER1 -ge INTEGER2 INTEGER1 is greater than or equal to INTEGER2
INTEGER1 -gt INTEGER2 INTEGER1 is greater than INTEGER2
INTEGER1 -le INTEGER2 INTEGER1 is less than or equal to INTEGER2
INTEGER1 -lt INTEGER2 INTEGER1 is less than INTEGER2
INTEGER1 -ne INTEGER2 INTEGER1 is not equal to INTEGER2
Да, сейчас уже в bash что [ что [[ выполняются внутри, без вызова /bin/[, но никто не мешает сделать /bin/[ 0 -eq 0 ] && echo 1 или что-то подобное.
Это я всё к тому, что это в оригинале был просто вызов программы, хоть и со специфичным именем, но всё же программы с классическими POSIX аргументами. Вот и всё. У всего этого богатая история, но никто не запрещает использовать "новодел", а-ля (( 0 == 0 )) && echo 1.
Не очень корректное сравнение. Python никак не мешает использовать сложные командные строки. Поэтому Python является скорее надстройкой над bash, чем альтернативой.
У Python есть один явный минус в сравнении с bash - это виртуальное окружение. Далеко не все скрипты можно "вот так взять и просто написать" без использования сторонних библиотек, а для этого нужно создавать виртуальное окружение, прописывать полный путь к интерпретатору в этом окружении... То есть речи о переносимости "из коробки" тут быть не может.
Часть библиотек есть в репозиториях ОС, иногда проще ставить их, чем возиться с виртуальными окружениями. Понятно, что не всё есть и версии старее, но иногда этого достаточно.
нет, дорогой друг, ставить какой-то пакет питона в "стандартное" окружение ОС - это путь в никуда, если вы собираетесь прожить с этой системой хоть пару лет (со всеми обновлениями безопасности и т.д,) Никогда! Повторю, НИКОГДА, не нужно ставить какие-то пакеты в окружение python вашего дистрибутива. Нет, я не выпендриваюсь, честно, просто это - опыт.
P.S. python - мой рабочий инструмент более 10 лет, я его искренне люблю и лелею, но нет - для задач переносимой автоматизации он подходит едва ли...
Какие-то пояснения будут, почему?
Расскажите это ансиблу и солту :)
Вообще стандартных библиотек Python должно быть достаточно для большинства задач по автоматизации а также есть возможность менять PYTHONPATH если нужны дополнительные модули.
Хотя с точки зрения использования shell, конкурент bash это не Python, а Ruby. Вот там краткость уровня bash и мощь полноценного языка программирования.
Были попытки внедрить ruby shell, однако видимо никому админам это не нужно.
В чем проблема при установки утилиты создать окружение, указывать до него относительный путь, добавлять symlinks и прочее?
ну тут go больше python уже подойдет, чтобы меньше телодвижений было. Дело, конечно, каждого, как извращаться. Как говорится "можно и зайца научить курить, но нафига?". Так и тут: bash - понятный POSIX инструмент, здесть P (Portable) является ключевым. Для каждой задачи должен подходить свой инструмент. Если задача требует программирования, то надо смотреть на накладные расходы. Никогда нет супер правильного решения - есть только компромиссы, с которыми мы готовы мириться
Если задачу можно решить на голом баше, то на питоне без сторонних библиотек тем более можно.
можно придумать такие кейсы. Например: считать информацию о загрузке процессора (CPU load) для каждого пользователя из /proc/loadavg и отсортировать их по убыванию средней нагрузки за последние 15 минут.
для меня в python видится использование библиотеки psutil (не входит в стандартную бибиотеку), а в bash это `awk '{for(i=1;i<=NF-2;i++) print $i}' /proc/loadavg | sort -nr`
Так вам и в питоне никто не мешает так же написать:
os.system("awk '{for(i=1;i<=NF-2;i++) print $i}' /proc/loadavg | sort -nr")
Bash — командная оболочка (UNIX, GNU/Linux, MacOS).
Python — высокоуровневый язык программирования.
Сравнение кажется мне не особо корректным. Разным задачам — разные инструменты.
P.S. Но заголовки в стиле "versus" нравятся, хоть и маркетинг.
P.P.S. «Bash vs Golang» # ?
А если предположить, что вы работаете с автоматизацией в Linux, и у вас из инструментов как раз bash и python? И задачи как раз не сверхсложные, но далеко не всегда простые. Спасибо, на парсить YAML/JSON на bash я желанием не горю, да и в некоторых местах без Python никуда (например, модули к системам автоматизации)
Спасибо за комментарий! Если рассматривать с подобной стороны - определенно факт. Я же хотел сравнить использование под те или иные задачи на Linux. Фактически, все задачи можно решить на одном bash, не городить окружения и тд, но ведь с точки зрения удобства подходы будут отличаться.
Согласен с предыдущем коментарием.
ПыСы
уже было на хабре
по всей видимости эффект от чатаЖПТ и иже с ними + "эффект ваАйТишников" уже провел к тому, что появилось много людей, не видящих абсурдности тем, подобных теме этой статьи.
Спасибо за комментарий!
уже было на Хабр
Попробуйте найти через поисковик статьи, например, «о пользе высшего в IT». Вы будете крайне удивлены их количеству. Это касается в целом большинства тем.
по всей видимости эффект от чатаЖПТ и иже с ними + "эффект ваАйТишников"
Раскройте понятия, пожалуйста. Не понимаю, что за «эффекты».
Сравнение Питона и Баша абсурдно по своей идее. Грамотному ИТшнику с минимальными знаниями базы это очевидно. Но за после последнее время это уже вторая статья на эту тематику
Спасибо за комментарий! Не уверен, что на Хабр сидят исключительно люди с огромным стажем в ИТ. Ниже был комментарий с вопросом: «с чего начать углубление, Bash или Python, если цель админить Linux/DevOps».
Я уверен, что Вы легко определите, какой язык использовать для скрипта под ту или иную задачу, но ведь не все имеют подобные знания. Разве это не так?
Не сочтите, пожалуйста, за грубость, но в действительности в АйТи заходят и молодые специалисты, которые вот-вот выпустились с ВУЗа. Для них многие вещи, которые Вам кажутся очевидными и простейшими, будут тяжелы в восприятии. Опыт приходит со временем.
Плюсом, я сравнивал не языки, а ситуации, когда и что использовать лучше. Когда правильнее и эффективнее использовать одно, а когда другое. На мой взгляд, это все же ≠ сравнению языков.
К статье есть много замечаний.
Не нашёл описания методологии выполнения тестирования. Как замерялось время (timeit в Python, time в Bash?), сколько проходов каждого теста использовалось для усреднения результатов? Использовались ли одни и те же файлы, либо же каждый раз создавались новые?
Воспроизводимость. Куски кода, это хорошо, но желательно ещё добавить ссылку на репозиторий с проектом тестирования, чтобы любой желающий мог проверить результаты через автоматизированный скрипт работающий с создаваемой на лету tmpfs. Скажем так, те, кто ходил по врачам и знакомы с понятием доказательной медицины (включая такие понятия как предвзятость), скорее всего пройдут мимо этой статьи, пролистав её до конца.
Путаница в терминологии. Вы сравниваете не Bash и Python, а библиотеки Python и команды UNIX-подобных систем. Они никакого отношения непосредственно к языкам не имеют. Например, Awk — это вполне самостоятельный парсер, который ничего не мешает вызывать напрямую из Python минуя командный интерпретатор. А pandas в Python не входит, в Python входит модуль csv.
Неправильно подобранные решения/алгоритмы для сравнения. При анализе логов в Python используется медленная регулярка, а в Bash — нет. Самым примитивным решением в Python будет split() для разделения на колонки, а не регулярки. В случае сокетов и использования disk_usage из shlibs вообще не должно быть сильно большой разницы между языками, как мне кажется. Там всё будет зависеть больше от скорости работы системных вызовов и работы почтового сервера (в том числе всевозможных задержек). Поэтому сразу возникает вопрос, а что тут замерялось-то со стороны языков? А если скрипт многократно запускался, то у Python инициализация самого интерпретатора и модулей в разы медленнее, чем у Bash (см. ниже).
Собственно, инициализация интерпретатора в Bash намного быстрее, чем в Python. Но это касается лишь инициализации, а не длительной работы скрипта. То есть многократный запуск маленького быстрого скрипта на Python будет медленнее, чем на Bash. Это учитывалось? В статье эта информация должна быть отражена, поскольку может оказывать значительное влияние на само тестирование, искажая его результаты.
Спасибо аз комментарий! Обратная связь очень помогает делать материалы более качественным.
Ваше замечание полностью справедливо, стоило внести эту информацию в статью. Для Python использоваться timet, для Bash - time. Проходов было 3, файлы же использовались одни и те же.
Момент с созданием репозитория рассмотрю в обязательном порядке, данный пункт действительно был упущен.
Что касательно путаницы в терминологии... Вы правы, фактически я противопоставлял 2 разных подхода. Методологическая ошибка, которая может ввести в заблуждение.
Да, мой пример с регулярками для разбора логов в Pythn - не самый лучший выбор для демонстрации производительности, были примеры более корректные. Но в этом аспекте я сознательно пошёл на компромисс в пользу "универсальности", тк регулярки лучше справятся с "грязными" данными. В статье данный момент действительно стоило оговорить, дабы не вводить в заблуждение.
И, про инициализацию интерпретатора - это наиболее важное замечание, которое мной было вообще упущено из виду. Разница в скорости запуска может быть критичной для каких-то сценариев.
Спасибо! Вы указали на все слабые места в статье, со всем согласен. Критика бесценна. Не сочтите за оправдание. Я действительно небольшой опыт в написании имею, поэтому какие-то аспекты в силу "неопытности" могу упускать. Критика же невероятно помогает в написании следующих статей, стараюсь уделять больше внимания деталям. Очень стараюсь улучшать материал, Вам ещё раз больше спасибо!
Поддерживаю предыдущего оратора, в общем и целом, автор сравнивает яблоки и апельсины.
По поводу скорости исполнения думаю это не критичный момент - если нужна скорость пишите специализированную программу на компилируемых языках.
Для целей автоматизации задач - bash удобнее. Хотя синтаксис мог быть и получше (хотя смотря с чем сравнивать, народ на CMD скриптах в винде такое пишет, …)
Главное преимущество bash- это же факто стандарт и нет разницы между версией 2.х и 3.0 как сделали в питоне и миграция заняла сколько лет? Гарантия обратной совместимости классная штука.
Запуск скриптов на питоне и запуск скриптов на баше имеет нюансы с точки зрения процессов операционной системы. В том числе в сценариях, когда идёт вызов системных команд из скрипта. Условно, запускается скрипт часть уже работающего процесса или как отдельный процесс. Хотелось бы про эти нюансы узнать в статье
Что посоветуете учить сначала для автоматизации Bash или Python, если цель – администрирование Linux/ DevOps?
Спасибо за комментарий!
Практически, важнее начать с Bash, тк он является стандартным интерпретатором командной строки. Без него админить Linux будет весьма проблематично. Затем плавно переходить к Python для сложных процессов.
Плюсом ко всему, админить сервера и работать с инструментами (K8s, Ansible, CI/CD) без знаний Bash крайне затруднительно. Но и Python для сложных процессов отменять сложно. Я бы посоветовал попробовать практиковаться параллельно.
Bash vs Python: битва, где нет проигравших