Здравствуйте, Sheridan, Вы писали:
S>Всё верно. Замечу только что неправильно выбранный инструмент это камень не в огород инструмента, а в огород выбирающего.
Что, собственно, я и писал с первого сообщения: для более-менее сложных задач баш отстоен.
S>>>Повершелл просто устраняет пропасть между скриптом и ОС, которой в линупсе нет изначально. S>>Раскройте мысль. S>Доступ к процессам, оборудованию, настройкам, статистике, управление этим делом нопример
И в каком место PS заточен именно под это? Возникает ощущение, что вы не совсем в курсе о чём пишете.
S>Да нет, в ём просто это всё есть изначально
Да ну? То-то на каждый чих всторону приходится либо sed вызывать, либо awk.
S>>Я ехидничал. Имелось в виду, что пытаться делать что-то тяжёлое на баше будет только тот, кто кроме баша ничего не видел. S>При должном опыте и усердии возможно всё.
...skipped...
Можно я себя процитирую: S>PS. Это не значит, что на нём нельзя что-то сделать. Можно, но геморройно донельзя.
А это просто из палаты мер и весов в этом смысле (Дайте угадаю по коду, не читая исходную статью — веб-сервер для отображения каталогов?)
Здравствуйте, Somescout, Вы писали:
S>>Всё верно. Замечу только что неправильно выбранный инструмент это камень не в огород инструмента, а в огород выбирающего. S>Что, собственно, я и писал с первого сообщения: для более-менее сложных задач баш отстоен.
Еще раз: инструмент надо выбирать правильно.
S>>>>Повершелл просто устраняет пропасть между скриптом и ОС, которой в линупсе нет изначально. S>>>Раскройте мысль. S>>Доступ к процессам, оборудованию, настройкам, статистике, управление этим делом нопример S>И в каком место PS заточен именно под это? Возникает ощущение, что вы не совсем в курсе о чём пишете.
А в каком месте под это заточен cmd/bat?
S>>Да нет, в ём просто это всё есть изначально S>Да ну? То-то на каждый чих всторону приходится либо sed вызывать, либо awk.
Ты так говоришь, что мне кажется что ты считаешь, что это плохо
S>Можно я себя процитирую: S>>PS. Это не значит, что на нём нельзя что-то сделать. Можно, но геморройно донельзя. S>А это просто из палаты мер и весов в этом смысле (Дайте угадаю по коду, не читая исходную статью — веб-сервер для отображения каталогов?)
Повторюсь: всё зависит от опыта. Кому то гемморойно и хэлловорд на плюсах написать.
Здравствуйте, Sheridan, Вы писали:
S>>Что, собственно, я и писал с первого сообщения: для более-менее сложных задач баш отстоен. S>Еще раз: инструмент надо выбирать правильно.
Ещё раз: для более-менее сложных задач баш отстоен.
S>>И в каком место PS заточен именно под это? Возникает ощущение, что вы не совсем в курсе о чём пишете. S>А в каком месте под это заточен cmd/bat?
wmic. Если нужно что-то сложней — VBScript который с давних времён есть в винде.
S>>>Да нет, в ём просто это всё есть изначально S>>Да ну? То-то на каждый чих всторону приходится либо sed вызывать, либо awk. S>Ты так говоришь, что мне кажется что ты считаешь, что это плохо
Ты так говоришь, что мне кажется ты не совсем понимаешь что такое "сахар".
S>Повторюсь: всё зависит от опыта. Кому то гемморойно и хэлловорд на плюсах написать.
В принципе мне нравится движение диалога к признанию сравнимости по ковнокодистости баша и C++.
Здравствуйте, Somescout, Вы писали:
S>>>Что, собственно, я и писал с первого сообщения: для более-менее сложных задач баш отстоен. S>>Еще раз: инструмент надо выбирать правильно. S>Ещё раз: для более-менее сложных задач баш отстоен.
Мне кажется тут рекурсия без выхода...
S>>А в каком месте под это заточен cmd/bat? S>wmic.
Уел, я про него зобыл
S>>>>Да нет, в ём просто это всё есть изначально S>>>Да ну? То-то на каждый чих всторону приходится либо sed вызывать, либо awk. S>>Ты так говоришь, что мне кажется что ты считаешь, что это плохо S>Ты так говоришь, что мне кажется ты не совсем понимаешь что такое "сахар".
Непонятен тогда твой коммент про awk/sed в свете wmic
S>Если нужно что-то сложней — VBScript который с давних времён есть в винде.
Мы всё еще шелл обсуждаем или уже более мощные инструменты?
Если мне нужен будет повершелл, я его установлю.
S>>Повторюсь: всё зависит от опыта. Кому то гемморойно и хэлловорд на плюсах написать. S>В принципе мне нравится движение диалога к признанию сравнимости по ковнокодистости баша и C++.
А, ты из тех, кто делит инструменты на "говно" и "рулезз"? Ок, учту.
Здравствуйте, pira, Вы писали:
P>Интересно, что делает скрипт — скриптом?
У меня есть мнение и сейчас я его изложу.
Понятия "скрипт" и "командная строка" неразрывно связаны. Это связано с тем, что в стародавние времена первобытные программисты сначала придумали командную строку, а потом автоматизацию рутинных операций путем обучения интерпретатора команд считывать последовательность команд не только с устройств взаимодействия с пользователем, но и из файлов. Такие файлы назвали сценариями, что по английски "script" (откуда и произошел русский жаргонизм "скрипт").
Соответственно, если мы имеем в файле последовательность команд, предназначенную для некоего интерпретатора команд, то это скрипт.
Если мы имеем в файле исходный код для интерпретатора некоего языка программирования, то это не скрипт, а "просто программа".
Lua, ruby, python — это не интерпретаторы команд (хотя нередко можно видеть в играх командную строку, куда предлагается вводить код на lua, очень неудобно, но это и неудивительно)
cmd.exe, bash, tcl, power shell — это интерпретаторы команд, соответственно и файлы с последовательностью команд для них это скрипты.
Здравствуйте, pira, Вы писали:
P>Вот есть питоновский скрипт, скрипт на руби, на баше... Интересно, что делает скрипт — скриптом? Язык? Или то, что он компилируется? Или то, что он одноразовый и небольшой? P>Например, на хаскелле тоже можно писать как-бы скрипты -- один файл, с директивой !#/bin/env stack -- чем не скрипт.
Немного абстрагируюсь и позанудствую. Думаю, что имею на это право, т.к. первую программу написал на ЭВМ СМ-4 в 1985-ом году на Фортран-IV, и прошёл все этапы с IBM 360/370, PL/1, RPL и "Примусами".... Потом с IBM PC, Foxbase, Foxpro, Borland C/C++, Watcom C, "Виндоза" с Microsoft VS, и даже NLM для Novell NetWare на Watcom C. Потом был SCO Unix/OpenServer, HP/UX со всеми "этими вашими" "шелами". "Поигралсё" и в Линух, и даже Qt "слегка потрогал"... JavaScript и PHP не вызвали у меня "сексуального возбуждения", как и все эти "вебовские примочки", к которым я относился тогда ещё слишком высокомерно и брезгливо (о чём теперь сожалею, но время уже упущено почти безвозвратно). Хоть так и остался на "уровне мышления" C++ программера, но вот в Python почему-то влюбился сразу и конкретно! Наверное, за его библиотеки и красивую работу со списками и прочие "вкусности". На Питоне удобно отрабатывать Идею, а потом её уже можно "опускать на уровень ниже" до того же boost-а или каких-то других специализированных библиотек... Можно ли программы на Питоне называть скриптами? С одной стороны да, т.к. всё компилируется "на лету" в байт-код и исполняется средой (нельзя просто послать клиенту даже откомпилированную программу на Питоне, не попросив его при этом сначала установить дистрибутив Питона. "Классический" exe-шник можно переслать и так, хоть и он может требовать установки каких-то библиотек). Но с другой стороны, для Питона многие библиотеки написаны на C/C++ и при "правильном питонизме" не так уж сильно могут отличаться по скорости исполнения от "нативных" C/C++ программ (зависит от задачи, разумеется). Т.е., если это и "скрипт", то очень хороший скрипт!
В общем, что хочу сказать, "скрипт"- это:
— прежде всего "средство автоматизации" каких-то рутинных операций, которые хоть и могут быть очень сложными, но достаточно высокоуровневыми, по-сравнению с задачами уровня того же C или C++.
— средство "склейки" и "организации взаимодействия" между различными готовыми "крупными" ресурсами, сервисами, библиотеками, которые, чаще всего, пишутся теми же "Си-шниками"... Т.е. скрипты пользуются чем-то, что может существовать, как отдельные "строительные блоки", которые даже не знают о существовании скриптов, которые ими пользуются! Но среда исполнения скриптов и её идеология обязаны создать такую "экосистему", чтобы скрипты могли пользоваться услугами или ресурсами, которые создаются или предоставляются кем-то "извне" (самой операционной системой и известными прикладными сервисами).
— более-менее простой синтаксически язык программирования. Чаще всего, без строгой типизации, с кучей вольностей и "инлайн-кастингом" типов, со встроенными средствами работы со сложными структурами данных "на лету", которые даже могут быть встроены в сам язык, как его составная часть.
— что-то, что исполняется в достаточно защищённой среде, которая хоть и не "бъёт по рукам" сразу, допуская какие-то вольности, но при этом и может сильно ограничивать в этих "вольностях". Кроме того, сама среда исполнения скриптов подчищает то "хавно", которое остаётся после "криворукого программирования", т.к. основная задача скриптов не в том, чтобы написать "совершенную программу" (хоть сама парадигма скриптов этого и не исключает совсем!), а в том, чтобы быстро "достичь результата" ("сделал дело — гуляй смело!" )
— интерпретаторы, чаще всего, по-определению и идеологии. В отличие от классических языков и сред программирования, где присутствует три этапа: (1) написание программы, (2) компиляция, (3) сборка в исполняемый файл "на языке процессора".
Вот как-то так с моей колоколни "старого засранца" ...
Здравствуйте, LuciferSaratov, Вы писали:
LS>Lua, ruby, python — это не интерпретаторы команд (хотя нередко можно видеть в играх командную строку, куда предлагается вводить код на lua, очень неудобно, но это и неудивительно)
Эээ что? ) Как раз основным элементом базовой поставки Питона является его интерпретатор. )))
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, LuciferSaratov, Вы писали:
LS>>Lua, ruby, python — это не интерпретаторы команд (хотя нередко можно видеть в играх командную строку, куда предлагается вводить код на lua, очень неудобно, но это и неудивительно)
_>Эээ что? ) Как раз основным элементом базовой поставки Питона является его интерпретатор. )))
я не про интерпретаторы вообще, а про интерпретаторы команд.
в том же питоне, кстати, есть нечто вроде команды — это print statement.
авторам питона было понятно, что для интерактивной отладки куда удобнее писать так:
print a
а вовсе не вызов функции:
print(a)
другими словами, в моём понимании весьма важен исторически сложившийся синтаксис.
но вообще говоря, я тут ещё поразмышлял над своим пониманием термина "скрипт" и пришёл к выводу, что синтаксис хоть и важен, но не он определяет, является ли некий код скриптом или нет.
определяющим моментом является не сам язык, на котором написан код, и даже не способ исполнения этого кода, а окружение, в котором код исполняется.
то есть, если код на некотором языке является "клеем" между высокоуровневыми внешними по отношению к нему утилитами, то это скрипт (утилиты в данном случае могут быть другими программами или функциями движка игры).
если код сам по себе является реализацией некоторой нетривиальной функциональности, то это уже программа, даже если язык и интерпретатор те же, что и в первом случае.
код lua в Serious Sam это скрипт, а код на lua в Prosody это уже не скрипт.
Здравствуйте, LuciferSaratov, Вы писали:
LS>>>Lua, ruby, python — это не интерпретаторы команд (хотя нередко можно видеть в играх командную строку, куда предлагается вводить код на lua, очень неудобно, но это и неудивительно) _>>Эээ что? ) Как раз основным элементом базовой поставки Питона является его интерпретатор. ))) LS>я не про интерпретаторы вообще, а про интерпретаторы команд. LS>в том же питоне, кстати, есть нечто вроде команды — это print statement. LS>авторам питона было понятно, что для интерактивной отладки куда удобнее писать так: LS>
LS>print a
LS>
LS>а вовсе не вызов функции: LS>
LS>print(a)
LS>
LS>другими словами, в моём понимании весьма важен исторически сложившийся синтаксис.
Хыхы, вот как раз в Питоне версий 3.х перешли к "print(a)", а "print a" — это код для Питона версий 2.x. )))
LS>но вообще говоря, я тут ещё поразмышлял над своим пониманием термина "скрипт" и пришёл к выводу, что синтаксис хоть и важен, но не он определяет, является ли некий код скриптом или нет. LS>определяющим моментом является не сам язык, на котором написан код, и даже не способ исполнения этого кода, а окружение, в котором код исполняется.
Конечно. Есть же и скрипты на C++ и полноценные приложения на Python. )
Замечу только что неправильно выбранный инструмент это камень не в огород инструмента, а в огород выбирающего.
Т.е. скрипты пользуются чем-то, что может существовать, как отдельные "строительные блоки", которые даже не знают о существовании скриптов, которые ими пользуются! Но среда исполнения скриптов и её идеология обязаны создать такую "экосистему", чтобы скрипты могли пользоваться услугами или ресурсами, которые создаются или предоставляются кем-то "извне" (самой операционной системой и известными прикладными сервисами).
...
