Пишем shell скрипты на Python и можно ли заменить им Bash

[@RPG]

Выглядит очень интересно, хотя я и привык к shutil и простой обертке над subprocess, но никогда не писал на питоне то, для чего шелл подошёл бы лучше. Из статьи непонятно, умеет ли библиотека делать конвейер? Ведь шелл-простыни зачастую намного сложнее, что-то вроде такого:

while read a b c; do
  grep $(sed s/1/2/ <<< $a) ... && some_command || error_handler
done <(find ... | grep ... | tr ... | sort -u)

В "нормальных" языках как раз часто не хватает главной фичи юникс-вея — конвейеров и всех тех непонятных штук, которые знакомы администраторам 50-го уровня:).

P. S. Интересно, кто-нибудь подсчитывал, сколько в приведённых трёх строчках шелла строк кода на Си (ну ладно, хотя бы на Питоне). Естественно, если делать по-честному, не прибегая к вызову system.

[@lamerman]

Да, это возможно, ведь то, что внутри '' по сути исполняется /bin/sh, например

result = `ls -l | grep myfile

[@bolk]

Надо просто сделать специальные объекты-обёртки и переопределить у них магический метод, отвечающий за «|» и можно будет делать конвееры.

[@lamerman]

Зачем, если и так работает? :)

[@bolk]

Как «так»? Автор же предпроцессор написал, то есть это не Пайтон.

[@mayorovp]

Чтобы можно было вставлять команды на питоне посреди конвейера

[@lamerman]

mayorovp, насколько я знаю, поправь меня если ошибаюсь, конвейеры не типичны для python. Там где они повсеместно используются, в шелл скриптах, вот это поддерживается в библиотеке, как видно в комментарии выше.
Если же нужны контейнеры прямо для python то видимо можно использовать какие-то библиотеки для python, которые делают конвейеризацию, но я такого никогда не видел и ни разу не использовал. То есть я не делал никогда ничего наподобие 'text' | re.find('e') | print. Ведь об этом речь я так понимаю.

[@bolk]

http://plumbum.readthedocs.org/en/latest/local_commands.html

[@fshp]

Пайп легко определить через левоассициативную бинарную функцию. На псевдокоде: x | f = f x
Единственное преимущество шелловских пайпов это то, что все компоненты конвейера работают параллельно.

[@mayorovp]

Это не "единственное преимущество", это "ключевое отличие".

[@hellman]

мне пришлось использовать препроцессинг, каюсь, но другого способа я не нашел

парсить как положено? например как в https://github.com/ikotler/pythonect

`curl {avatar_url} > {destination}

если avatar_url = "; rm -rf /", что будет? от баша например можно ожидать, что echo $var не выполнит лишних команд (хотя $var и может раскрыться в несколько аргументов), а в этом вашем shellpy всё плохо

[@lamerman]

Я не видел pythonect, нужно посмотреть что он делает и как это реализовано внутри.

Сейчас {avatar_url} будет вставлен как есть, спасибо за обнаружение потенциальной проблемы, я подумаю насколько это критично и что с этим можно сделать.

[@MrFrizzy]

А еще есть xonsh, но я не знаю, как у него обстоят дела с предыдущим примером

[@moigagoo]

Использую его в качестве основного шелла, очень доволен. У него вполне цельная модель разделения ролей между Питоном и Башем.

[@lamerman]

Он хороший, но лично мне он не показался очень удобным, наверное, это дело вкуса :)

[@lightman]

Кстати на странице упомянутого MrFrizzy xonsh'а есть табличка сравнения в т.ч. с fish
http://xon.sh/#comparison

xonsh выходит самый мощный

[@moigagoo]

Я использую xonsh именно как шелл. Перешел с zsh и не оглядывался.

[@frol]

Я очень долго жил на bash и только в прошлом году решил снова поэкспериментировать с этими новомодными окружениями. zsh решил пропустить, а начал с xonsh, так как казалось, что это может быть удобно. В общем, не ужился я с ним из-за странностей (автодополнение мне всё время мешало понять что же я пишу) и отсутствия достаточно базовых вещей вроде && и || в bash, ну и поддержка virtualenv кривая (и это в shell'e на Python для любителей писать проекты на Python). А вот fish — действительно оказался очень приятной штукой, тут и остановился (даже небольшой скринкаст записал).

[@moigagoo]

Буквально неделю назад добавил в xonsh менеджер окружений :-) Есть, что улучшить, но в целом проблема решена.

Проекту есть, куда расти, не спорю.

[@stagnantice]

Не всегда все так ужасно в bash, можно использовать обычные операторы сравнения, вместо -ne и прочих.
Самому понравилось использовать в питон argparse, для консольных команд. А его уже вызывать bash скриптом например.

[@maydjin]

Наш ответ PS ?:)

Мне нравится. Имхо, в первую очередь надо подумать в сторону реализации/реюза readline для такого шелла. Опять же имхо — если основной юзекейс скрипты, то шансов взлететь гораздо меньше, без удобного интерактивного режима в смысле.

[@bodqhrohro]

вы хотите распарсить json, xml, yaml

Есть jq/xmlstarlet/shyaml.

то непременно лезу в поисковик

Вместо того, чтобы в мануал глянуть, который уже на диске лежит. Обычно.

синтаксис языка простой и интуитивный

У шей он тоже простой и интуитивный, если допереть, что «ключевые слова» — это на самом деле имена команд, соответственно, они всегда стоят в начале и не более одного на команду. А так-то у пыхтона по сравнению с «мейнстримными языками» синтаксис не менее странный. И привязка синтаксиса к форматированию многих отпугивает. Иногда красивее однострочник написать, чем длинную узенькую «лестницу».

[@lamerman]

Есть jq/xmlstarlet/shyaml

Речь не о том, что что-то есть в принципе, а о удобстве использования.

Вместо того, чтобы в мануал глянуть, который уже на диске лежит. Обычно.

Зачем лезть в мануал для того чтобы посмотреть синтаксис одного оператора (пожалуйста, не спутайте это с "зачем вообще лезть в мануал", я этого не говорил :) )? Поисковик даст ответ мгновенно, а мануал надо сначала найти, потом в нем найти if.

[@bodqhrohro]

а о удобстве использования

Ну и чем впихивание в однострочник скриптов на другом языке удобнее рассчитанных на CLI утилит с компактным синтаксисом запросов?

Поисковик даст ответ мгновенно

Если соединение быстрое. И даже при этом надо пролистать пару-тройку сайтов.

мануал надо сначала найти

Прям так сложно man bash набрать, ага.

потом в нем найти if.

А вот с этим там проблема, да, дюжеть большой мануал, и коллизий на поиск много, даже под /^\s+if много подпадает. С другой стороны, если пролистать его разок весь, то можно запомнить, что команды в конце.

[@Ayahuaska]

Справедливости ради, питонячьи однострочники тоже вполне бывают.

PS>
Автор хотел велосипед — автор его собрал (:

[@l0rda]

Смею заверить, что на баше можно писать очень красивые и элегантые скрипты, просто нужно прочитать ман. А тот же sed, awk, cut и тп, запоминаются раз и навсегда, хотя те кто пользуются mc, про них часто даже и не знают. Сам пишу на питоне, но как по мне смешивать все в кучу — ужасно, перфекционист во мне категорически против.

[@bodqhrohro]

awk — вообще отдельный язык с кучей фич. На нём целиком довольно крупные скрипты пишут. Ну и sed — не промах, помимо попсового s/foo/bar/ там ещё куча полезных возможностей, из самого простого — печать определённого диапазона строк (sed -n 17,19p). А ещё теоретически на нём можно реализовать любой нормальный алгоритм Маркова, но это уже из разряда извращений.

[@KawaiDesu]

Всё, что угодно, лишь бы шелл не учить. Не нужен там пятидесятый уровень.

[@sebres]

А если он где вдруг и нужен, то для этого есть другие шелл-подобные языки, например тот же TCL (действительно "интуитивно понятный", а главное шелл-похожий)…

Python я тоже люблю и уважаю, но никогда не взял бы его как "shell replacement"...

Вот как приведенный пример будет на TCL, причем без всяких препроцессингов, т.е. OOTB:

#!/usr/bin/tclsh
package require json

set destination ""
if {[catch {
  # set answer [exec curl https://api.github.com/users/python 2>1&]
  set answer [exec curl -s https://api.github.com/users/python]

  set answer_json [::json::json2dict $answer]
  set avatar_url [dict get $answer_json avatar_url]

  set destination [file join [exec mktemp -d -t] python.png]

  exec curl -s $avatar_url > $destination

  puts "Avatar downloaded: [exec ls -l $destination]"

} err opt]} {
  puts "Failed to download avatar: $err"
  if {$destination ne ""} {file delete -force [file dirname $destination]}
  puts $opt
}

[@eps]

Пробовал писать shell-скрипты на python вместо bash, и запомнил про это три вещи:

• Скрипты стали красиво выглядеть
• Вообще нету особой уличной магии с экранированием, пробелами и кавычками
• Даже большой скрипт через пол-года понятен. Ясно, что он делает, и что хранится в каждой переменной.

[@belonesox]

Наверно это https://github.com/lamerman/shellpy/issues/42 → блокер, для перевода с баша шелл-скриптов. Ждать (минуты-часы-дни) вывод пока закончится команда, это точно не то, что ожидаешь от скриптов. И увы, даже на него забито.