Pull to refresh

Comments 35

Выглядит очень интересно, хотя я и привык к 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.
Да, это возможно, ведь то, что внутри '' по сути исполняется /bin/sh, например
result = `ls -l | grep myfile

Надо просто сделать специальные объекты-обёртки и переопределить у них магический метод, отвечающий за «|» и можно будет делать конвееры.
Зачем, если и так работает? :)
Как «так»? Автор же предпроцессор написал, то есть это не Пайтон.
Чтобы можно было вставлять команды на питоне посреди конвейера
mayorovp, насколько я знаю, поправь меня если ошибаюсь, конвейеры не типичны для python. Там где они повсеместно используются, в шелл скриптах, вот это поддерживается в библиотеке, как видно в комментарии выше.
Если же нужны контейнеры прямо для python то видимо можно использовать какие-то библиотеки для python, которые делают конвейеризацию, но я такого никогда не видел и ни разу не использовал. То есть я не делал никогда ничего наподобие 'text' | re.find('e') | print. Ведь об этом речь я так понимаю.
Пайп легко определить через левоассициативную бинарную функцию. На псевдокоде: x | f = f x
Единственное преимущество шелловских пайпов это то, что все компоненты конвейера работают параллельно.
Это не "единственное преимущество", это "ключевое отличие".
мне пришлось использовать препроцессинг, каюсь, но другого способа я не нашел

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

`curl {avatar_url} > {destination}

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

Сейчас {avatar_url} будет вставлен как есть, спасибо за обнаружение потенциальной проблемы, я подумаю насколько это критично и что с этим можно сделать.
UFO just landed and posted this here
Он хороший, но лично мне он не показался очень удобным, наверное, это дело вкуса :)
UFO just landed and posted this here
Кстати на странице упомянутого MrFrizzy xonsh'а есть табличка сравнения в т.ч. с fish
http://xon.sh/#comparison

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

UFO just landed and posted this here
Я использую xonsh именно как шелл. Перешел с zsh и не оглядывался.
Я очень долго жил на bash и только в прошлом году решил снова поэкспериментировать с этими новомодными окружениями. zsh решил пропустить, а начал с xonsh, так как казалось, что это может быть удобно. В общем, не ужился я с ним из-за странностей (автодополнение мне всё время мешало понять что же я пишу) и отсутствия достаточно базовых вещей вроде && и || в bash, ну и поддержка virtualenv кривая (и это в shell'e на Python для любителей писать проекты на Python). А вот fish — действительно оказался очень приятной штукой, тут и остановился (даже небольшой скринкаст записал).
UFO just landed and posted this here
Не всегда все так ужасно в bash, можно использовать обычные операторы сравнения, вместо -ne и прочих.
Самому понравилось использовать в питон argparse, для консольных команд. А его уже вызывать bash скриптом например.
Наш ответ PS ?:)

Мне нравится. Имхо, в первую очередь надо подумать в сторону реализации/реюза readline для такого шелла. Опять же имхо — если основной юзекейс скрипты, то шансов взлететь гораздо меньше, без удобного интерактивного режима в смысле.
вы хотите распарсить json, xml, yaml
Есть jq/xmlstarlet/shyaml.
то непременно лезу в поисковик
Вместо того, чтобы в мануал глянуть, который уже на диске лежит. Обычно.
синтаксис языка простой и интуитивный
У шей он тоже простой и интуитивный, если допереть, что «ключевые слова» — это на самом деле имена команд, соответственно, они всегда стоят в начале и не более одного на команду. А так-то у пыхтона по сравнению с «мейнстримными языками» синтаксис не менее странный. И привязка синтаксиса к форматированию многих отпугивает. Иногда красивее однострочник написать, чем длинную узенькую «лестницу».
Есть jq/xmlstarlet/shyaml

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

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

Зачем лезть в мануал для того чтобы посмотреть синтаксис одного оператора (пожалуйста, не спутайте это с "зачем вообще лезть в мануал", я этого не говорил :) )? Поисковик даст ответ мгновенно, а мануал надо сначала найти, потом в нем найти if.
а о удобстве использования
Ну и чем впихивание в однострочник скриптов на другом языке удобнее рассчитанных на CLI утилит с компактным синтаксисом запросов?
Поисковик даст ответ мгновенно
Если соединение быстрое. И даже при этом надо пролистать пару-тройку сайтов.
мануал надо сначала найти
Прям так сложно man bash набрать, ага.
потом в нем найти if.
А вот с этим там проблема, да, дюжеть большой мануал, и коллизий на поиск много, даже под /^\s+if много подпадает. С другой стороны, если пролистать его разок весь, то можно запомнить, что команды в конце.
Справедливости ради, питонячьи однострочники тоже вполне бывают.

PS>
Автор хотел велосипед — автор его собрал (:
Смею заверить, что на баше можно писать очень красивые и элегантые скрипты, просто нужно прочитать ман. А тот же sed, awk, cut и тп, запоминаются раз и навсегда, хотя те кто пользуются mc, про них часто даже и не знают. Сам пишу на питоне, но как по мне смешивать все в кучу — ужасно, перфекционист во мне категорически против.
awk — вообще отдельный язык с кучей фич. На нём целиком довольно крупные скрипты пишут. Ну и sed — не промах, помимо попсового s/foo/bar/ там ещё куча полезных возможностей, из самого простого — печать определённого диапазона строк (sed -n 17,19p). А ещё теоретически на нём можно реализовать любой нормальный алгоритм Маркова, но это уже из разряда извращений.
Всё, что угодно, лишь бы шелл не учить. Не нужен там пятидесятый уровень.
А если он где вдруг и нужен, то для этого есть другие шелл-подобные языки, например тот же 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
}
Пробовал писать shell-скрипты на python вместо bash, и запомнил про это три вещи:

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

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

Sign up to leave a comment.

Articles

Change theme settings