Скрипты Python против Bash

[@khim]

По-моему лучше оставить close() для каких-нибудь специальных нужд и писать просто:

with open("/home/khim/helloworld", "w") as gogo:
  gogo.write("Hello, world!\n")

Необходимость этого доказывает ваш второй пример где вы умудрились закрыть файл — и это в статье со словами Запомните! Любое открытие файла должно сопровождаться последующим закрытием с помощью этого метода…

[@Azy]

Думаю не лишним будет сказать, что with поддерживается только с версии 2.5.

[@khim]

Python 2.5 появился больше двух лет назад. Никому же не приходит в голову говорить что bash поддерживает [[ и (( только с версии 2.0?

[@Azy]

Люди еще РНР4 используют ) Так что небольшое предупреждение думаю не повредит.

[@zzeus]

во всяких тырпрайз дистрах (RHEL/Debian) пока еще 2.4

[@khim]

Ну с еnterprise всё непросто. Но я предполагаю что люди, работающие в enterprise и без моих советов знают что делают.

Ubuntu 8.04 LTS использует Python 2.5, RHEL 6 будет тоже его содержать…

[@zzeus]

убунта это такой веселый дебиян-анстабля.

а вот RHEL6 пока неизвестно когда будет. есть вероятность, что через год еще.

[@yonyonson]

Ну мне например приходится на python 2.3 писать регулярно, но это скорее вырожденный случай, Вы правы конечно.

[@ilya_ost]

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

host l2tp.corbina.ru | egrep -o -m 1 '([0-9]+\.){3}[0-9]+'
host l2tp.corbina.ru | sed -r -n '2s/.+\ address\ //p'
host l2tp.corbina.ru | awk '/address/ {print $4; exit}'

[@ilya_ost]

s/shell/shell со стандартными программами/

[@Cepg]

Python не замена Shell…

[@ilya_ost]

Вы название топика видели? А почему не замена? Иногда вполне себе замена.

[@Cepg]

А bash!=sh

[@ilya_ost]

А bash теперь не shell? Или в «Bourne-again shell» слово «shell» мне мерещится?

[@SergeyKish]

Ой, а кто такое читать умеет?
Я уж не говорю о писать

[@khim]

Писать такое как раз нормально. Главное — в файлах не сохранять, а то так и до скриптов с тысячу строк (в которых потом чёрт ногу сломает) недалеко.

[@SergeyKish]

Если не сохранять, то и прочитать никто не получится.
В таком случае творить можно что угодно.

[@enchantner]

Python во многом потому и составляет конкуренцию — потому что код на нем изящен и легко читается.

[@SergeyKish]

Бедные девочки.
Мне стыдно! Стыдно за шарик на котором мы живем.

[@Elvalery]

почему эт бедные? что вы имеете против девочек-программистов?

[@Tagire]

у вы же читать на русском умеете. А человек, который знает испанский, но не знает русский, умеет читать по испански. А китайский текст вам вообще тарабарщиной с другой грамматикой покажется. Не все языки похожи, но это не значит, что непохожие хуже.
П.С. Для меня — это вполне читабельный вид.

[@SergeyKish]

Странное дело — для меня код на C/C++, Java, Python, Ruby, Perl, PHP, JavaScript читабелен, а приведенное выше — нет. Появляется вполне логичный вопрос — а кому такое читабельно?

Развивая вашу аналогию — отправляясь в Европу не стоит особо рассчитывать на знания корейского.

[@ilya_ost]

Там не читабелен только первый вариант из-за регулярки и относительно редко используемых опций grep, которые я перед написанием посмотрел в man. Варианты на sed и awk тривиальны и понятны любому, кто с ними как-то знаком. Вы тоже не родились со знанием C, Java или Perl.

[@Tagire]

Регулярки — это вообще не считается, потому что они используются в большинстве языков.
И относительно аналогии, китайский слабо распространен среди не китайцев, но китайцев достаточно много, чтобы говорить о большом количестве людей понимающих китайский)

[@SergeyKish]

То есть вы предлогаете оформлять документацию прежде всего на китайском. Не китаец всегда может найти китайца и попросить того перевести. Вероно?

[@Tagire]

Ну как сказать, я думаю скоро на всем ПРИДЕТСЯ оформлять документацию прежде всего на китайском вместо английского)

[@Tagire]

Кстати, вы назвали все языки принадлежащие только к одному виду языков. А где же пролог, хаскель, лисп, f#, эрланг и языки других видов?)

[@SergeyKish]

Ага, языки одного вида (кроме JavaScript, но мы о нем тактично промолчим).

Случилось так что C/C++, Python, Ruby, Perl я использую для автоматизации процессов в Unix системах. Ну не встречаются мне скрипты на lisp, haskell, io, lua, хоть и интересуюсь. А если я попробую их использовать заказчики не поймут — кому потом систему поддерживать, дорабатывать?

[@Tagire]

Человеку, который не знает руби, код на руби покажется таким же не читаемым, как вам код на bash. А если брать код bash без синтаксиса awk,sed итп., то он как бы совсем легко читается.

[@SergeyKish]

Мне не кажется нечитаемым код на bash. Я просто не хочу его читать. Он мне по просту не нравится (как и php, а также C++ местами).

[@Tagire]

А мне не нравится ява. На ней много неграмотного кода, который читать гораздо труднее, чем совершенно логичный, пусть не с рождения понятный код bash. И?

[@SergeyKish]

Расскажите об этом миру! Не сдерживайте себя.

А если серьезно — где вы постоянно берете «не понятный»?
И хватит смешивать понятия — неграмотный код есть везде.

>> И?
А я тут при чем?

[@SergeyKish]

Человек знакомый с одним из языков ветки легко переходит на другой. Bash для него тоже не составляет труда.

[@Tagire]

Если на этот язык легко перейти, то почему вы считаете, что это ужасный язык программирования? Я думаю, что он идеально подходит для своей задачи — написания системных скриптов.

[@SergeyKish]

Видать в этих землях полно поклонников недоязыков… минусуют.
BASH — отличная штука, но как язык программирования полный отстой.

Да, не ослышались — отстой. Что за манеры — ковыряться дубинкой в носу?

Повторюсь еще раз — посмотрите на другие языки! В мире софта и так полно кривых решений. Да идеальное не создать, но можно хотя бы приблизится к идеалу!

А как будете минусовать хоть коментарий оставьте, мне действительно интересно мнение.

[@ilya_ost]

Согласен, Bash как язык программирования полный отстой. Я его толком не знаю и писать на нем меня ломает. Но задачи типа связывания каналом пары программ и простой фильтрации текста с помощью стандартных shell инструментов решаются проще. И в статье как раз не показано преимуществ. Дубасить Врагов Отечества надо дубинкой, а ковырятся в носу пальцами =)

[@Tagire]

Не надо приводить все языки к одному виду. Парадигм программирования очень много(аспектное, объектное, событийное, командное итп), и если у языка непривычная, или неудобная для какого-то, пусть даже и большого количества, людей структура, то это не делает его хуже для какого-то, пусть даже и маленького количества, людей, которым он нравится.
П.С. Правда из коммандных языков мне нравится больше tcl, но он довольно сильно похож на bash.

[@SergeyKish]

Да я не привожу… Просто я вижу язык на котором можно создавать страшные вещи. Язык развивавшийся стихийно, пытающийся поддерживать обратную совместимоть. Язык переросший первоначальную задачу.

Это делает язык хуже для людей сталкивающихся с творчеством людей не знающих меры, а может просто знающих только один язык.

[@Tagire]

Где тут развитие, большинству его возможностей почти двадцать лет. Синтаксис регулярных выражений обычный перловский. awk — си-подобный язык, основные возможности осваиваются за час. sed — тоже не шибко сложнее. Перенаправление вывода одной комманды в другую — эта вещь знакомая каждому пользователю юникс-подобной системы.

И у этого языка есть один огромнейший плюс. Он приучает не изобретать велосипеды там где они не нужны.

[@SergeyKish]

Имхо, не изобретать велосипеды это использовать библиотеки:
— python pypi
— ruby gems
— perl cpan
есть это под bash?

Именно библиотеки определяют возможность использования языка.
— Вы импортируете / экспортируете данные из csv, xml, odt?
— Производите математические рассчеты?
— Строите графики?
— Создаете GUI с Gtk, Qt (я помню о Tcl, вопрос для bash)?
— А как вы работаете с RPC / SOAP?

Вам не кажется что мы рассматриваем разные задачи?

[@Tagire]

Библиотека bash — это /bin && /usr/bin && /sbin && /usr/sbin
Там есть много чего интересного)

— Данные awk,sed и прочее
— www.linux.org/apps/all/Scientific/Math.html выбираем любую, и используем. Они большинство под gpl
— Графики plotutils
— bash скрипты, как бы предназначены для запуска в среде bash, но если неймется, то можно использовать zenity и dialog
— rpc запросы если только через netcat слать

Похоже на то. В начале мы рассматривали вопрос написания служебных скриптов.

[@SergeyKish]

Эм… вы не фанатик случайно? Ручной парсинг… брр.
Создается впечатление будто вы готовы переписать все на bash.

Ключевой для меня момент:
>> BASH — отличная штука, но как язык программирования полный отстой.

И если мне нужно узнать текущую директорию я воспользуюсь

$ pwd

а не

$ python -c "import os; print os.path.abspath(os.curdir)"

Но при создании приложения я воспользуюсь языком программирования. А вы приложения создавали?

[@Tagire]

Не обязательно ручной парсинг. И я не говорил, что я буду писать всё на bash. Я говорил, что он по возможностям не уступает другим языкам. Мне кажется, что вы смешиваете понятия языка программирования, и языка программирования на котором пишутся десктопные приложения.

[@SergeyKish]

Вы сами написали ответ на импорт / экспорт csv, xml, odt — awk, sed и прочее — вероятно таки руками.

А мне кажется вы не понимаете о чем я говорю. Потрудитесть прочесть и иные ветки.
habrahabr.ru/blogs/python/47474/#comment_1219134
habrahabr.ru/blogs/python/47474/#comment_1220000
habrahabr.ru/blogs/python/47474/#comment_1221499

Еще — что это за «язык программирования на котором пишутся десктопные приложения» у вас есть опыт программирования? Вы понамаете о чем говорите? Или только лабы умеете писать?

[@Tagire]

У меня есть опыт программирования. Причем у меня есть опыт использования lua, postscript, javascript, maple и r. В которых нет и десятой доли возможностей вами перечисленными, но которые считаются отличными языками программирования в своей среде.

[@SergeyKish]

Я прекращаю дискуссию ибо бред

[@Zert]

Shell — не язык общего назначения. Он предназначен для интерактивной работы с системой и всё. Поэтому к нему нет библиотек soap, qt, импорт-експорт в csv,odt и т.д. Не надо быть таким фанатичным, со своей целью он отлично справляется, для всего остального есть другие инструменты.

[@khim]

Shell — это shell. При наборе команд в командной строке важна лаконичность. А вот в скриптах (особенно больших) уже важнее читаемость…

[@Yfka]

Речь идёт не о замене командных строк баша, а о том, что питоновские скрипты вполне заменяют шеловские обычные скрипты. Автор как раз это и показывал в статье.

Разве вам не приходилось видеть установочные скрипты на многие тысячи строк?
Речь о том, что можно реализовать их на Питоне и они будут изящными. Причём очень важный момент: в них можно использовать всю мощь Питона и задействовать возможности для использования которых в традиционных скриптах пришлось бы писать Си-шные утилитки.

[@ilya_ost]

Я с вами согласен конечно. Я тоже что-то пишу на Python, что-то — на Bash. Вопрос в выборе инструмента, и я как раз ожидал увидеть примеры, когда Python лучше. В статье код довольно не интересный и не показывает особенностей Python. Так можно написать на чем угодно, а на Bash + sed + grep + awk получается проще.

[@SergeyKish]

Пример из жизни (прям сейчас работаю) Guard:
— стартует при запуске системы
— мониторит логи, принимает RPC-запросы, все это парсит
— останавливает, запускает процесы
— конфигируруемая логика событий
— обо всем этом пишет логи

Для решения задачи каждый использует свой набор инструментов. Я вот Python / Ruby / Perl — обычно выбор определяют требования заказчика и библиотеки.

[@c411k]

извращение. гланды через ж? =\

[@voidlizard]

Что-то много букаф. Второй скрипт:

import os, re, sys, commands
r = re.findall(r'address\s+([.\d]+)', commands.getoutput('host '+sys.argv[1]), re.MULTILINE)
print 'Addr:', r[0] if len® else ''

Первый скрипт:

open("/home/username/goo",«w»).write('GOO')

Файл вполне успешно закроется сборщиком мусора, и в однострочниках его закрывать — пустая трата времени.
Если все же есть опасения, то with поможет. Правда для 2.5 придется написать from __future__ import with_statement

Для однострочников может питон и не рулит, но если нужно сделать что-то достаточно сложное — то тут он уже уделывает баш, конечно.

[@vitek]

Я уверен, что из тех кто прочёл этот пост, какой-то процент заинтересуется языком. Ещё небольшой процент от них его полюбит и начнёт использовать. И вот они уже к тому моменту сами с лёгкостью будут писать подобные выражения-монстры.
Но начинать-то нужно с малого ;)
Вот если бы топик назывался «Как на питоне определить ip-адрес корбины», то тогда, несомненно, можно было подвергнуть разгромной критике всё вышенаписанное.

А я позволю себе критику но небольшую. Вот тут ([\d]+)\.([\d]+)\.([\d]+)\.([\d]+) всё же можно и квантификатор {1,4} себе позволить для облегчения читаемости :)

[@vitek]

Точнее даже {2,4}, а ещё лучше просто {4} :)

[@vitek]

От ведь :) Виноват, утро, голова ещё не включилась :) Спасибо

[@enchantner]

import os, re, sys, commands
r = re.findall(r'address\s+([.\d]+)', commands.getoutput('host '+sys.argv[1]), re.MULTILINE)
print 'Addr:', r[0] if len® else ''

Согласен, но я не ставил целью компактность :) Согласитесь, что написанное вами объяснить в двух строчках было бы куда сложнее.

[@voidlizard]

Ну оппоненты именно многословность ставят в минут. вместо cmd | grep — получаем десять строк на питоне, в которых делается куча всего. В принципе ничего непонятного в моем варианте не используется — никаких функциональных заморочек и т.п.

[@Mr_Floppy]

listdir(path)

Пишите уж тогда принадлежность к модулю

gogo.close

close() метод, а не свойство — в питоне нельзя опускать скобки, если в функцию не передаются параметры.

hst != None

Так не пишут:

Comparisons to singletons like None should always be done with
'is' or 'is not', never the equality operators.

PEP 8 — Style Guide for Python Code

А вообще же данная задача решается методом socket.gethostbyname(domain)

[@enchantner]

gogo.close

Ой, точно, исправил.

hst != None

Оператор официально работает в последних версиях Python, а в третьем питоне только он и останется. Хотя насчет логики стоит подумать, вы правы.

[@iv1]

Раз уж vs bash, то может стоит перенести в блог Линукс для всех и добавить соответствующий тег.

[@Azy]

Причем тут линукс? :)
У меня под Mac OS тоже bash.
Под win32 вообще, думаю вариант для тех кто не ставит себе cygwin.

[@iv1]

При том, что это первично, а вариант с цугвином это уже вторяк.

[@Yfka]

Я знаю bash и Windows PowerShell, но теперь я использую для всего именно Питон.

Главное преимущество Питона: он МОЩНЕЕ чем просто язык сценариев; это полноценный язык программирования. Т.е. написать скрипт не труднее чем на баше, но если нужно можно добавить какую угодно функциональность. А для традиционных скриптов пришлось бы писать и использовать программу на Си.

[@Yfka]

Поясняю для минусующих:

Эта статья важна именно для Windows, потому, что там нет установленых по умолчанию bash и Windows PowerShell.

[@khim]

Python там тоже из коробки не стоит.

[@kmmbvnr]

Кстати, уже несколько раз, по просьбе, пользователей этой несчастной ос, писал небольшие утилитки, и конвертил их с помощью py2exe в исполняемый файл.

Очень удобно.

[@khim]

Ну всё-таки сказать что писать скрипт не труднее чем на bash'е нельзя. На bash'е вы можете получить результат работы программы просто написав

RESULT=$(host l2tp.corbina.ru)

а на Python'е это выглядит заметно сложнее. Но если вам нужно в программе не просто вызвать несколько файлов, но и закодировать какую-то логику, то Python — уже удобнее. И быстрее.

[@iv1]

Для виндовс есть другие скриптовые языки (javascript/vbscript) — первичные (так сказать, заточенны под него), все остальное повторяю вторично.

[@kmmbvnr]

По синтаксису, у них нет особого преимущества перед python, так что их стоило изучить, ради мелких задач.

А т.к. с распространением флешек, ~10 мегабайт даже для небольшой утилитки, никого не смущают, то вполне можно в тех редких случаях, когда утилитка нужна где-то еще, использовать python+py2exe.

[@meako]

Помню когда-то игрался подобным способом, и то что сильно не понравилось, так то что raw_input() не умеет автодополнения. Весьма напряжно при введении длинного пути к файлам и т.п.
С этим можно что-то сделать?

[@khim]

Да, можно.

[@spanasik]

По моему скромному мнению вместо
#!/usr/bin/python
лучше писать
#!/usr/bin/env python

[@prodd]

сложные участки для шела(неудобные в написании и понимании на sh) типа коннекта к бд или коннект по телнету пишу на питоне и все эти кусочки потом срепляю sh-скриптами

[@alteist]

Не убедили, такие операции делаю с помощью grep, sed, awk с закрытыми глазами, смысла изучать Питон админу пока что не вижу.

Пишите еще, интересно было бы почитать:
— сравнение скорости выполнения пакетных операций, вроде обработки регекспами файла в несколько тысяч строк
— обзор библиотек полезных в администрировании.

[@descentspb]

Вы правы насчет операций grep,sed и awk. Они действительно полезны, отлично работают, и для таких целей лучше использовать их. К тому же они чаще всего быстрее, как бы вы не оптимизировали Pyhton'овский код.
Но вот насчет смысла изучения Python, я бы посоветовал вам изменить свое мнение. Ваши возможности расширятся многократно, как только вы начнете его испозьзовать. И, как было сказано выше, при решении задач, которые сложнее, чем описанные примеры, Python идеально подходит.
Когда вы владеете обоими этими инструментами, работать значительно приятнее.

[@kmmbvnr]

Вероятно в большинстве случаев, действительно sed/grep/awk будут быстрее, но иногда даже просто написанный код, использующий казалось бы такую тяжелою фичу питона, как генераторы, работает быстрее.

См. следующий топик ссылку, там в презентации приводится сравнение.

[@ganqqwerty]

Сравнить бы скорости… Из питон-программ юзаю yum — это просто тренажер терпения. Первая ассоциация — программист, выпущенный на марафон.
А так, целью статьи было введение в общесистемные команды Питона?

[@SergeyKish]

Yum — это который менеджер пакетов? Вы считаете на sh быстрее?

По поводу скорости — тормозят обычно алгоритмы. В качестве примера — стандартный менеджер пакетов Gentoo emerge написан на Python, есть ускоренная версия и тоже на Python, но она шустрее поскольку кеширует некоторые моменты.

В большинстве случаев скорости Python хватает. Если же не будет хватать — определяем профайлером узкое место и реализуем на C. Это гуманее чем писать все на C. Чтобы убедится достаточно найти в доках создания расширений Python небольшой пример реализованный на C и на Python.

[@And1ty]

Для Windows — Python спасает от написания bat-скриптов. Для *nix — сомнительно.

[@chumric]

Автор зачем то питона ставит против баша. У каждого есть любимое блюдо, какоето блюдо на обед, на завтрак, на ужин.
Скрипты в пару десятков строк пишу на bash, чуть по сложнее на php — потому что мне так удобнее.

Автор молодец — приподнял завесу о том как написать консольный скрипт на любимом языке. Питон, перл, баш, рнр — только дело вкуса.

[@qq6ka]

О чём пост?

[@bepcyc]

люблю пайтон, но если вы не на линуксе, а в произвольном юниксе, то питона может запросто не быть (на AIX нет)
а скрипты часто пишутся по принципу «написал в одном месте — использую везде»

[@khim]

На AIX и bash'а может не быть, однако. А писать на чистом sh — увольте.

[@bepcyc]

не быть может, наверное, но почему-то есть
и везде обычно находится
а питон оказывается экзотикой обычно

[@glorybox]

как будто перла нету :)

[@khim]

Такими темпами скоро и не будет :-)

[@zupernintendo]

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

[@aiz]

Python:
gogo = open ("/home/username/helloworld","w")
gogo.write("Hello, world!")
gogo.close()

shell:
echo "Hello, world!" >> /home/username/helloworld

чувствуете разницу? Python — это всё таки больше ЯП, нежели хороший инструмент по автоматизации рутинных действий в операционной системе; а вот posix shell'ам в последнем равных нету, как ни старайтесь. Одни каналы чего стоят — на любом другом ЯП вы задолбаетесь создавать код, который должен тупо положить в переменную вывод результата работы внешней программы(а ведь для этого в другом ЯП придётся ещё создать системный вызов для запуска этой программы), пропущенный, к примеру, через grep или sed; в shell подобные действия осуществляются в одну строку. Каждой задаче — свой инструмент; и ни из python'а, ни из ruby(а что? тоже ведь скриптовый), хороший удобный shell не сделаешь, как ни старайся.

[@thevery]

а как на счёт, например,
new File("/home/ildar/tmp/file.txt4")<<«Hello, world!»
на groovy?

>на любом другом ЯП вы задолбаетесь создавать код, который должен тупо положить в переменную вывод результата работы внешней программы

def result = «uname -a».execute().text

[@aiz]

э, не. Вы мою цитату на полуслове оборвали — у меня там дальше речь про конвейеры была — "… вывод <> внешней программы, _пропущенной_ <> через...". К примеру так:
var="`cat file | grep <шаблон для вывода строк> | sed <шаблон для замены какого-либо одного текста на другой> | awk <печать определённых полей> | ... <и так далее>`"
я не сомневаюсь, наверняка в python'е тоже есть функционал (как и в любом другом нормальном ЯП) для работы с каналами (помню, даже как-то специально ковырялся в нём именно с целью разобраться, как их в нём можно использовать), но сомневаюсь, что это будет выглядеть столь лаконично и записываться в одну строку без лишних слов; опять же, в Вашем примере выше — целых два лишних слова — «execute().text»; так к чему плодить сущности без необходимости. Ну и ещё не стоит забывать, что в shell'е если переменная состоит только из цифр, то она, в зависимости от контекста, может использоваться и как численная переменная, и как текстовая — это _очень_ полезно и эффективно; afaik, в python'е без переконвертирования типов для этого не обойтись(хоть он и может использовать динамическую типизацию) — а это, опять же, лишние строки для вызова других методов для конвертирования данных.
имхо, нельзя приравнивать python и shell; ну разные у них задачи, раз-ны-е; поэтому для меня заголовок топика звучит как что-то вроде «C++ против HTML».