Скриптовый язык для повседневных нужд

[diesel]

Чего только (для шелл-скриптинга) стоит возможность:

Код: Выделить всё

<?php
$result = `/usr/bin/something --blah-blah --verbosity 9`;
?>

В переменной $result имеем полный вывод выполнившейся команды, с которым можно делать всё что угодно. В Перле точно так же, кстати говоря. А вот в Питоне для этого требуется подключение какого-то там внешнего дополнительного модуля, вызов одной (надо точно помнить которой) из функций exec*, похожих друг на друга, но с разными наборами параметров и разными типами возвращаемых значений, и т.д и т.п.

php использовать для "шелл-скриптинга" - то есть я так понял для склейки результатов выполнения внешних команд - это интересно конечно, только зачем? Вопрос ведь не в том насколько сложно выполнять внешние команды

[eduard_pustobaev]

да, разумеется! а также grep, cat, sort, uniq и т.д.

sed & awk, в отличии от приведенных вами команд, считаются скриптовыми языками.

А чо за исправления? Я уверен, что человек не ошибся и вполне себе имел в виду именно cut, а не cat. Вполне себе юзабельная штука.

[rm_]

php использовать для "шелл-скриптинга" - то есть я так понял для склейки результатов выполнения внешних команд - это интересно конечно, только зачем?

А Вы что предлагаете, голый шелл? А если неохота каждый раз вспоминать, как в шелле пишутся его уродские недоциклы for/while/until, или там switch/case (а он есть вообще?), и так далее. Что мешает воспользоваться всеми удобствами нормального языка, с современным синтаксисом и богатой библиотекой функций?
В любом случае, даже начав писать какой-то скрипт на шелле, есть очень большая вероятность рано или поздно придти к необходимости в скрипте реализовать чего-нибудь этакое, что средствами шелла и вышеупомянутых unix tools'ов сделать невозможно просто никак. Тогда что, с нуля переписывать всё на полноценном скриптовом языке? Не лучше ли было сразу им и воспользоваться?)

[diesel]

php использовать для "шелл-скриптинга" - то есть я так понял для склейки результатов выполнения внешних команд - это интересно конечно, только зачем?

А Вы что предлагаете, голый шелл? А если неохота каждый раз вспоминать, как в шелле пишутся его уродские недоциклы for/while/until, или там switch/case (а он есть вообще?), и так далее. Что мешает воспользоваться всеми удобствами нормального языка, с современным синтаксисом и богатой библиотекой функций?

про "нормальный язык" - пропущу ... ежели у языка есть "богатая библиотека функций", то зачем этот язык использовать как шелл? - то есть для склейки результатов выполнения внешних команд? - вопрос именно в этом. Либо библиотеки языка позволяют получать необходимую информацию "изнутри" - и тогда надо пользоваться этими библиотеками, либо же стоит поискать другой способ реализации поставленной задачи(вариант "написать библиотеку самому" я пропущу). Каждое правило имеет свои исключения, но если в скриптах на php/python/ruby/perl слишком часто появляется вызов внешних команд - что-то явно не так.

В любом случае, даже начав писать какой-то скрипт на шелле, есть очень большая вероятность рано или поздно придти к необходимости в скрипте реализовать чего-нибудь этакое, что средствами шелла и вышеупомянутых unix tools'ов сделать невозможно просто никак.

если вдруг понадобится забить микроскопом гвоздь... не стоит ли сразу делать дно микроскопа из толстенного слоя метала, дабы забивать было удобнее? На практике это означает, что либо: изначально не был выбран правильный инструмент, либо изначально поставленная задача переросла сама себя, и нужен другой инструмент для решения новой задачи. Кстати, благодаря тому что шелл служит для склейки комманд, никто не запрещает сделать то что вы не можете сделать шеллом - отдельным скриптом.

[rm_]

если в скриптах на php/python/ruby/perl слишком часто появляется вызов внешних команд - что-то явно не так.

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

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

...приглядитесь - вдруг это не микроскоп, а молоток с оптическим прицелом?

[minoru-kun]

Тех, кто их использует, хотел бы спросить, почему вы используете тот или иной, какие сильные стороны имеет каждый из них?

Быдлокодеришкам обычно пистон нра, рекомендую попробовать

[Voice]

Быдлокодеришкам обычно пистон нра, рекомендую попробовать

А не быдло на чем пишет? Не уж то на хаскеле и лиспе?

[Denjs]

Дыбы вернуть тему "в русло" - предлагаю обсудить вопрос "об отдалчиках".
* shell - отладчики отсутствуют (?!) как класс?
* php - отладка затруднительна... в 4-м PHP был кажется сторонний отладчик, в PHP5 кажется ничего не было (я ничего внятного по данному вопросу не нашел. "Zend-студия" не обсуждается.ибо $$$$), что c PHP6 ?
* QtScript (да, я опять пиарю QDroid) - в QT 4.4 отладчика нет, появитсяс выходом QT4.5 (ныне в бета-версии).

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


После этого обсудим вопрос "оБ расширениях".
Насколько/как возможности каждого из языков-кандидатов могут быть расширены в случае если чего-то не хватает?
новый модуль? библиотека? класс? как трудно его разработать и как быстро его встроить в среду/программу?

[Portnov]

Сначала напомню, что речь идёт о unix-like системах, где традиционно отладчики используются редко. Самое частое применение gdb - "gdb -c proga.core; bt" чтобы узнать, от чего упала программа. Логгирование рулит немерянно.

И тем не менее.

Для bash есть bashdb. Для php есть что-то под названием Xdebug. Для python есть pydb и отладчики в различных IDE (вероятно, они являются фронтендами к pydb, не смотрел). Для perl есть ebug и ptkdb.

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

[diesel]

если в скриптах на php/python/ruby/perl слишком часто появляется вызов внешних команд - что-то явно не так.

Странно, с чего это вдруг.

ну допустим что эти языки имеют достаточное количество функций и библиотек дабы заместить стандартные unix-команды. зачем cat, grep, sed, awk, wget, lynx, dig etc. если это можно сделать "изнутри", и получить более адекватный доступ к полученным данным,чем просто plain-text вывод? Если речь идет о том что делается что-то не очень простое, то зачем усложнять себе жизнь ненужным парсингом результатов внешней команды? shell объединяет plain-text'овые вводы/выводы разных команд, ориентируясь на то что там полюбому текст, а пользователь знает что ему от этого текста надо. ЯП может дать возможность работать с абстракцией "большей чем просто текст", и может быть больше чем просто склейка для фильтров. Вы же одной рукой даете продвинутые возможности, а другой их отодвигаете.

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

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

В любом случае, оправдать использование именно голого шелла в качестве языка для хоть сколь-либо нетривиальных скриптов (т.е. больше одной-двух строчек), на мой взгляд может разве что отсутствие на целевой системе чего-либо более функционального.

init-скрипты в Вашей системе больше двух строк, и perl, а скорее всего и python идут из-коробки. внимание вопрос....

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

...приглядитесь - вдруг это не микроскоп, а молоток с оптическим прицелом?

главное что "молоток с отпическим прицелом" - штука бесполезная, хотя прикольно (:

[tolobayko]

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

ключик точно не помню, по-моему -v

[psyshit]

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

ключик точно не помню, по-моему -v

#!/bin/bash -x


В результате этого будет выводиться некоторая интересная выходная информация. (отладка) (с) http://linfoline.homedns.org/howto/Bash-Prog-Intro/