Боже, ну и дела.
Ладно, экскурс для самых зелёных:
На заре первых диких программных комплексов человек часто предпринимал попытки их одомашнить. В итоге эволюции и труда многих программистов создавались командные оболочки. Первые программисты были очень трудолюбивы, но генетика, бессердечная сволочь, всё же делала своё дело — то там то сям добавляя крупицу лени. Как ни прискорбно, в итоге появился очень ленивый программист, которому лень было столько трудиться. И вот закралась ему крамольная мысль — а почему бы не переложить всю эту работу на компьютер? К тому моменту совесть по отношению к компьютеру уже была рудиментом у большинства его вида, что и позволило нашему программисту воплотить свои идеи в виде расширений возможностей для командной оболочки. Дальнейшие годы эволюции оформили эти расширения в интерпретируемый язык сценариев, которые в простонародье стали называть скриптами.
Так, что исторически в сленге программистов скрипт — это то, что интерпретируется.
То, что сейчас идёт судорожное броуновское движение динамики в статику, статики в динамику, интерпретируемого в компилируемое, компилируемое в интерпретируемое — это всё "мартышкин труд" и починёт на полях всех остальных "гениальных" идей. Тема не стоит топика.
Здравствуйте, IID, Вы писали:
IID>Компилируемость (в байткод) не важна. Очень многие языки это и так делают (неявно). IID>ИМХО основное (историческое?) отличие — это возможность исполняться нативно. Результат JIT-а в исполняемый файл это уже не скрипт.
А тут как сову натягивать. Основной критерий, кмк, это возможность поправить исходный код на ходу.
Всё остальное — это уже вопрос терминологии. Скажем, sfx архив с интерпретатором и скриптом внутри вполне реально выдать за пакет с скриптами. Добавим сфероконины: возьмём любой софт, который хранит скрипт в ресурсах / базе / отдельных файлах и имеет встроенный редактор скриптов. Ну да, он тоже скриптуемый, даже если эти скрипты в фоне в натив перегоняются.
Здравствуйте, pira, Вы писали:
P>Вот есть питоновский скрипт, скрипт на руби, на баше... Интересно, что делает скрипт — скриптом? Язык? Или то, что он компилируется? Или то, что он одноразовый и небольшой? P>Например, на хаскелле тоже можно писать как-бы скрипты -- один файл, с директивой !#/bin/env stack -- чем не скрипт.
Можно к вопросу подойти с другой стороны.
Скрипт это то, что написано для автоматизации того, что можно сделать вручную, затратив много времени. Нопример, переименовать кучу файлов или потрогать за ssh сервера с целью нопример сбора статистики.
"Программа" (сервис, АРМ, етц) же делает больше и часто комплексно (ну то бишь тот же CMS — там и зарегистрировацца можно и пост написать и коммент и оформить и кортинку вставить). Одним из критериев отличия я бы назвал возможность взаимодействия с пользователем (сервисы конечно не попадают под этот критерий).
Ну вот как то так.
Если кратко, то скрипт — "лучше я потрачу два часа на написание кода, который делает работу за пять минут, на которую у меня уйдет пятнадцать", а "программы" — всё остальное.
Здравствуйте, pira, Вы писали:
P>Вот есть питоновский скрипт, скрипт на руби, на баше... Интересно, что делает скрипт — скриптом? Язык? Или то, что он компилируется? Или то, что он одноразовый и небольшой?
Компилируемость (в байткод) не важна. Очень многие языки это и так делают (неявно).
ИМХО основное (историческое?) отличие — это возможность исполняться нативно. Результат JIT-а в исполняемый файл это уже не скрипт.
P>Например, на хаскелле тоже можно писать как-бы скрипты -- один файл, с директивой !#/bin/env stack -- чем не скрипт.
хаскелл тут непричём, это shebang, фича командного интерпретатора (и да — ты перепутал символы в shebang).
Здравствуйте, pira, Вы писали:
P>Вот есть питоновский скрипт, скрипт на руби, на баше... Интересно, что делает скрипт — скриптом? Язык? Или то, что он компилируется? Или то, что он одноразовый и небольшой? P>Например, на хаскелле тоже можно писать как-бы скрипты -- один файл, с директивой !#/bin/env stack -- чем не скрипт.
Если после написания текста программы ты можешь выполнить ее, используя только сам файл с исходным кодом и минуя явные шаги создания дополнительных сущностей (скомпилированной программы) — то это скрипт. Как оно под капотом все устроено, как и во что компилируется — неважно.
Здравствуйте, pira, Вы писали:
P>Вот есть питоновский скрипт, скрипт на руби, на баше... Интересно, что делает скрипт — скриптом? Язык? Или то, что он компилируется? Или то, что он одноразовый и небольшой? P>Например, на хаскелле тоже можно писать как-бы скрипты -- один файл, с директивой !#/bin/env stack -- чем не скрипт.
Вообще на этот вопрос ответил более 20 лет назад товарищ Джон О́устерхаут в своей работе "Scripting: Higher-Level Programming for the 21st Century". Гугл в помощь.
S>Если кратко, то скрипт — "лучше я потрачу два часа на написание кода, который делает работу за пять минут, на которую у меня уйдет пятнадцать", а "программы" — всё остальное.
+Скрипт ещё не имеет собственного состояния. Чисто вход-выход. Программа же часто имеет состояния, сохраняемые между запусками
Здравствуйте, pira, Вы писали:
P>Вот есть питоновский скрипт, скрипт на руби, на баше... Интересно, что делает скрипт — скриптом? Язык? Или то, что он компилируется? Или то, что он одноразовый и небольшой? P>Например, на хаскелле тоже можно писать как-бы скрипты -- один файл, с директивой !#/bin/env stack -- чем не скрипт.
Script это по основному значению сценарий. Поэтому этим термином логично называть текст программы в human readable форме. Т.е. к примеру сишный код в файлах это скрипт, а в скомпилированном виде уже бинарник. По сути тоже скрипт, но для человеческого восприятия неподходящий.
Вот есть питоновский скрипт, скрипт на руби, на баше... Интересно, что делает скрипт — скриптом? Язык? Или то, что он компилируется? Или то, что он одноразовый и небольшой?
Например, на хаскелле тоже можно писать как-бы скрипты -- один файл, с директивой !#/bin/env stack -- чем не скрипт.
Здравствуйте, pira, Вы писали:
v6>>Если после написания текста программы ты можешь выполнить ее, используя только сам файл с исходным кодом и минуя явные шаги создания дополнительных сущностей (скомпилированной программы) — то это скрипт. Как оно под капотом все устроено, как и во что компилируется — неважно.
P>ну так я могу скомпилировать прожку на С таким образом, что будет иллюзия, что она так и исполняется. в одном случае это будет python my_app.py, в другом compile_my_c_app.sh my_app.c P>разница-то?
Ну будет скрипт на C, в чем проблемы? Другое дело, что так никто не делает потому что неудобно.
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, Sheridan, Вы писали:
S>>Сишному программеру, не знающему эти вашы (Ц) башы и перлы будет удобно.
IID>Скажу без утаечки. И баши и перлы — оба два чудовищное говно.
На счёт перла мнения могут расходиться, а вот баш — не говно! Баш — это говнище.
Здравствуйте, Somescout, Вы писали:
S>>>На счёт перла мнения могут расходиться, а вот баш — не говно! Баш — это говнище. S>>Слайды будут? Или по радио услышал? S>Да приходилось иметь с ним дело. Даже фанаты баша когда речь заходит о более-менее сложных скриптах начинают кивать на питон.
А когда питона недостаточно — уходят в плюсы нопример. Так везде. Когда язык/среда перестаёт подходить под задачу — оно заменяется чем то помощнее.
S>Не, если по привычке сравнивать его с .bat-никами, то да баш рулит. А вот если с чем-то более современным — powershell или python, то баш дико устаревший отстой на уровне тех же самых .bat-ников, в пределах погрешности измерения.
Баш именно с батниками/повершеллом сравнивать и надо, это одного поля ягоды. А вот питоноперлы это уже других полей ягода.
S>PS. Это не значит, что на нём нельзя что-то сделать. Можно, но геморройно донельзя.
Вопрос опыта
Здравствуйте, pira, Вы писали:
P>Вот есть питоновский скрипт, скрипт на руби, на баше... Интересно, что делает скрипт — скриптом? Язык? Или то, что он компилируется? Или то, что он одноразовый и небольшой? P>Например, на хаскелле тоже можно писать как-бы скрипты -- один файл, с директивой !#/bin/env stack -- чем не скрипт.
Простота линковки -- иначе, как уже сказано выше, не надо перекомпилировать.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, IID, Вы писали:
IID>>Компилируемость (в байткод) не важна. Очень многие языки это и так делают (неявно). IID>>ИМХО основное (историческое?) отличие — это возможность исполняться нативно. Результат JIT-а в исполняемый файл это уже не скрипт.
S>А тут как сову натягивать. Основной критерий, кмк, это возможность поправить исходный код на ходу.
что значит на ходу? если я запустил питоновский скрипт и потом сделал изменения -- они в этом работающем скрипте не будут видны.
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, pira, Вы писали:
P>>Вот есть питоновский скрипт, скрипт на руби, на баше... Интересно, что делает скрипт — скриптом? Язык? Или то, что он компилируется? Или то, что он одноразовый и небольшой?
IID>Компилируемость (в байткод) не важна. Очень многие языки это и так делают (неявно). IID>ИМХО основное (историческое?) отличие — это возможность исполняться нативно. Результат JIT-а в исполняемый файл это уже не скрипт.
а почему тогда скрипты на Lua называют скриптами?
P>>Например, на хаскелле тоже можно писать как-бы скрипты -- один файл, с директивой !#/bin/env stack -- чем не скрипт.
IID>хаскелл тут непричём, это shebang, фича командного интерпретатора (и да — ты перепутал символы в shebang).
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, pira, Вы писали:
P>>Вот есть питоновский скрипт, скрипт на руби, на баше... Интересно, что делает скрипт — скриптом? Язык? Или то, что он компилируется? Или то, что он одноразовый и небольшой? P>>Например, на хаскелле тоже можно писать как-бы скрипты -- один файл, с директивой !#/bin/env stack -- чем не скрипт.
S>Простота линковки -- иначе, как уже сказано выше, не надо перекомпилировать.
ну вот возьмем хаскел:
#!/usr/bin/env stack
--stack runghc --resolver nightly-2016-12-04
-- тут прога идет
main = putStrLn "hellllo"
это скрипт на хаскелле. а ты точно знаешь, что stack не компилирирует этот код за кулисами в нативную прожку, а потом при запуске в терминале, выдает результат?
также, я могу сюда еще подключить разные внешние библиотеки. тут -- простота линковки?
Здравствуйте, pira, Вы писали:
P>что значит на ходу? если я запустил питоновский скрипт и потом сделал изменения -- они в этом работающем скрипте не будут видны.
Как насчёт "в уже доставленном клиенту продукте"?
Здравствуйте, Sheridan, Вы писали:
S>Скрипт это то, что написано для автоматизации того, что можно сделать вручную, затратив много времени. Нопример, переименовать кучу файлов или потрогать за ssh сервера с целью нопример сбора статистики. S>"Программа" (сервис, АРМ, етц) же делает больше и часто комплексно (ну то бишь тот же CMS — там и зарегистрировацца можно и пост написать и коммент и оформить и кортинку вставить). Одним из критериев отличия я бы назвал возможность взаимодействия с пользователем (сервисы конечно не попадают под этот критерий).
ну что ж, не бывает скриптов на питоне, которые от пользователя принимают данные, которые он печатает вручную через терминал?
S>Если кратко, то скрипт — "лучше я потрачу два часа на написание кода, который делает работу за пять минут, на которую у меня уйдет пятнадцать", а "программы" — всё остальное.
возьму любую программу и получишь то же самое определение.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, pira, Вы писали:
P>>что значит на ходу? если я запустил питоновский скрипт и потом сделал изменения -- они в этом работающем скрипте не будут видны. S>Как насчёт "в уже доставленном клиенту продукте"?
ну так передай клиенту прожку на С с исходниками, которую он сможет компилить с помощью make файла и запускать. и питоновский скрипт. и там, и там можно исправлять на ходу и все это сделать одной коммандой.
обе эти прожки -- на С и питоне -- будут скриптами?
Здравствуйте, pira, Вы писали:
P>ну так передай клиенту прожку на С с исходниками, которую он сможет компилить с помощью make файла и запускать. и питоновский скрипт. и там, и там можно исправлять на ходу и все это сделать одной коммандой. P>обе эти прожки -- на С и питоне -- будут скриптами?
Я ж говорю — тут как сову натягивать.
ChaiScript, CS-Script, typescript, который вообще компилируется с проверкой типов, JS, который браузером JITтится в натив — что из этого не скрипт?
Здравствуйте, v6, Вы писали:
v6>Здравствуйте, pira, Вы писали:
P>>Вот есть питоновский скрипт, скрипт на руби, на баше... Интересно, что делает скрипт — скриптом? Язык? Или то, что он компилируется? Или то, что он одноразовый и небольшой? P>>Например, на хаскелле тоже можно писать как-бы скрипты -- один файл, с директивой !#/bin/env stack -- чем не скрипт.
v6>Если после написания текста программы ты можешь выполнить ее, используя только сам файл с исходным кодом и минуя явные шаги создания дополнительных сущностей (скомпилированной программы) — то это скрипт. Как оно под капотом все устроено, как и во что компилируется — неважно.
ну так я могу скомпилировать прожку на С таким образом, что будет иллюзия, что она так и исполняется. в одном случае это будет python my_app.py, в другом compile_my_c_app.sh my_app.c
разница-то?
Здравствуйте, pira, Вы писали:
P>Здравствуйте, Sharov, Вы писали:
S>>Здравствуйте, pira, Вы писали:
P>>>Вот есть питоновский скрипт, скрипт на руби, на баше... Интересно, что делает скрипт — скриптом? Язык? Или то, что он компилируется? Или то, что он одноразовый и небольшой? P>>>Например, на хаскелле тоже можно писать как-бы скрипты -- один файл, с директивой !#/bin/env stack -- чем не скрипт.
S>>Простота линковки -- иначе, как уже сказано выше, не надо перекомпилировать.
P>ну вот возьмем хаскел: P>
P>#!/usr/bin/env stack
P>--stack runghc --resolver nightly-2016-12-04
P>-- тут прога идет
P>main = putStrLn "hellllo"
P>
P>это скрипт на хаскелле. а ты точно знаешь, что stack не компилирирует этот код за кулисами в нативную прожку, а потом при запуске в терминале, выдает результат? P>также, я могу сюда еще подключить разные внешние библиотеки. тут -- простота линковки?
ога, руками перекампилировать ничего не надо. Изменили и запустил. Остальное интерпретатор на лету подхватит.
Здравствуйте, TimurSPB, Вы писали:
TSP>+Скрипт ещё не имеет собственного состояния. Чисто вход-выход. Программа же часто имеет состояния, сохраняемые между запусками
Скрипт тоже может сохранять состояния, если этого автор захочет.
Здравствуйте, GarryIV, Вы писали:
P>>ну так я могу скомпилировать прожку на С таким образом, что будет иллюзия, что она так и исполняется. в одном случае это будет python my_app.py, в другом compile_my_c_app.sh my_app.c P>>разница-то? GIV>Ну будет скрипт на C, в чем проблемы? Другое дело, что так никто не делает потому что неудобно.
Вообще то делают, если требуется быстродействие. ) Например здесь: https://root.cern.ch
Здравствуйте, Michael7, Вы писали:
TSP>>+Скрипт ещё не имеет собственного состояния. Чисто вход-выход. Программа же часто имеет состояния, сохраняемые между запусками M>Скрипт тоже может сохранять состояния, если этого автор захочет.
Естественно, на каждый аргумент можно придумать своё исключение, но тут не тот случай, когда "один экземпляр не соответствует критериям значит вся партия брак". Границы размыты, камрад. Более того, со временем скрипт может перерасти в "программу" (нопример, в сервис) и наоборот (студент написал "программу", пришол админ, увидел закономерности, дал подзатыльник и заменил скриптом)
Здравствуйте, GarryIV, Вы писали:
GIV>Ну будет скрипт на C, в чем проблемы? Другое дело, что так никто не делает потому что неудобно.
Почему же неудобно? Сишному программеру, не знающему эти вашы (Ц) башы и перлы будет удобно. Правда для начала надо будет нарисовать компилирующий и запускающий скрипт, который можно будет использовать в шебанге, и это довольно тривиальная задача (скопировали в tmp, откусили строку с шебангом, скомпилировали, запустили, подождали, удалили).
Здравствуйте, Sheridan, Вы писали:
GIV>>Ну будет скрипт на C, в чем проблемы? Другое дело, что так никто не делает потому что неудобно. S>Почему же неудобно? Сишному программеру, не знающему эти вашы (Ц) башы и перлы будет удобно. Правда для начала надо будет нарисовать компилирующий и запускающий скрипт, который можно будет использовать в шебанге, и это довольно тривиальная задача (скопировали в tmp, откусили строку с шебангом, скомпилировали, запустили, подождали, удалили).
Здравствуйте, alex_public, Вы писали:
_>Или же не извращаться и просто поставить это https://root.cern.ch/cling. )))
Можно, но это оверкилл. В треде про "скомпилять и запустить" а не про с++ командную строку.
Здравствуйте, IID, Вы писали:
S>>Сишному программеру, не знающему эти вашы (Ц) башы и перлы будет удобно. IID>Скажу без утаечки. И баши и перлы — оба два чудовищное говно.
Согласен с тем, что всё то что я не знаю — говно это годная позиция.
TSP>>+Скрипт ещё не имеет собственного состояния. Чисто вход-выход. Программа же часто имеет состояния, сохраняемые между запусками M>Скрипт тоже может сохранять состояния, если этого автор захочет.
Может конечно. Но не стоит так делать(на мой взгляд).
Здравствуйте, Somescout, Вы писали:
S>На счёт перла мнения могут расходиться, а вот баш — не говно! Баш — это говнище.
Слайды будут? Или по радио услышал?
Здравствуйте, Sheridan, Вы писали:
S>>На счёт перла мнения могут расходиться, а вот баш — не говно! Баш — это говнище. S>Слайды будут? Или по радио услышал?
Да приходилось иметь с ним дело. Даже фанаты баша когда речь заходит о более-менее сложных скриптах начинают кивать на питон.
Не, если по привычке сравнивать его с .bat-никами, то да баш рулит. А вот если с чем-то более современным — powershell или python, то баш дико устаревший отстой на уровне тех же самых .bat-ников, в пределах погрешности измерения.
PS. Это не значит, что на нём нельзя что-то сделать. Можно, но геморройно донельзя.
Здравствуйте, Sheridan, Вы писали:
S>>Да приходилось иметь с ним дело. Даже фанаты баша когда речь заходит о более-менее сложных скриптах начинают кивать на питон. S>А когда питона недостаточно — уходят в плюсы нопример. Так везде. Когда язык/среда перестаёт подходить под задачу — оно заменяется чем то помощнее.
Только вот в случае с башем этот момент наступает подозрительно быстро.
S>Баш именно с батниками/повершеллом сравнивать и надо, это одного поля ягоды. А вот питоноперлы это уже других полей ягода.
В сравнении с powershell'ом bash — отстой. И, кстати, у powershell'а с питоном (и тем более перлом) больше общего, чем с башем.
S>>PS. Это не значит, что на нём нельзя что-то сделать. Можно, но геморройно донельзя. S>Вопрос опыта
Возможно. В том плане, что если кроме баша ничего не знаешь.
Здравствуйте, Somescout, Вы писали:
S>>А когда питона недостаточно — уходят в плюсы нопример. Так везде. Когда язык/среда перестаёт подходить под задачу — оно заменяется чем то помощнее. S>Только вот в случае с башем этот момент наступает подозрительно быстро.
Еще раз: всё зависит от задачи. Если этот момент наступил быстро, то очевидно изначально был выбран неправильный инструмент.
S>>Баш именно с батниками/повершеллом сравнивать и надо, это одного поля ягоды. А вот питоноперлы это уже других полей ягода. S>В сравнении с powershell'ом bash — отстой. И, кстати, у powershell'а с питоном (и тем более перлом) больше общего, чем с башем.
Повершелл просто устраняет пропасть между скриптом и ОС, которой в линупсе нет изначально. Ну и сахара добавили.
S>>>PS. Это не значит, что на нём нельзя что-то сделать. Можно, но геморройно донельзя. S>>Вопрос опыта S>Возможно. В том плане, что если кроме баша ничего не знаешь.
Я вот даже не представляю себе ситуацию, когда ктото знает только бащ кроме как если это начинающий студент.
Здравствуйте, Sheridan, Вы писали:
S>>Только вот в случае с башем этот момент наступает подозрительно быстро. S>Еще раз: всё зависит от задачи. Если этот момент наступил быстро, то очевидно изначально был выбран неправильный инструмент.
т.е. баш
S>Повершелл просто устраняет пропасть между скриптом и ОС, которой в линупсе нет изначально.
Раскройте мысль.
S>Ну и сахара добавили.
В этом плане баш для диабетиков.
S>>>Вопрос опыта S>>Возможно. В том плане, что если кроме баша ничего не знаешь. S>Я вот даже не представляю себе ситуацию, когда ктото знает только бащ кроме как если это начинающий студент.
Я ехидничал. Имелось в виду, что пытаться делать что-то тяжёлое на баше будет только тот, кто кроме баша ничего не видел.
Здравствуйте, Somescout, Вы писали:
S>>>Только вот в случае с башем этот момент наступает подозрительно быстро. S>>Еще раз: всё зависит от задачи. Если этот момент наступил быстро, то очевидно изначально был выбран неправильный инструмент. S>т.е. баш
Всё верно. Замечу только что неправильно выбранный инструмент это камень не в огород инструмента, а в огород выбирающего.
S>>Повершелл просто устраняет пропасть между скриптом и ОС, которой в линупсе нет изначально. S>Раскройте мысль.
Доступ к процессам, оборудованию, настройкам, статистике, управление этим делом нопример
S>>Ну и сахара добавили. S>В этом плане баш для диабетиков.
Да нет, в ём просто это всё есть изначально
S>Я ехидничал. Имелось в виду, что пытаться делать что-то тяжёлое на баше будет только тот, кто кроме баша ничего не видел.
При должном опыте и усердии возможно всё. Например:
:;while [ $? -eq 0 ];do
nc -vlp 8080 -c'(
r=read;
e=echo;
$r a b c;
z=$r;
while [ ${#z} -gt 2 ]; do
$r z;
done;
f=`$e $b|sed 's/[^a-z0-9_.-]//gi'`;
h="HTTP/1.0";
o="$h 200 OK\r\n";
c="Content";
if [ -z "$f" ];then (
$e $o;
(for n in *;do
if [ -f "$n" ]; then
$e "<a href=\"/$n\">`ls -gh \"$n\"`</a><br>";
fi;
done);
);
elif [ -f "$f" ];then
$e "$o$c-Type: `file -ib \"$f\"`\n$c-Length: `stat -c%s \"$f\"`";
$e;
$e $f>&2;
cat "$f";
else
$e -e "$h 404 Not Found\n\n404\n";
fi)';
done
Здравствуйте, 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. )
Т.е. скрипты пользуются чем-то, что может существовать, как отдельные "строительные блоки", которые даже не знают о существовании скриптов, которые ими пользуются! Но среда исполнения скриптов и её идеология обязаны создать такую "экосистему", чтобы скрипты могли пользоваться услугами или ресурсами, которые создаются или предоставляются кем-то "извне" (самой операционной системой и известными прикладными сервисами).
...
