Комментарии 259
> Например, с помощью этих утилит мы можем найти все упоминания ключевого слова class в нашем дереве исходников
Зачем здесь нужен find вообще? grep -rn сделает это изящнее.
Зачем здесь нужен find вообще? grep -rn сделает это изящнее.
Я, может, что-нибудь упускаю, но если
grep -r указать *.cpp — он не зайдёт в подкаталоги (если только они не имеют окончания .cpp), а если указать просто звёздочку — он будет искать вообще во всех файлах, а не только в исходниках. Нет?--exclude=*
--include=*.cpp
--include=*.cpp
Здорово! Спасибо за информацию!
В одной команде вашей ничего страшного нет, но на загруженном svn сервере такое делать не стоит)
Лучше запустить 1 раз grep, чем find и н-ное количество раз grep.
Лучше запустить 1 раз grep, чем find и н-ное количество раз grep.
Попробуйте еще ack-grep.
betterthangrep.com
betterthangrep.com
Не пойму вообще, зачем сравнивать nix way утилиты и пауер шелл. У них разные идеологии.
по-моему здесь нет ничего, чего нет в UNIX shell, во-первых всем ясно откуда пошел PowerShell, пресловутые «алиасы» лишнее тому доказательство, во-вторых некоторые программы (команды) существуют по 30 лет, логично что они не оперируют объектами
вообще топик напоминает радость пользователя MS, который никогда не работал под *NIX :-)
P.S. ни в коем случае не холивар
вообще топик напоминает радость пользователя MS, который никогда не работал под *NIX :-)
P.S. ни в коем случае не холивар
>вообще топик напоминает радость пользователя MS, который никогда не работал под *NIX :-)
Как будто это плохо. Прогресс и развитие — всегда хорошо. Глядишь как нибудь и никсовые шеллы начнут перенимать плюшки у PowerShell.
Как будто это плохо. Прогресс и развитие — всегда хорошо. Глядишь как нибудь и никсовые шеллы начнут перенимать плюшки у PowerShell.
было бы конечно здорово, но что-то мне подсказывает, что microsoft пишет для себя и под себя, собственно мало чего сделано opensource, и как вывод, мало чего пользователь может улучшить и закоммитить для других…
и на мой взгляд про zsh в топике упоминать не стоило, PowerShell это как планета в галактике zsh
и на мой взгляд про zsh в топике упоминать не стоило, PowerShell это как планета в галактике zsh
Вы ошибаетесь, если так сравнивать, то zsh лишь аналог bash с некоторыми улучшениями ;) PowerShell же совершенно новый шелл с революционными нововведениями :)
я вроде бы достаточно прозрачно упомянул, что bash (и другие sh) и PoweShell это разные ЭПОХИ
отличие вашего сравнения и моего состоит как раз в том, что вы видите этот продукт революционным, а я вижу старые проверенные идеи в новой оболочке (причем реализация и тестирование этих старых идей заняло какое-то время у сообщества UNIX, в то время как первоначальная идея MS о собственном шелле провалилась и они решили взять основу идеи UNIX), здесь я ни в коем случае не хочу кого-то оскорбить, просто напомнить
функций zsh мне хватает за глаза, хоть это и «аналог bash с некоторыми улучшениями», он легок, довольно прост (для того кто не первый день работает) и функционален
P.S. у меня лимит 1 коммент за 5 минут, так что я при всем желании не могу всем ответить, к тому же какие-то тролли срут в карму уже сейчас :-))
отличие вашего сравнения и моего состоит как раз в том, что вы видите этот продукт революционным, а я вижу старые проверенные идеи в новой оболочке (причем реализация и тестирование этих старых идей заняло какое-то время у сообщества UNIX, в то время как первоначальная идея MS о собственном шелле провалилась и они решили взять основу идеи UNIX), здесь я ни в коем случае не хочу кого-то оскорбить, просто напомнить
функций zsh мне хватает за глаза, хоть это и «аналог bash с некоторыми улучшениями», он легок, довольно прост (для того кто не первый день работает) и функционален
P.S. у меня лимит 1 коммент за 5 минут, так что я при всем желании не могу всем ответить, к тому же какие-то тролли срут в карму уже сейчас :-))
>я вроде бы достаточно прозрачно упомянул, что bash (и другие sh) и PoweShell это разные ЭПОХИ
Разумеется! В результате у PowerShell огромный отрыв по технологиям и по изначально продуманной реализации, а у старых *nix шеллов — огромный же запас утилит на все случаи жизни.
>отличие вашего сравнения и моего состоит как раз в том, что вы видите этот продукт революционным, а я вижу старые проверенные идеи в новой оболочке
Отличие видимо в том что я знаком с обоими сторонами, а вы лишь с одной.
>P.S. у меня лимит 1 коммент за 5 минут, так что я при всем желании не могу всем ответить, к тому же какие-то тролли срут в карму уже сейчас :-))
А нечего было пытаться унизить PowerShell обладая о нем лишь поверхностными знаниями :) Если что — это не я :)
Разумеется! В результате у PowerShell огромный отрыв по технологиям и по изначально продуманной реализации, а у старых *nix шеллов — огромный же запас утилит на все случаи жизни.
>отличие вашего сравнения и моего состоит как раз в том, что вы видите этот продукт революционным, а я вижу старые проверенные идеи в новой оболочке
Отличие видимо в том что я знаком с обоими сторонами, а вы лишь с одной.
>P.S. у меня лимит 1 коммент за 5 минут, так что я при всем желании не могу всем ответить, к тому же какие-то тролли срут в карму уже сейчас :-))
А нечего было пытаться унизить PowerShell обладая о нем лишь поверхностными знаниями :) Если что — это не я :)
вы ни сказали ничего нового, равно как и не дали своих аргументов на мои ответы…
я прекрасно вижу что умеет PowerShell и следил за новостями о его разработке с тех самых пор, как эта разработка началась
в качестве ответа на то, что умеет zsh предлагаю вам посетить ссылку rayninfo.co.uk/tips/zshtips.html
с моей стороны глупо было бы даже упоминать на сколько невероятно преимущество zsh 1990 года «выдержки» над PowerShell, а с вашей писать неаргументированно что-либо еще :-)
я прекрасно вижу что умеет PowerShell и следил за новостями о его разработке с тех самых пор, как эта разработка началась
в качестве ответа на то, что умеет zsh предлагаю вам посетить ссылку rayninfo.co.uk/tips/zshtips.html
с моей стороны глупо было бы даже упоминать на сколько невероятно преимущество zsh 1990 года «выдержки» над PowerShell, а с вашей писать неаргументированно что-либо еще :-)
Zsh обладает огромным количеством возможностей и как язык — но мне всегда почему-то стрёмно их использовать в скриптах :-) Наверное, из ранних наущений «всегда пиши так, чтобы было совместимо! всегда вверху ставь #!/bin/sh» :-)
По качеству интерактива, конечно, zsh уделывает PowerShell как котёнка — здесь нет никаких возражений.
По качеству интерактива, конечно, zsh уделывает PowerShell как котёнка — здесь нет никаких возражений.
Например? ;)
Вы это кстати видели? :)
Вы это кстати видели? :)
PowerTab мне показался каким-то «липким», медленновато отрисовывает свои попапы, плюс эта рамочка уродская. В zsh это выглядит более правильно, с моей точки зрения эмаксера.
Кроме того, там, по-моему, так и не решили проблему редактирования многострочных команд из хистори. Т.е. если я ввожу команду 1, потом копипащщу текст функции 2, а затем хочу вернуться по хистори к команде 1, то мне придётся прощёлкать вверх все строки функции 2.
Кроме того, там нет Ctrl+R.
Правда, вполне допускаю, что сейчас это уже поправили — было бы хорошо.
Кроме того, там, по-моему, так и не решили проблему редактирования многострочных команд из хистори. Т.е. если я ввожу команду 1, потом копипащщу текст функции 2, а затем хочу вернуться по хистори к команде 1, то мне придётся прощёлкать вверх все строки функции 2.
Кроме того, там нет Ctrl+R.
Правда, вполне допускаю, что сейчас это уже поправили — было бы хорошо.
>PowerTab мне показался каким-то «липким»
Нуу… Есть куча альтернативных оболочек для PS еще. Там обычно интеллисенс как в VS. А рамочка включается/отключается/настраивается легко.
>Т.е. если я ввожу команду 1, потом копипащщу текст функции 2, а затем хочу вернуться по хистори к команде 1, то мне придётся прощёлкать вверх все строки функции 2.
Да, есть такое, это правда не проблема PowerTab и PowerShell. Это всё та же старая обертка для утилит командной строки которую использует cmd.exe. Если использовать любую другую оболочку, тот же ISE написанный специально для PS, то таких проблем не возникнет.
Нуу… Есть куча альтернативных оболочек для PS еще. Там обычно интеллисенс как в VS. А рамочка включается/отключается/настраивается легко.
>Т.е. если я ввожу команду 1, потом копипащщу текст функции 2, а затем хочу вернуться по хистори к команде 1, то мне придётся прощёлкать вверх все строки функции 2.
Да, есть такое, это правда не проблема PowerTab и PowerShell. Это всё та же старая обертка для утилит командной строки которую использует cmd.exe. Если использовать любую другую оболочку, тот же ISE написанный специально для PS, то таких проблем не возникнет.
Пустую страницу? Много раз.
У Вас там расширение для SWF-ки дважды прописано вперемешку с .html ;)
И что же в нём есть такое, чего нету в ipython?)
и на мой взгляд про zsh в топике упоминать не стоило, PowerShell это как планета в галактике zsh
А разве zsh как-то принципиально изменил парадигму того же bash? Имхо, это просто горизонтальный рост. Powershell — в большей степени вертикальный. Во-первых, вместо разноперых утилит, которые мы наблюдали в %windir%\system32 стала органичная система коммандлетов с четкими гайдлайнами и ООП-организацией, что с легкостью позволяет создавать новые команды, осуществляя реюзинг старых. Во-вторых, это мощный бэкграунд, как языковой в лице c#, так и библиотечный в лице FCL. С ним по силами сражаться питону, но скриптовым языкам будет тяжеловато, ибо другая весовая категория. Плюс добавлена мощная динамика в рантайме. Сможет zsh оперировать с XML, например, в таком стиле: "$doc.rootnodename.somenodename.childnonename"? В третьих — это часто упоминаемый объектный пайп. Точне, дело не столько в пайпе, а в том, что все есть объекты, в пайпе они или без оного. Я бы не сказал, что все эти части представляют из себя что-то инновационное. Но аналогичных продуктов, которые столь гармонично бы в себя вобрали практически все лучшее я пока не знаю.
я не понимаю, вы идеолог или ИТ-спец? Мне совершенно параллельно кто какую парадигму изменил, или наоборот не изменил. Мне удобно — я пользуюсь, не удобно — соответственно. Я сильно сомневаюсь, что теми идеями, которые вы сейчас изложили, вы пользуетесь в жизни… Вы покупаете новые штаны не потому, что они вам нравятся или подходят, а исключительно потому что это новая парадигма в изготовлении штанов? Всего в паре задач мне приходилось подключать скриптовые языки, да и то по незнанию sed/awk, массив текста, с которым оперирует *sh здорово обрабатывать perl'ом.
И еще, вы вот упоминаете про объекты, а для чего они мне? Какая полезная нагрузка? Чего я не мог делать раньше, когда у меня не было объектов? Такое ощущение, что это спасительная гавань в диалоге.
Ну и еще, PowerShell это безусловно новое и полезное явление на win платформах, но я думаю что относиться надо к этому соответственно, а не кричать о революциях и попытках изменить орбиту Земли :-)
И еще, вы вот упоминаете про объекты, а для чего они мне? Какая полезная нагрузка? Чего я не мог делать раньше, когда у меня не было объектов? Такое ощущение, что это спасительная гавань в диалоге.
Ну и еще, PowerShell это безусловно новое и полезное явление на win платформах, но я думаю что относиться надо к этому соответственно, а не кричать о революциях и попытках изменить орбиту Земли :-)
я не понимаю, вы идеолог или ИТ-спец? Мне совершенно параллельно кто какую парадигму изменил, или наоборот не изменил. Мне удобно — я пользуюсь, не удобно — соответственно. Я сильно сомневаюсь, что теми идеями, которые вы сейчас изложили, вы пользуетесь в жизни…
Я — практик. Говорю о том, что использую. Например, буквально пару недель назад связал powershell с MS UI automation. Теперь могу автоматизировать UI-операции в таком стиле:
New-Window "$root\app.exe" | Get-Window -Name "Next >" -ControlType Button | Send-Window -Click $window | Wait-Window -Name "Some question?" -ControlType CheckBox | Send-Window -Toggle $window | Get-Window -ControlType Tree | Get-Window -ControlType TreeItem -Name "Folder" | Send-Window -Expand | Find-Window -ControlType TreeItem -Name "Item" | Send-Window -MouseClick
Как бы вы решали подобную задачу на zsh?
И еще, вы вот упоминаете про объекты, а для чего они мне? Какая полезная нагрузка? Чего я не мог делать раньше, когда у меня не было объектов? Такое ощущение, что это спасительная гавань в диалоге.
А вы посмотрите на статистику использования grep/awk для того чтобы выдернуть какие-нибудь свойства из текста, тогда может ситуация проясниться. Я вот только никак в толк не возьму, вы на самом деле думаете что сериализация+передача по пайпу+десериализация- это круче чем просто передача по пайпу? Что передача объекта, частным случаем которого является строка — это хуже, чем передача строки? Что вызов $someapp.Uninstall() по определению ущербен?
Ну и еще, PowerShell это безусловно новое и полезное явление на win платформах, но я думаю что относиться надо к этому соответственно, а не кричать о революциях и попытках изменить орбиту Земли :-)
На win-платформе это по определению революция :) Как все это выглядит на Unix-платформах я знаю очень мало, поэтому мне интересны примеры. На одном форуме холиварили с адекватными линуксоидами, было немало примеров и масса интересного для обоих сторон. К сожалению здесь заменили здоровый соревновательный дух неаргументированным загаживанием кармы.
>Как бы вы решали подобную задачу на zsh?
Таки задачи бывают только в windows, у нас всё можно сделать через консоль, не прибегая к таким костылям =)
Таки задачи бывают только в windows, у нас всё можно сделать через консоль, не прибегая к таким костылям =)
Да ладно, всё. Сделайте мне удобную сложную, иерархическую форму ввода данных через консоль, пожалуйста.
$ some_util -u nvbn -q lololo -a bbbbb
password:
Или:
$ some_util --user nvbn --qqqq asdasd --auth bbbbb
Чем не сложная форма?)
password:
Или:
$ some_util --user nvbn --qqqq asdasd --auth bbbbb
Чем не сложная форма?)
Пример сложной формы. Необходимо ввести результаты тренировки за день. Что нужно ввести: 1) дата; 2) информацию о выполненных упражнениях; 3) комментарий. Информация о выполненных упражнениях — это массив, где каждый элемент содержит следующую информацию: 1) название упражнения (выбирается из списка); 2) информация о подходах. Информация о подходах — это массив, где каждый элемент содержит следующую информацию: 1) отягощение; 2) количество повторений.
Вот это — сложная форма.
Вот это — сложная форма.
Вы определитесь с целью для начала. Что является источником информации? Её должен вводить человек?
Всю эту информацию при желании можно закодировать в командной строке или через стандартный ввод в каком-нибудь формате запихать (например, JSON или XML) в наше консольное приложение. А для человека можно сделать отдельную формочку в отдельном приложении (фронт-энд), чтобы он мог ввести в поля значения и нажать кнопку, что будет приводит к запуску консольной утилиты.
Если источник не человек, тогда и форму не надо — всё через консоль.
Всю эту информацию при желании можно закодировать в командной строке или через стандартный ввод в каком-нибудь формате запихать (например, JSON или XML) в наше консольное приложение. А для человека можно сделать отдельную формочку в отдельном приложении (фронт-энд), чтобы он мог ввести в поля значения и нажать кнопку, что будет приводит к запуску консольной утилиты.
Если источник не человек, тогда и форму не надо — всё через консоль.
пипец :) Вы меня простите великодушно, но это пипец. Теперь я наконец осознал, как делаются холивары:
AlexeyK: вы сраный идеолог!
Guderian: я — практик. Вот тут, например, тестирование GUI автоматизировал.
nvbn: тестирование GUI нужно только в Windows, нам оно не нужно, мы всё можем сделать через консоль.
uj2: ага, ну сделайте мне сложную форму ввода.
nvbn: пыщь-пыщь.
uj2: ваша форма ввода говно. Вот такую сделаете?
cy6erGn0m: ваш подход — говно, должно быть разделение на фронтенд и бакенд.
Простите, но я, наверное, не буду в этом участвовать :-)
AlexeyK: вы сраный идеолог!
Guderian: я — практик. Вот тут, например, тестирование GUI автоматизировал.
nvbn: тестирование GUI нужно только в Windows, нам оно не нужно, мы всё можем сделать через консоль.
uj2: ага, ну сделайте мне сложную форму ввода.
nvbn: пыщь-пыщь.
uj2: ваша форма ввода говно. Вот такую сделаете?
cy6erGn0m: ваш подход — говно, должно быть разделение на фронтенд и бакенд.
Простите, но я, наверное, не буду в этом участвовать :-)
>> cy6erGn0m: ваш подход — говно, должно быть разделение на фронтенд и бакенд.
Вы сами это написали. Если считается, что приложение должно иметь возможность быть автоматизированным, то у него должен быть чёткий API, например, через интерфейс командной строки. Если считается, что его не надо автоматизировать, то и не надо никакого бэк-энда, но тогда и дёргать за ниточки его не нужно.
Вы сами это написали. Если считается, что приложение должно иметь возможность быть автоматизированным, то у него должен быть чёткий API, например, через интерфейс командной строки. Если считается, что его не надо автоматизировать, то и не надо никакого бэк-энда, но тогда и дёргать за ниточки его не нужно.
>nvbn: тестирование GUI нужно только в Windows, нам оно не нужно, мы всё можем сделать через консоль.
Тестировать гуй нужно предназначенными для этого штуками, не надо меня переверать, а то ебальник разобью!
Тестировать гуй нужно предназначенными для этого штуками, не надо меня переверать
Отсутствие возможности обратиться к приложению напрямую и приводит к необходимости «дёргать UI за ниточки» через PS.
О да… монолитные программы рулят. Дайвайте убьём главную идею Unix.
Возникает вопрос: зачем _скрипту_ сложная иерархическая форма ввода данных?
Удобные, иерархические формочки были придуманы для пользователей. А Вы, получается, хотите заменить поток данных на некую юзер-френдли структуру, а затем с этой структурой снова работать как с потоком данных.
Хотите формочки — TCL/TK/perl+gtk/что-то ещё. Из них пользовательские данные великолепно укладываются в текст (можно json нагенерить, можно cvs, что душе угодно), с которым потом можно работать.
Не хотите формочек — передавайте данные сразу в обход UI.
Удобные, иерархические формочки были придуманы для пользователей. А Вы, получается, хотите заменить поток данных на некую юзер-френдли структуру, а затем с этой структурой снова работать как с потоком данных.
Хотите формочки — TCL/TK/perl+gtk/что-то ещё. Из них пользовательские данные великолепно укладываются в текст (можно json нагенерить, можно cvs, что душе угодно), с которым потом можно работать.
Не хотите формочек — передавайте данные сразу в обход UI.
А что вопросы автоматизации тестирования GUI-приложений стоят только под винду? Вы их не тестируете? Или делаете это руками?
Тестирую средствами qt
Не надо смешивать всё в кучу. Для тестирования UI сущестуют специальные инструменты и никто не будет применять shell чтобы тестировать UI.
Я эти скрипты для тестирования и не использую. Так, повседневные задачки и некоторая другая мелочевка. Просто появился конкретный тезис, что мол unix'ам автоматизация UI не нужна: «Таки задачи бывают только в windows, у нас всё можно сделать через консоль, не прибегая к таким костылям =)». Я привел в качестве примера категорию таковых задач. Пример же реализации на повершелле отвечал на другой тезис, что я исключительно теоретик.
Вообще общение интересное складывается. Когда на Summer Code 2007 демонстрировали автоматизацию FireFox на Linux'е, то кругом только и было, что wonderful job. А теперь эта автоматизация вроде как и не нужна никому. Интересно, если бы я привел пример по работе с RSS, мне наверно сказали бы, что это нафиг не нужно ибо есть куча замечательных приложений по работе с ним, да только весь хабр истыкан примерами, как это здоров делается в линуксовом шелле :)
Вообще общение интересное складывается. Когда на Summer Code 2007 демонстрировали автоматизацию FireFox на Linux'е, то кругом только и было, что wonderful job. А теперь эта автоматизация вроде как и не нужна никому. Интересно, если бы я привел пример по работе с RSS, мне наверно сказали бы, что это нафиг не нужно ибо есть куча замечательных приложений по работе с ним, да только весь хабр истыкан примерами, как это здоров делается в линуксовом шелле :)
Автоматизация средствами приложения и тулкитозависимый костыль — разное.
Это вы про линуксовые LDTP, dogtail и т.п.?
Это я про повершел и виндоуз
И кто из них «тулкитозависимый костыль»? Дайте догадаюсь — windows в целом?)
Шняга для тыканья по кнопочкам в дотнете через повершел *НЕОЖИДАННО*
А для чего я упомянул ранее LDTP, dogtail и т.п. не дошло? Или приложения, их использующие — не «тулкитозависимые»? То, что не костыли я знаю точно, это только убогие вроде меня пишут шняги под винду, ну а вы, конечно, бох :) Посмотрел задачки в вашем блоге, куда уж мне :)
>LDTP, dogtail
Я их не использовал, поэтому говорить не буду
>Посмотрел задачки в вашем блоге, куда уж мне :)
О_о, дайте плз ссылку на мой болжек =)
Я их не использовал, поэтому говорить не буду
>Посмотрел задачки в вашем блоге, куда уж мне :)
О_о, дайте плз ссылку на мой болжек =)
Вы меня заинтриговали, мне ж интересно себя почитать)
nvbn.habrahabr.ru/blog/ — сюрприз, да? ;)
Автоматизация Firefox — это замечательно, это полезно. Опять же, для тестирования, например, Selenium. Автоматизация ЛЮБЫХ приложений — в общем случае, это неплохо, но польза не очевидна и явно, что это не самое полезное, что умеет PS. Хотя, конечно, всегда лучше мочь, чем не мочь.
Вы совершенно правы. Просто данная конкретная задача встала лично передо мной. Мне нужно было что-то вроде Spy++, но с возможностями скриптования. В повершелле я ее решил быстро и на 200% для своих целей. Думаю всем нам другого от шеллов и не нужно. Пример этот я привел в ответ на обвинение в том, что я исключительно теоретик. Честно говоря, я думал, что коллеги девелоперы найдут использование пайпов для автоматизации оконного интерфейса, как минимум, прикольным. К сожалению на все есть один весомый контраргумент «нам это не нужно». Жаль, что никто не приводит примеры того, что вам нужно. Даже если бы это мне было совсем не нужно, то я бы попробовал решить чисто из спортивного интереса :)
Возможно, можно пытаться использовать power shell для тестирования в случае, если нет другого выбора, на безрыбье и рак — рыба. В той же яве есть несколько средств тестирования UI, например, Jemmy. Я точно знаю, что в .NET тоже есть пара средств тестирования UI (к сожалению не помню названий, но видел презентацию на эту тему). Зачастую применение специализированных средств бывает более удобно и часто переносимее. Я извиняюсь, что я опять про яву, однако, например, тесты на Jemmy я могу гонять на винде, линухе и т.д. Если же я буду использовать PS, то тестиовать UI будет возможно только на винде. Если бы я писал на Qt и C++, то опять та же фигня. Не делать же для разных платформ разные тесты.
Единственный тезис, в котором я полностью с вами согласен, это тезис про карму :-)
Проблема в том, что под никсами нет MS UI, отсюда и другие задачи
я могу вам показать насколько проще слушать радио в никсах (пример подсказал один давний знакомый), просто чтобы не скатываться к голословию :-)
wget -t 0 -T 15 -O — «radiostream» | lame --mp3input --decode /dev/stdin — | aplay
все просто и понятно, текста нет, есть звуковые данные, с ними получается довольно нормально работать и без объекта
я безусловно рад, что на win платформе революция, искренне рад, НО есть одно «но», это безопасность… и с ней (сорри за оффтоп, но опустить вопрос довольно сложно) у MS проблемы, PowerShell дает такую массу преимуществ и новых «парадигм» ($someapp.Uninstall() и т.п.) не только администраторам, но и хакерам, что я просто диву даюсь
Проблема в том, что под никсами нет MS UI, отсюда и другие задачи
я могу вам показать насколько проще слушать радио в никсах (пример подсказал один давний знакомый), просто чтобы не скатываться к голословию :-)
wget -t 0 -T 15 -O — «radiostream» | lame --mp3input --decode /dev/stdin — | aplay
все просто и понятно, текста нет, есть звуковые данные, с ними получается довольно нормально работать и без объекта
я безусловно рад, что на win платформе революция, искренне рад, НО есть одно «но», это безопасность… и с ней (сорри за оффтоп, но опустить вопрос довольно сложно) у MS проблемы, PowerShell дает такую массу преимуществ и новых «парадигм» ($someapp.Uninstall() и т.п.) не только администраторам, но и хакерам, что я просто диву даюсь
Единственный тезис, в котором я полностью с вами согласен, это тезис про карму :-)
Жалко, что единственный, но карму апну :)
все просто и понятно, текста нет, есть звуковые данные, с ними получается довольно нормально работать и без объекта
В приведенной задаче — да. А теперь просто введите awk в поиск на хабре и узнайте о том, что существуют другие задачи ;)
я безусловно рад, что на win платформе революция, искренне рад, НО есть одно «но», это безопасность… и с ней (сорри за оффтоп, но опустить вопрос довольно сложно) у MS проблемы, PowerShell дает такую массу преимуществ и новых «парадигм» ($someapp.Uninstall() и т.п.) не только администраторам, но и хакерам, что я просто диву даюсь
Фишка в том, что CLR, в котором исполняется повершелл и который рулит управляемым кодом совершенно толерантен к большинству атак.
>совершенно толерантен к большинству атак
прям таки getthefacts
прям таки getthefacts
Поделитесь, как вы сделаете управляемому коду stack overlfow, например? А за getthefacts я обычно хожу на secunia.com. Я в чем-то не прав?
Я не «хакер», а под гетзефактс имелось ввиду — www.microsoft.com/windowsserver/facts/default.mspx?R=cf
Во-первых, не всё .NET-окружение — управляемый код. Всегда есть большие нативные куски. Опыт явы не раз доказывал, что даже очень маленькие нативные вставки порой приподносят сюрпризы.
Во-вторых, не все уязвимости связаны с переполнением стэка.
Во-вторых, не все уязвимости связаны с переполнением стэка.
Никаких «больших нативных кусков» нет. Не верите — посмотрите исходники. Unsafe кода в FCL очень мало, в повершелле его нет вообще.
С переполнением стека связано подавляющее большинство эксплоитов, к остальным уязвимостям доступа к памяти также толерантна. Инъекцию сделать в подписанную библиотеку с командлетами или подписанный скрипт нереально. Sql-инъекции, XSS и многое другое по понятным причинам не рассматриваю.
С переполнением стека связано подавляющее большинство эксплоитов, к остальным уязвимостям доступа к памяти также толерантна. Инъекцию сделать в подписанную библиотеку с командлетами или подписанный скрипт нереально. Sql-инъекции, XSS и многое другое по понятным причинам не рассматриваю.
Мало, однако он есть. В яве тоже очень мало нативного кода, однако, он обязательно есть — без него никак.
Кроме того, очень важно не забывать про JIT-компилятор, который тоже не может быть идеальным, так что можно попытаться поискать уязвимости в нативном коде, который генерирует JIT-компилятор (или AOT, в данном случае не имеет значения).
А по поводу патчей бинарников — это вообще сложновыполнимая задача, а на юниксах в особенности, да и на правильно настроенной винде тоже.
Кроме того, очень важно не забывать про JIT-компилятор, который тоже не может быть идеальным, так что можно попытаться поискать уязвимости в нативном коде, который генерирует JIT-компилятор (или AOT, в данном случае не имеет значения).
А по поводу патчей бинарников — это вообще сложновыполнимая задача, а на юниксах в особенности, да и на правильно настроенной винде тоже.
Естественно, CLR написан на C/C++, разумеется FCL нередко обращается к реализации WinAPI, но в исходном тезисе речь шла о том, что де повершелл нагнетает проблемы с безопасностью, а это не так, ибо управляемое приложение априори менее подвержено атакам, чем аналогичное неуправляемое.
С точки зрения выполняемого кода да. Рискну предположить, что речь шла не об этом, а о недостаточно строгих политиках безопасности и т.п.
Контекст безопасности существует вне повершелла, последнему остается только ему соответствовать. Никакой эскалации системных привелегий он для себя не подразумевает.
Немного не в теме того, как в .NET работают политики безопасности, так что не могу ничего по существу сказать.
В то же время, я помню, что можно было тягать ActiveX-компоненты из .NET. Этих компонентов много и в них сосредоточено очень большое количество уязвимостей (судя по базам уязвимостей). Как результат — эффект от безопасности виртуальной машины существенно снижается. Атакующему нужно только придумать, а как же ему скормить ActiveX в пасть PS.
В то же время, я помню, что можно было тягать ActiveX-компоненты из .NET. Этих компонентов много и в них сосредоточено очень большое количество уязвимостей (судя по базам уязвимостей). Как результат — эффект от безопасности виртуальной машины существенно снижается. Атакующему нужно только придумать, а как же ему скормить ActiveX в пасть PS.
Активация COM-объектов не осуществляется ни в повершелле ни в.НЕТ. Т.е. если доступ к этому объекту политикой безопасности запрещен для рассматриваемого контекста безопасности, то доступ к нему вы не получите не из повершелла, не из любого другого.НЕТ приложения, если, конечно, явно не будете менять этот контекст на другой (с указанием логина, пароля соответственно).
Каковы настройки безопасности на «нулёвой» desktop тачке? Нужто обычному пользовательскому приложению на .NET запрещено использовать ActiveX?
Настройки безопасности для какого ActiveX-объекта? Они, знаете ли, разные могут быть. Еще раз поясню,.НЕТ-приложение не занимается активацией ActiveX-объектов. Если вы зайдете в Component Services, например, и запретите кому-то активировать какой-то ActiveX-объект, то он не сможет его активировать ни в повершелле, ни в.НЕТ-приложении, ни в JS, ни в MS Word, Ни где-либо еще.
А, так значит по умолчанию всем всё можно. В таком случае, что запрещает злоумышленнику создать такой ActiveX-объект (воспользовавшись ещё какой-нибудь плюшкой из PS), а потом поэксплуатировать уязвимость в нём?
«Всем все можно» — это вывод из фразы о том, что настройки безопасности могут различаться для разных объектов?
Третий раз поясняю. Доступ определяется контекстом безопасности в котором работает и сам повершелл. Если пользователь имеет права на активацию ActiveX-объекта — ему для этого не нужен повершелл. Если не имеет — то запусти хоть сто повершеллов, он его не получит.
Третий раз поясняю. Доступ определяется контекстом безопасности в котором работает и сам повершелл. Если пользователь имеет права на активацию ActiveX-объекта — ему для этого не нужен повершелл. Если не имеет — то запусти хоть сто повершеллов, он его не получит.
есть разница между толенрантностью на словах и на деле, что часто не совпадает у MS, но это не в ваш огород :-)
>> Теперь могу автоматизировать UI-операции в таком стиле:
New-Window "$root\app.exe" | Get-Window -Name «Next >» -ControlType Button | Send-Window -Click
$window | Wait-Window -Name «Some question?» -ControlType CheckBox | Send-Window -Toggle
$window | Get-Window -ControlType Tree | Get-Window -ControlType TreeItem -Name «Folder» | Send-Window -Expand | Find-Window -ControlType TreeItem -Name «Item» | Send-Window -MouseClick
А как бы вы стали автоматизировать UI, если приложение не написано на .NET и, быть может, вообще все свои элементы управления самостоятельно рисует? (java? qt?)?
New-Window "$root\app.exe" | Get-Window -Name «Next >» -ControlType Button | Send-Window -Click
$window | Wait-Window -Name «Some question?» -ControlType CheckBox | Send-Window -Toggle
$window | Get-Window -ControlType Tree | Get-Window -ControlType TreeItem -Name «Folder» | Send-Window -Expand | Find-Window -ControlType TreeItem -Name «Item» | Send-Window -MouseClick
А как бы вы стали автоматизировать UI, если приложение не написано на .NET и, быть может, вообще все свои элементы управления самостоятельно рисует? (java? qt?)?
Вообще оно автоматизирует любое приложение, которое использует стандартное апи. В том числе, qt и java. Собственная отрисовка не является ничем зазорным, главное грамотно регистрировать оконные классы и т.п. Если уж кто-то свихнулся и изобрел свой велосипед то можно просто эмулировать движение мыши, клики и т.п.
Да вот в том-то и дело, что никто не обязан ничего регистрировать. Java, в частности, делает это только для AWT, а она уже, мягко говоря, устарела. Есть ещё SWT, но на ней далеко не всё написано. Возьмите любое приложение на яве и попробуйте из него выудить что-нибудь — получите шыш.
Насчёт Qt не уверен в том, как он действует на винде, но тоже велик шанс, что никакие ресурсы внутри окна не ригистрируются (попробуйте, например, на опере испытать).
Насчёт Qt не уверен в том, как он действует на винде, но тоже велик шанс, что никакие ресурсы внутри окна не ригистрируются (попробуйте, например, на опере испытать).
Попробовал на Opere и на Vuze (ex. Azureus). Все работает.
Vuze использует SWT — вам просто повезло. Попробуйте, например, jedit.
А вот он не работает, нашел только рудименты от стандартного окна :)
Много приложений на яве, особенно мелких, используют swing (т.к. он стандартен и идёт на борту с явой), а swing не регистрирует ресурсы. И это во многом правильно, т.к. ресурсы эти приложению не нужны, а отслеживать нативные ресурсы — это лишняя работа, в то время как преимуществ никаких (ни для приложения, ни для jvm).
Скажем так, создавая приложение для какой-то среды, я бы старался привести его в соответствие с гайдлайнами этой среды без аргументации, что это лишняя работа. Но это лично моя практика разработки. В конкретном рассматриваемом примере они уже проделывали эту лишнюю работу для AWT/SWT. Ребят из экс Trolltech это тоже не напрягло.
Эта работа не только лишняя. Она потенциально вредная, тогда как потенциальные преимущества туманны.
Т.е. если соответствие стандартам, гайдалайнам и другим принципам требует лишней работы, то им можно не соответствовать? Если, например, для девелопера на Java основным рабочим место является Windows, то использовать для тестирования swing-приложения он может использовать только несколько эксклюзивных тестсьютов для Swing, весь остальной рынок данных средств проходит мимо него? Как впрочем и рынок приложений для Unix?
Остальной рынок… а какой это? Кто? Зачем он нужен, если есть специальные инструменты? Если эти инструменты на что-то претендуют, то пускай делают поддержку для явы, т.к. генерализованные методы всё равно не годятся никуда — в мире существуют не только кнопки и поля ввода. Ну получите вы объект окна текстового редактора в NetBeans, например. Ну и что вы будете с ним делать? Использую обощённые средства вы всё равно ничего с ним сделать не сможете.
Java соответствует стандартам. Создание ресурсов для всего, что ни попадя (кнопки, и т.п.) — не является стандартом, а лишь средством. Просто яве они не нужны ни для чего, в то время как для AWT и SWT они необходимы, а свингу они ни к чему. Кроме того, отсутствие таких сущностей полезно для переносимости кода (хотя бы, самого свинга).
Java соответствует стандартам. Создание ресурсов для всего, что ни попадя (кнопки, и т.п.) — не является стандартом, а лишь средством. Просто яве они не нужны ни для чего, в то время как для AWT и SWT они необходимы, а свингу они ни к чему. Кроме того, отсутствие таких сущностей полезно для переносимости кода (хотя бы, самого свинга).
Опять же, из первого моего абзаца следует, что польза туманна, а вред возможен.
Если следовать этой логике, то Qt/AWT/SWT писали идиоты, которые стремились нанести «вред». И только Swing писали боги :) Странно, но я могу разрабатывать под Qt/WPF/WinForms/VCL и использовать тот инструмент, что мне нравится, а не заучивать для каждого свой. Но это, естественно, идиотской желание. Если я, например, привык использовать Ranorex для тестирования Qt/WPF/Flash/Silverlight, то для Swing единственно верным способом будет использовать что-то другое. Честно скажу, мне такая логика не совсем понятна.
Кажется, я объяснил причину. Ещё раз: если даже вы сможете получить идентификатор окна какого-нибудь сложного компонента, то вам от этого идентификатора нет никакого проку. Поэтому применение обощённых средств тестирования невозможно. Нужны специализированные средства. Qt это тоже касается. Недостаточно убедиться в существовании компонента и возможности нажать на него — необъходимо ещё знать что-то о его внутреннем состоянии, иначе от теста никакого толку.
Вообще, я с трудом представляю себе такую автоматизацию. Чуть кнопку переименовали, переместили в другой контейнер или ещё чего — сразу всё повалится. Разве что для своих приложений… для тестирования, например. Вот только зачем для тестирования использовать PS, если есть специализированные средства для этого?
не уверен насчёт качества и полноты продукта, но уже есть что-то подобное под моно — pash.sf.net
В powershell по pipe идут объекты, в распространённых шелах под Unix — текст. Это очень сильное различие.
ну прежде всего, и так всем ясно, откуда взяты основные идеи PowerShell, я и не говорил, что это совершенно разные вещи :-)
Насчёт пользователя MS, который никогда не работал под *NIX — это неверно; хоть мне и нечем особо похвастаться, но я довольно давно и неплохо знаком с Linux и скриптингом под него :-)
Насчёт пользователя MS, который никогда не работал под *NIX — это неверно; хоть мне и нечем особо похвастаться, но я довольно давно и неплохо знаком с Linux и скриптингом под него :-)
тогда непонятно как вы сравниваете, и почему именно с zsh?
любой шелл (тот же bash) в линукс, точно так же как и zsh — выполняет роль загрузчика и интерпретатора скриптов для команд окружения. без этого окружения возможно линукс-shell'ы не представляют собой чегото экстраординарного. Но в тесной интеграции среды и шелла — проявляется вся красота и польза. Например, файлы устройств, один только чего стоят в сумме с пайпами шелла!
Подобного сибмиоза шелла и среды никогда не будет в windows в силу архитектурного органичения. (ну или майкрософту надо все переписать с нуля вернувшись к *nix парадигме)
любой шелл (тот же bash) в линукс, точно так же как и zsh — выполняет роль загрузчика и интерпретатора скриптов для команд окружения. без этого окружения возможно линукс-shell'ы не представляют собой чегото экстраординарного. Но в тесной интеграции среды и шелла — проявляется вся красота и польза. Например, файлы устройств, один только чего стоят в сумме с пайпами шелла!
Подобного сибмиоза шелла и среды никогда не будет в windows в силу архитектурного органичения. (ну или майкрософту надо все переписать с нуля вернувшись к *nix парадигме)
Хотя набор команд и похож, но концептуально PS кардинально отличается от юниксового шелла. Просто ребята из MS решили взамен старого игрушечного шелла сделать новый с чистого листа, и взяли отовсюду самое лучшее, что, кстати, получилось довольно неплохо.
фразой «старый игрушечный шелл» вы накликали на себя ярость сотен тыщ юниксоидов и линуксоидов :-)
А также вечное проклятие святого иГНУсия ;-)
Боже упаси! Я имел в виду виндовый cmd.exe =)
>по-моему здесь нет ничего, чего нет в UNIX shell
Объектный пайп? ;)
>во-первых всем ясно откуда пошел PowerShell
В частности авторы PowerShell очень уважают Perl. Ну и разумеется он унаследовал много хорошего и из других языков. Постоянно слышу фразы «да они же содрали [perl|php|c#|java|bash|...]» ;)
>пресловутые «алиасы» лишнее тому доказательство
А вот если вы считаете алиасы доказательством к чему то — вы знаете PowerShell очень поверхностно. Алиасы только для удобства перехода, а на самом деле мало похожи на любые аналоги. Тот же Get-ChidItem в отличии от dir и ls выдает не текст со списком файлов, а массив объектов, что в корне меняет принципы работы (в лучшую сторону разумеется ;) )если немного углубиться.
>вообще топик напоминает радость пользователя MS, который никогда не работал под *NIX :-)
Ваше сообщение достаточно однозначно идентифицирует вас как человека лишь «слышавшего» о PowerShell :) Те пользователи/админы/программисты *NIX кто действительно ознакомился о PowerShell говорят совсем иначе :)
Объектный пайп? ;)
>во-первых всем ясно откуда пошел PowerShell
В частности авторы PowerShell очень уважают Perl. Ну и разумеется он унаследовал много хорошего и из других языков. Постоянно слышу фразы «да они же содрали [perl|php|c#|java|bash|...]» ;)
>пресловутые «алиасы» лишнее тому доказательство
А вот если вы считаете алиасы доказательством к чему то — вы знаете PowerShell очень поверхностно. Алиасы только для удобства перехода, а на самом деле мало похожи на любые аналоги. Тот же Get-ChidItem в отличии от dir и ls выдает не текст со списком файлов, а массив объектов, что в корне меняет принципы работы (в лучшую сторону разумеется ;) )если немного углубиться.
>вообще топик напоминает радость пользователя MS, который никогда не работал под *NIX :-)
Ваше сообщение достаточно однозначно идентифицирует вас как человека лишь «слышавшего» о PowerShell :) Те пользователи/админы/программисты *NIX кто действительно ознакомился о PowerShell говорят совсем иначе :)
по-моему здесь нет ничего, чего нет в UNIX shell, во-первых всем ясно откуда пошел PowerShell, пресловутые «алиасы» лишнее тому доказательство, во-вторых некоторые программы (команды) существуют по 30 лет, логично что они не оперируют объектами
по-моему здесь нет ничего, чего нет в UNIX shell, во-первых всем ясно откуда пошел PowerShell, пресловутые «алиасы» лишнее тому доказательство, во-вторых некоторые программы (команды) существуют по 30 лет, логично что они не оперируют объектами
А UNIX shell такжу имеет провайдер для управления алиасами, как Powershell? ;)
«провайдер управления алиасами» в *sh именуется до смешного просто «alias»
И он также умеет привычными командами удалять эти алиасы, скопировать на другой хост, переименовать и т.п.? Или мне надо освоить очередной набор ключей командной строки?
скопируйте на другой хост .bashrc и пользуйтесь сколько угодно…
для zsh все алиасы доступны в каждой инстанции этого самого zsh…
для zsh все алиасы доступны в каждой инстанции этого самого zsh…
Т.е.е вместо задачи скопировать нужные мне алиасы вы предлагаете скопировать файл, а потом некоторой утилитой удалить ненужные и при этом не забыть изучить эту утилиту. Я то просто хотел
PS:\>alias: PS:\>copy ls sometarget PS:\>del somealias PS:\>move -include somemask sometarget
если у вас примонтирован ресурс, копируйте, утилит никаких знать не надо, вы или не слышите, или не хотите слышать
Отчего же, soider и nvbn поняли, в чем мой вопрос. Другое дело, что мне не удается донести информацию о таком инструменте powershell'а как провайдеры.
>Другое дело, что мне не удается донести информацию о таком инструменте powershell'а как провайдеры.
Просто такая вещь не нужна в unix системах
Просто такая вещь не нужна в unix системах
Странно, а люди которые пишут для unix виртуальные файловые системы с вами не согласны. Может вам о чем-то говорят названия devfs, procfs, sysfs?
Но причём здесь провайдер алиасов?)
Одна из возможностей провайдеров — создание виртуальных файловых систем. Alias в примере ранее — это и есть виртуальная файловая система.
Поинт юниксоидов в этой ветке в том, что применение такой большой технологии для такой простой задачи — из пушки по воробьям. Алиасы команд — это по сути очень простые сущности, а провайдеры\файловые системы — сложные.
Поинт повершелла в том, что создание провайдеров доведено до предельной простоты. Наследовал базовый провайдер, переписал нужные методы. Провайдер алиасов вместе со всеми диагностическими приблудами занимает порядка 100 строк.
Всё-равно это излишняя сложность для очень простой вещи
Правильно ли я понимаю, что procfs с исходниками далеко за 100K — это очень нужно и очень просто, а провайдер в 100К для алиасов — это сложно и абсурдно? Просто хочу понять, в какой системе координат мы ведем дискуссию.
Тьфу, провайдер в 5К :)
procfs насколько я помню умеет… «чуть чуть больше», чем отражать состояние списка алиасов.
Да, благодаря procfs, чтоб узнать где сидит модуль, мы можем сделать:
А алиасы — куда более простая вещь и всё, что можно о нём узнать — его содержимое, а оно либо выводится через alias имя или, если он не «активирован», легко грепаеться из файл, что ещё можно сделать с алиасами я не представляю
cat /proc/modules|grep sata_sis|awk '{ print $6 }'А алиасы — куда более простая вещь и всё, что можно о нём узнать — его содержимое, а оно либо выводится через alias имя или, если он не «активирован», легко грепаеться из файл, что ещё можно сделать с алиасами я не представляю
Я всегда думал, что и procfs и ps суть просто обертки вокруг функций ядра и сами реализации означенной функции они не содержат. Что до функциональности, то точно также я могу для алиасов получит модули, в которых реализованы их команды. Например
$a = gi ls #получил объект алиаса для ls $a.ResolvedCommand.DLL
Виртуальные файловые системы сделаны для того, чтобы обеспечивать доступ к каким-то рантайм данным, например, /proc/meminfo содержит информацию о памяти.
В винде разного рода виртуальные файловые системы не принято применять, а вместо них применяют всяческие API-шные решения. И их недостаток как раз в том, что доступ к ним только программный. То что PS позволяет легко обращаться к этим API — это хорошо, но в unix эта проблема не стоит, так как есть procfs, sysfs и т.п. В то же время, API-шные зеркала данных, лежащих в них также доступны.
Так что в целом преимущества никакого нет, кроме, разве что, объектности опять же, в то время как тот же /proc/meminfo надо парсить.
В винде разного рода виртуальные файловые системы не принято применять, а вместо них применяют всяческие API-шные решения. И их недостаток как раз в том, что доступ к ним только программный. То что PS позволяет легко обращаться к этим API — это хорошо, но в unix эта проблема не стоит, так как есть procfs, sysfs и т.п. В то же время, API-шные зеркала данных, лежащих в них также доступны.
Так что в целом преимущества никакого нет, кроме, разве что, объектности опять же, в то время как тот же /proc/meminfo надо парсить.
Как раз провайдеры и реализуют виртуальные файловые системы. И создавать их можно буквально в повершелле, на лету. Хочешь RSS-файловую систему — 5 минут, ХабраFS — 10 :)
В линуксах это тоже решаемо… можно использовать, например, fuse чтобы сделать свою fs. А потом фигачить данные из неё можно будет тем же grep'ом, awk и т.п.
Да. Только будет несколько сложнее. Хотя, не смотря на сложность, на fuse немало файловых систем более бесполезных чем провайдер алиасов :)
Кстати, на fuse можно было бы сделать тоже fs, которая была бы в PATH. Такие алиасы были бы намного прозрачнее, чем текстовый файл .bashrc. Тогда эти алиасы работали во всех приложениях, т.к. были бы просто бинарнками из виртуальной файловой системы. Тогда как провайдерами такого трудно добиться.
Ой, случайно удалил кусок в начале. Я хотел написать, что на fuse можно было бы сделать fs для алиасов.
Вообще-то повершелл — просто одна их хостинг сред для провайдеров. Ничто не мешает инстанцировать провайдер из другого приложения. Причем, обращаться к нему можно как к базовому провайдеру в файловом стиле, а можно скастить к конкретному типу и получить доступ к расширенными функциями, если он таковые предоставляет. К сожалению, повершелл еще очень молод, посему стандартные системные файловые диалоги и файловые операции не умеют выбирать провайдеры, посему есть и очевидные недостатки.
cat ~/.bashrc | egrep «alias (нужные|команды|через|пайп)» > tmp
scp tmp name@server:/path/tmp
и на серваке cat /path/tmp >> ~/.bashrc?
scp tmp name@server:/path/tmp
и на серваке cat /path/tmp >> ~/.bashrc?
Так легко можно перенести альясы и ничего лишнего из башрц — $(cat bashrc|grep ^alias)
И файл этот можно получить хоть по ssh, хоть с флешки
И файл этот можно получить хоть по ssh, хоть с флешки
>потом некоторой утилитой удалить ненужные и при этом не забыть изучить эту утилиту.
вам предлагают использовать штатные средства для работы с текстовыми файлами вместо изучения «провайдера управления алиасами» :)
вам предлагают использовать штатные средства для работы с текстовыми файлами вместо изучения «провайдера управления алиасами» :)
>> некоторой утилитой удалить ненужные и при этом не забыть изучить эту утилиту
Вот тут вы зря. Тот факт, что power shell оперирует объектами, а не plain text — и это большой плюс.
К сожалению, мой опыт работы с power shell -> 0, в отличие от shell, однако, некоторые простые вещи в shell делаются удивительно сложно именно из-за plain-овости. Так что, я считаю, что некоторые плюшки из power shell действительно не мешало бы добавить в nix-шеллы.
К сожалению, мой опыт работы с power shell -> 0, в отличие от shell, однако, некоторые простые вещи в shell делаются удивительно сложно именно из-за plain-овости. Так что, я считаю, что некоторые плюшки из power shell действительно не мешало бы добавить в nix-шеллы.
Вы совсем не понимаете суть PS.
Вспомните самую важную идею Unix: пайпы.
Вместо монолитных программ-комбайнов — небольшие программки, каждая из которх делает немного, но хорошо, соединённые пайпами.
Это прекрасная идея, которую неплохо реализовали *nix шеллы и плохо — DOS шелл.
В какой-то момент развитие возможностей многих *nix программ было приостановлено с целью сохранения совместимости. Многие шеллы, вроде bash не боятся нарушить POSIX, но всё-таки стараются придерживаться традиционой парадигмы. Думаю, Вы согласны со мной, так как сами пишете, что многие программы принципиально не менялись по 30 лет.
Причём тут PS?
Моё мнение такое: в упомянутой мной «идее Unix» PS пошёл дальше bash и zsh. Он может проигрывать по рюшечкам вроде автокомплита, по набору и возможностям стандартных программ (причём тут шелл?) и т.д. Но идея пайпов в PS реализована более полно, чем в Bash (возможно, на том же уровне, что и ipython).
Приведу два примера. Технический и Ваш пример с радио («wget -t 0 -T 15 -O — «radiostream» | lame --mp3input --decode /dev/stdin — | aplay „):
1) В Bash я очень активно пользуюсь пайпами. “Этажерки» вызовов иногда достигают десятка. Давайте подумаем, с программистской точки зрения, что при этом происходит.
Каждая команда:
Читает символы из stdin.
Разбивает по концам строк.
Разбивает строки по разделителям.
Парсит данные вроде цифр.
Делает работу.
Сериализует результаты в текст.
Форматирует вывод и отправляет его в stdout.
Умножить на 10. Если Вы программист, Вам должно стать противно от вида этой картины.
В PS не нужно постоянно сериализовывать/десериализовывать/форматировать/парсить текст. Какое-нибудь поле, возникшее в момент начального парсинга файла, может всё оставшееся время просуществовать в виде ссылку на строку, а не копироваться по 40 раз.
2) Вы привели хороший пример с звуковыми данными. Как раз в такого рода задачах хорошо виден потенциал PS.
Вы показали пример, как в *nix шелле можно обойтись без объектов при передаче нетекстовой информации. Прекрасно. Тем не менее, это а) редкость и б) всё равно не даёт всех возможностей PS.
Почем работает Ваш пример?
Первый пайп в Вашем примере работает, потому, что Ваши стримы имеют один фиксированный формат — mp3.
Второй пайп работает потому, что есть общий бинарный формат, к которому может быть приведены любые звуковые данные и который.
Посмотрим на похожую тему: изображения. Как обычно работают с изображениями в Linux? imagemagick. Тот самый монстрообразный комбайн, который так противоречит идее Unix.
Теперь посмотрим как (примерно) должна была бы выглядеть работа с графикой:
< file.jpg decode_jpeg | image_rotate --center --angle 90 | image_mirror --vertical | image_scale 3 | encode_jpeg > file2.jpg
При этом, image_rotate ничего не должна знать ни о формате исходного изображения, ни о выходном формате. Часто такое видите в Linux шеллах?
Вы, сейчас, конечно, скажете, что надо использовать bmp-подобный промежуточный формат. У этого способа много проблем: Вы снова несколько раз копирует очень большие бинарные данные; Вы не можете поворачивать/зеркалировать векторные изображения.
Как же абстрагироваться от форматов данных? Вспомните программирование и ООП: инкапсуляция, полиморфизм… Если программы передают по пайпам объект базового типа Image, то количество проблем резко снижается.
В Unix множетсво программ для гибкой работы с текстом.
Но, по указанным мною причинам, программы, которые позволяют так же гибко работать с нетекстовой информацией очень редки. Даже Ваш пример Вам подсказали — Вы бы не догадались сами. А вот как «вывести 10 самых больших значений из третьего столбца таблицы в строках, содержащих слово word» Вы бы, я думаю, догадались сами, без подсказки.
>, пресловутые «алиасы» лишнее тому доказательство
Алиасы (которые там, к слову, идля Dos и для *nix), очевидно, для того, чтобы людям было в первое время проще найти знакомые команды. Ещё алиасы ичень удобны в интерактивном режиме. Вы хотели бы, чтобы в шелле не было алиасов?
Вспомните самую важную идею Unix: пайпы.
Вместо монолитных программ-комбайнов — небольшие программки, каждая из которх делает немного, но хорошо, соединённые пайпами.
Это прекрасная идея, которую неплохо реализовали *nix шеллы и плохо — DOS шелл.
В какой-то момент развитие возможностей многих *nix программ было приостановлено с целью сохранения совместимости. Многие шеллы, вроде bash не боятся нарушить POSIX, но всё-таки стараются придерживаться традиционой парадигмы. Думаю, Вы согласны со мной, так как сами пишете, что многие программы принципиально не менялись по 30 лет.
Причём тут PS?
Моё мнение такое: в упомянутой мной «идее Unix» PS пошёл дальше bash и zsh. Он может проигрывать по рюшечкам вроде автокомплита, по набору и возможностям стандартных программ (причём тут шелл?) и т.д. Но идея пайпов в PS реализована более полно, чем в Bash (возможно, на том же уровне, что и ipython).
Приведу два примера. Технический и Ваш пример с радио («wget -t 0 -T 15 -O — «radiostream» | lame --mp3input --decode /dev/stdin — | aplay „):
1) В Bash я очень активно пользуюсь пайпами. “Этажерки» вызовов иногда достигают десятка. Давайте подумаем, с программистской точки зрения, что при этом происходит.
Каждая команда:
Читает символы из stdin.
Разбивает по концам строк.
Разбивает строки по разделителям.
Парсит данные вроде цифр.
Делает работу.
Сериализует результаты в текст.
Форматирует вывод и отправляет его в stdout.
Умножить на 10. Если Вы программист, Вам должно стать противно от вида этой картины.
В PS не нужно постоянно сериализовывать/десериализовывать/форматировать/парсить текст. Какое-нибудь поле, возникшее в момент начального парсинга файла, может всё оставшееся время просуществовать в виде ссылку на строку, а не копироваться по 40 раз.
2) Вы привели хороший пример с звуковыми данными. Как раз в такого рода задачах хорошо виден потенциал PS.
Вы показали пример, как в *nix шелле можно обойтись без объектов при передаче нетекстовой информации. Прекрасно. Тем не менее, это а) редкость и б) всё равно не даёт всех возможностей PS.
Почем работает Ваш пример?
Первый пайп в Вашем примере работает, потому, что Ваши стримы имеют один фиксированный формат — mp3.
Второй пайп работает потому, что есть общий бинарный формат, к которому может быть приведены любые звуковые данные и который.
Посмотрим на похожую тему: изображения. Как обычно работают с изображениями в Linux? imagemagick. Тот самый монстрообразный комбайн, который так противоречит идее Unix.
Теперь посмотрим как (примерно) должна была бы выглядеть работа с графикой:
< file.jpg decode_jpeg | image_rotate --center --angle 90 | image_mirror --vertical | image_scale 3 | encode_jpeg > file2.jpg
При этом, image_rotate ничего не должна знать ни о формате исходного изображения, ни о выходном формате. Часто такое видите в Linux шеллах?
Вы, сейчас, конечно, скажете, что надо использовать bmp-подобный промежуточный формат. У этого способа много проблем: Вы снова несколько раз копирует очень большие бинарные данные; Вы не можете поворачивать/зеркалировать векторные изображения.
Как же абстрагироваться от форматов данных? Вспомните программирование и ООП: инкапсуляция, полиморфизм… Если программы передают по пайпам объект базового типа Image, то количество проблем резко снижается.
В Unix множетсво программ для гибкой работы с текстом.
Но, по указанным мною причинам, программы, которые позволяют так же гибко работать с нетекстовой информацией очень редки. Даже Ваш пример Вам подсказали — Вы бы не догадались сами. А вот как «вывести 10 самых больших значений из третьего столбца таблицы в строках, содержащих слово word» Вы бы, я думаю, догадались сами, без подсказки.
>, пресловутые «алиасы» лишнее тому доказательство
Алиасы (которые там, к слову, идля Dos и для *nix), очевидно, для того, чтобы людям было в первое время проще найти знакомые команды. Ещё алиасы ичень удобны в интерактивном режиме. Вы хотели бы, чтобы в шелле не было алиасов?
НЛО прилетело и опубликовало эту надпись здесь
Я, как человек много программировавший под bash, а теперь много программирующий под PS, ответственно заявляю: Powershell — отличный shell и ни разу не велосипед.
> И вообще, какие только велосипеды не придумают, лишь бы не использовать богомерзкие и grep, find и множество других отличных утилит.
Почему не использовать? Я вполне нормально совмещаю Cygwin+ZSH и PowerShell, никаких проблем с этим не вижу. Просто чаще под виндой удобнее PowerShell.
Zsh и прочие удобны, например, когда нужно перелопатить большой объём текста (тут PowerShell сливает по производительности), или перекодировать текст из экзотической кодировки.
Почему не использовать? Я вполне нормально совмещаю Cygwin+ZSH и PowerShell, никаких проблем с этим не вижу. Просто чаще под виндой удобнее PowerShell.
Zsh и прочие удобны, например, когда нужно перелопатить большой объём текста (тут PowerShell сливает по производительности), или перекодировать текст из экзотической кодировки.
Что касается объема текста — лучше вообще обойтись без посредников, и использовать специально предназначенный язык — perl.
Про кодировки в PS — xaegr.wordpress.com/2007/01/24/decoder/ не iconv, но тоже кое что ;) Может секономит лишний запуск zsh ;)
Про кодировки в PS — xaegr.wordpress.com/2007/01/24/decoder/ не iconv, но тоже кое что ;) Может секономит лишний запуск zsh ;)
>Для аналогичных целей в окружении PowerShell есть коммандлет Select-String, или sls (это алиас)
sls это ваш персональный алиас, по умолчанию в PowerShell такого нет. Думаю это стоит указать в статье, а лучше вообще убрать упоминание, дабы не смущать людей.
ЗЫ: Хорошая статья, буду рад если продолжите подобные на Хабре :)
sls это ваш персональный алиас, по умолчанию в PowerShell такого нет. Думаю это стоит указать в статье, а лучше вообще убрать упоминание, дабы не смущать людей.
ЗЫ: Хорошая статья, буду рад если продолжите подобные на Хабре :)
В PowerShell унылые названия команд (get-object, ну хуже некуда), но зато в Линуксе проблемы с раскрытием всяких звездочек, скобок, кавычек и тд.
Мне наоборот кажется это правильным. Исходные названия такими и должны быть, говорящими. А там — что нам стоит алиасов понастроить.
Представьте, что удобнее, поддерживать скрипт, состоящий из:
1. коротких, повсеместно и давно употребляемых команд
2. длинных CamelCase-команд
3. алиасов, которые каждый разработчик пишет под свои нужды и подключает к скрипту
Да, разработчику на PS будет удобнее 2й вариант, если он не будет отвлекаться на другие языки (сравнимо с dot-NET/Java).
Однако, в unix-песочницу с такой лопаткой залазить не стоит ;)
1. коротких, повсеместно и давно употребляемых команд
2. длинных CamelCase-команд
3. алиасов, которые каждый разработчик пишет под свои нужды и подключает к скрипту
Да, разработчику на PS будет удобнее 2й вариант, если он не будет отвлекаться на другие языки (сравнимо с dot-NET/Java).
Однако, в unix-песочницу с такой лопаткой залазить не стоит ;)
В повершелле своя «песочница» :) Там названия скриптлетов состоят из Verb и Noun. Для verb'ов есть продуманный список валидных вербов, отклонение от которых грохит предупреждением. Такой подход удобен в том плане, что я могу легко выбрать все команды, которые работают с определенным типом объектов. Например help *-Process дасть мне все, что работает с процессами. Иногда я даже угадывал команду по тому, что мне было нужно, хотя о ее существовании не знал :)
расстраивает именование команд в обратную сторону.
вместо того, что бы по комплекшену быстро понять что я могу сделать скажем с процессом, мне предлагают увидеть все что можно «гетнуть» :)
Предпочитаю все же обратное, что бы было скажем process-(get|set|...|...) — ты сначала выбираешь с каким объектом идет работа, комплекшеном дополняешь что нужно сделать.
вместо того, что бы по комплекшену быстро понять что я могу сделать скажем с процессом, мне предлагают увидеть все что можно «гетнуть» :)
Предпочитаю все же обратное, что бы было скажем process-(get|set|...|...) — ты сначала выбираешь с каким объектом идет работа, комплекшеном дополняешь что нужно сделать.
GetFileByPattern --MySearchPattern=class --RunSomeCommandAfterFind org.base.misc.tools.MSFT.BestSuperCommandForParsingAndThisIsNotUnixGrep ReallyGoodParams
CamelCase убивает. Избыточность в именовании команд — тоже (find/awk/grep/sed/ls против. И альясы — не спасение, если изначально у авторов powershell говно в голове.
CamelCase убивает. Избыточность в именовании команд — тоже (find/awk/grep/sed/ls против. И альясы — не спасение, если изначально у авторов powershell говно в голове.
bash/zsh можно использовать в повседневности, а к PS как к программированию подход. Пока всмпонишь все, наберешь. Не написать просто ps aux | grep nginx на автомате, да.
Да настройте вы уже алиасы, в конце концов! :-)
В данном случае это точно вопрос привычки. Привыкнуть к ps nginx гораздо проще, но всё же надо привыкать, а ps aux | grep nginx у вас уже отскакивает ;)
ps — стандартный псевдоним к get-process, его не надо настраивать.
ps — стандартный псевдоним к get-process, его не надо настраивать.
Вы, вижу, хорошо разбираетесь в устройстве голов ;-) Но плохо в устройстве шеллов :-(
Не нравится CamelCase, не используйте его, это можно. Для часто используемых команд и параметров есть алиасы.
1. Кейс может использовать любой.
2. Автодополнение замечательно работает и для команд и для аргументов.
3. Зачастую аргументы позиционированы, т.е. их имена можно не писать вообще.
4. Все аргументы можно сокращать хоть до одной буквы, главное чтобы количество введенных букв идентифицировало аргумент однозачно.
5. Есть гарантия, что все командлеты будут в едином стиле и не придется встречаться с сюрпризами, когда автор утили решил, что его способ передачи аргументов является единственно верным.
Имхо, уже неплохо. Единственное, что анноит лично меня — лучше бы они в именовании командлетов вначале располагали объект, а потом — операцию.
2. Автодополнение замечательно работает и для команд и для аргументов.
3. Зачастую аргументы позиционированы, т.е. их имена можно не писать вообще.
4. Все аргументы можно сокращать хоть до одной буквы, главное чтобы количество введенных букв идентифицировало аргумент однозачно.
5. Есть гарантия, что все командлеты будут в едином стиле и не придется встречаться с сюрпризами, когда автор утили решил, что его способ передачи аргументов является единственно верным.
Имхо, уже неплохо. Единственное, что анноит лично меня — лучше бы они в именовании командлетов вначале располагали объект, а потом — операцию.
Может мне кто-нибудь объяснить, а почему все сравнивают конкретный PowerShell с bash/grep/sed/awk/whatever, хотя сравнивать надо подходы?
bash/прочие консоли используют пайпы и передают через них текст. PowerShell использует пайпы, и передаёт через них какие-то собственные объекты в каком-то собственном внутреннем формате. По-моему, на этом сравнение уже можно закончить, уже после этих слов станет понятно, что PowerShell — это типовое образцовое MS-решение, полностью в MS-духе, основанное на ключевых MS-идеях разработки и маркетинга. Разве нет?
Как сделать «революционное» решение от MS? Надо проанализировать всех конкурентов, взять из них самый часто используемый функционал, придумать способ, которым этот основной и часто используемый функционал можно было бы использовать наиболее удобным, красивым и зрелищным способом («поиск строки в файлах простой трёхбуквенной командой! GUI-enabled HelloWorld-приложение одной мышкой, без единого нажатия на клавиши! динамическая страница с доступом к базе данных с помощью мастера!»)… и полностью проигнорировать, если не усложнить, интеграцию получившегося продукта со сторонними системами.
Что, в случае с консольными шеллами, является не то что вредным, а полностью противоречащим их идее.
Так и тут. Только вылезло на главную страницу сообщение с ключевым словом PowerShell, как в комментариях тут же началось — «А zsh лучше!» — «нет, PowerShell современнее!» Да ни то и не другое и не лучше и не хуже. Сами bash/zsh/PowerShell вообще иррелевантны. Лучше или хуже — передача через пайпы каких-то объектов или обычного текста.
В одном случае, мы имеем революционный кухонный комбайн на 100 операций из разряда «а у нас тоже есть, и причём ООП!»
В другом — мы имеем несколько десятков лет эволюции, полную прозрачность спецификаций, кроссплатформенность и кросссистемность (мало того что тот же Cygwin уже сто лет как работает под Windows, не говоря уже про наличие шелла даже в каких-нибудь мобильных телефонах, так ещё и, небось, netcat сможет кинуть данные с Cygwin/Win32 на HP/UX и при этом не поперхнуться), (постоянно используемую) возможность написать любой недостающий компонент нужного пайпа легко и просто на любом языке программирования, имеющем доступ к STDIN и STDOUT (что примерно совпадает с множеством всех языков программирования), наличие достаточно прозрачного доступа через этот механизм почти к любой работающей системе, тысячи уже имеющихся программ, поддерживающих этот механизм и выстраивающих на его стабильной основе более сложные конструкции (например, на базе тексто-пайпового механизма работает Makefile, а на базе Makefile работают инсталляционные скрипты в том же Debian), и экспоненциальный взрыв вариантов комбинирования этих программ.
Слышал где-то легенду про то, как руководство IBM отнеслось к тому, что Microsoft со своим Windows начал захватывать рынок десктопных ОС. «Microsoft? А, это те выскочки из Редмонда? Ну, лет через 30 посмотрим, что у них получится.»
bash/прочие консоли используют пайпы и передают через них текст. PowerShell использует пайпы, и передаёт через них какие-то собственные объекты в каком-то собственном внутреннем формате. По-моему, на этом сравнение уже можно закончить, уже после этих слов станет понятно, что PowerShell — это типовое образцовое MS-решение, полностью в MS-духе, основанное на ключевых MS-идеях разработки и маркетинга. Разве нет?
Как сделать «революционное» решение от MS? Надо проанализировать всех конкурентов, взять из них самый часто используемый функционал, придумать способ, которым этот основной и часто используемый функционал можно было бы использовать наиболее удобным, красивым и зрелищным способом («поиск строки в файлах простой трёхбуквенной командой! GUI-enabled HelloWorld-приложение одной мышкой, без единого нажатия на клавиши! динамическая страница с доступом к базе данных с помощью мастера!»)… и полностью проигнорировать, если не усложнить, интеграцию получившегося продукта со сторонними системами.
Что, в случае с консольными шеллами, является не то что вредным, а полностью противоречащим их идее.
Так и тут. Только вылезло на главную страницу сообщение с ключевым словом PowerShell, как в комментариях тут же началось — «А zsh лучше!» — «нет, PowerShell современнее!» Да ни то и не другое и не лучше и не хуже. Сами bash/zsh/PowerShell вообще иррелевантны. Лучше или хуже — передача через пайпы каких-то объектов или обычного текста.
В одном случае, мы имеем революционный кухонный комбайн на 100 операций из разряда «а у нас тоже есть, и причём ООП!»
В другом — мы имеем несколько десятков лет эволюции, полную прозрачность спецификаций, кроссплатформенность и кросссистемность (мало того что тот же Cygwin уже сто лет как работает под Windows, не говоря уже про наличие шелла даже в каких-нибудь мобильных телефонах, так ещё и, небось, netcat сможет кинуть данные с Cygwin/Win32 на HP/UX и при этом не поперхнуться), (постоянно используемую) возможность написать любой недостающий компонент нужного пайпа легко и просто на любом языке программирования, имеющем доступ к STDIN и STDOUT (что примерно совпадает с множеством всех языков программирования), наличие достаточно прозрачного доступа через этот механизм почти к любой работающей системе, тысячи уже имеющихся программ, поддерживающих этот механизм и выстраивающих на его стабильной основе более сложные конструкции (например, на базе тексто-пайпового механизма работает Makefile, а на базе Makefile работают инсталляционные скрипты в том же Debian), и экспоненциальный взрыв вариантов комбинирования этих программ.
Слышал где-то легенду про то, как руководство IBM отнеслось к тому, что Microsoft со своим Windows начал захватывать рынок десктопных ОС. «Microsoft? А, это те выскочки из Редмонда? Ну, лет через 30 посмотрим, что у них получится.»
Люто плюсую (плюсовать обычным способом карма не доросла).
Здорово, обернуть одно из главных преимуществ как главный недостаток — это уровень профессионала :)
>PowerShell использует пайпы, и передаёт через них какие-то собственные объекты в каком-то собственном внутреннем формате.
Пропиетарные объекты! Ужос! :) Объекты во вполне открытых форматах, более того, для их изучения даже не требуется документация (хотя есть и она), спасибо Reflection. Ну про то что их можно экспортировать\импортировать в тот же общепринятый xml или даже csv думаю даже не стоит упоминать :)
>и полностью проигнорировать, если не усложнить, интеграцию получившегося продукта со сторонними системами.
Даа? А как насчет управления например Nix'ами через WS-Man (открытый стандарт, являющийся родным для PS)? ;)
>Сами bash/zsh/PowerShell вообще иррелевантны. Лучше или хуже — передача через пайпы каких-то объектов или обычного текста.
Ну не согласен, объекты не единственная фича PS. Хотя конечно сравнение какой шелл лучше — несколько надуманное.
>В другом — мы имеем несколько десятков лет эволюции,
Согласен, у PowerShell это всё впереди. Сравнивать его стоит скорее с 3х-летним башем :)
>netcat сможет кинуть данные с Cygwin/Win32 на HP/UX и при этом не поперхнуться
Вы так говорите будто в наше время передача данных открытым текстом — это что то хорошее. Одно из преимуществ PS это то что он по большей части стремится использовать современные технологии и достижения.
>Ну, лет через 30 посмотрим, что у них получится.
Досмотрелись… Где сейчас IBM и где MS…
>PowerShell использует пайпы, и передаёт через них какие-то собственные объекты в каком-то собственном внутреннем формате.
Пропиетарные объекты! Ужос! :) Объекты во вполне открытых форматах, более того, для их изучения даже не требуется документация (хотя есть и она), спасибо Reflection. Ну про то что их можно экспортировать\импортировать в тот же общепринятый xml или даже csv думаю даже не стоит упоминать :)
>и полностью проигнорировать, если не усложнить, интеграцию получившегося продукта со сторонними системами.
Даа? А как насчет управления например Nix'ами через WS-Man (открытый стандарт, являющийся родным для PS)? ;)
>Сами bash/zsh/PowerShell вообще иррелевантны. Лучше или хуже — передача через пайпы каких-то объектов или обычного текста.
Ну не согласен, объекты не единственная фича PS. Хотя конечно сравнение какой шелл лучше — несколько надуманное.
>В другом — мы имеем несколько десятков лет эволюции,
Согласен, у PowerShell это всё впереди. Сравнивать его стоит скорее с 3х-летним башем :)
>netcat сможет кинуть данные с Cygwin/Win32 на HP/UX и при этом не поперхнуться
Вы так говорите будто в наше время передача данных открытым текстом — это что то хорошее. Одно из преимуществ PS это то что он по большей части стремится использовать современные технологии и достижения.
>Ну, лет через 30 посмотрим, что у них получится.
Досмотрелись… Где сейчас IBM и где MS…
> А как насчет управления например Nix'ами через WS-Man (открытый стандарт, являющийся родным для PS)?
Ещё один велосипед от ms, чёт я у себя никаких всманов не вижу, а ssh вижу
Ещё один велосипед от ms, чёт я у себя никаких всманов не вижу, а ssh вижу
Круто вы DMTF в MS зачислили. Возможно у вас просто не очень современная ОС? ;)
У меня современная ОС не имеющая лишних сущностей.
Просто у него не-windows. Рассмотрим все основные OC:
Windows — есть
Mac — маловероятно… не уверен
Linux — нет
FreeBSD — нет
Solaris — нет
А каком открытом СТАНДАРТЕ идёт речь? Это стандарт только для windows.
Что же касается современная\не современная, то винда — очень не современная ось, в её ядре давно уже не было существенных изменений (если не считать изоляции модуля видео-драйвера).
Windows — есть
Mac — маловероятно… не уверен
Linux — нет
FreeBSD — нет
Solaris — нет
А каком открытом СТАНДАРТЕ идёт речь? Это стандарт только для windows.
Что же касается современная\не современная, то винда — очень не современная ось, в её ядре давно уже не было существенных изменений (если не считать изоляции модуля видео-драйвера).
Объекты во вполне открытых форматах, более того, для их изучения даже не требуется документация (хотя есть и она), спасибо Reflection.
Прекрасно. Вы ведь напишете статью о том, как в PowerShell-овый пайп встроить однострочник на Python-е, выбирающий строки на основании какой-то своей, питоновой логики? Впрочем, если не хотите, можно не на Python-е, можно на Tcl. С Reflection-ом в духе print dir(входящий_объект) было бы здорово :)
Мне это не интересно, но думаю проблем не возникнет если указанные языки смогут принять/получить объекты .NET/COM (максимум сохранности, возможность сохранить методы объектов, и т.д.) или XML/CSV (хотя бы сохраняем структуру объектов и данных, сериализация). Ну уж если они и этого не могут, то тогда конечно придется опускаться до привычного и понятного всем текста… Да, PS может и это разумеется, хотя при наличии возможности работать с объектами — все стараются избегать этих ужасов.
Я думаю иделаьно подошел бы JSON. Так как XML — это слишком большой оверхед, а CSV слишком ограничен по структуре.
Питон легко работает с JSON'ом (впрочем как и с XML и CSV).
Питон легко работает с JSON'ом (впрочем как и с XML и CSV).
Запросто. IronPython поддерживает DLR, а значит я его могу поднять в Powershell. Можно вообще сделать Powershell чисто на Питоне. Ибо сам повершелл в том виде, в каком мы его привыкли видеть — просто одна из реализаций класса PSHost. Я могу ее наследовать и поднять внутри IronPython через DLR. Могу я расширить Bash таким образом?
А зачем это нужно?
Если нужен шел с питоном, есть ipython
Если нужен шел с питоном, есть ipython
Случайно Ctrl-Enter нажал, блин.
И как насчёт управления ими? Расскажите, не стесняйтесь — боюсь, кроме пользователей Windows, про этот «открытый стандарт» мало кто знает. Чем оно полезнее и удобнее в интеграции по сравнению с, например, WBEM?
Не говоря уже про то, что пользователи «альтернативных операционных систем» умели ими управлять удалённо с помощью rexec и rsh наверное, ещё тогда, когда не было не то что WS-MAN, SOAP или XML, но даже, боюсь, Microsoft. Впрочем, про последнее не поручусь. WS-MAN ведь открывает равномощный способ доступа к системе по сравнению с rsh?
С башем 1990-го года? Хм.
Во-во. Особенно забавно смотреть на сравнения интерактивных возможностей zsh и powershell — да не красоту автодополнения надо сравнивать, а сам тот факт, что zsh вписан в систему, в которой есть тысячи сторонних программ, интерфейс пайпового доступа к которым zsh умеет упрощать. Что одним и тем же zsh я быстро пишу командные строки, включающие в себя отправку почты, жаббер- или твиттер-сообщений, сравнения по времени работы (time :) ) и уровню сжатия пары десятков архиваторов, от банальных pkzip/bzip2 до сумасшедшего paq8, устанавливаю SIP-звонки,… ну, или неторопливо сканирую все доступные smb-шары на предмет наличия свежескачанного Хауса.
Не подумайте, кстати, я сюда не просто пофлеймиться по поводу PowerShell пришёл — я вполне гибок и с радостью попробую его, когда он появится в репозиториях. Пока же, полагаю, «powershell — powerful terminal emulator for GNOME» — это что-то неблизкое к теме нашей беседы :) И сейчас меня на самом деле больше всего интересует, как вписать программку на Perl/Python в PowerShell-овскую объектную структуру.
А как насчет управления например Nix'ами через WS-Man (открытый стандарт, являющийся родным для PS)? ;)
И как насчёт управления ими? Расскажите, не стесняйтесь — боюсь, кроме пользователей Windows, про этот «открытый стандарт» мало кто знает. Чем оно полезнее и удобнее в интеграции по сравнению с, например, WBEM?
Не говоря уже про то, что пользователи «альтернативных операционных систем» умели ими управлять удалённо с помощью rexec и rsh наверное, ещё тогда, когда не было не то что WS-MAN, SOAP или XML, но даже, боюсь, Microsoft. Впрочем, про последнее не поручусь. WS-MAN ведь открывает равномощный способ доступа к системе по сравнению с rsh?
Согласен, у PowerShell это всё впереди. Сравнивать его стоит скорее с 3х-летним башем :)
С башем 1990-го года? Хм.
Хотя конечно сравнение какой шелл лучше — несколько надуманное.
Во-во. Особенно забавно смотреть на сравнения интерактивных возможностей zsh и powershell — да не красоту автодополнения надо сравнивать, а сам тот факт, что zsh вписан в систему, в которой есть тысячи сторонних программ, интерфейс пайпового доступа к которым zsh умеет упрощать. Что одним и тем же zsh я быстро пишу командные строки, включающие в себя отправку почты, жаббер- или твиттер-сообщений, сравнения по времени работы (time :) ) и уровню сжатия пары десятков архиваторов, от банальных pkzip/bzip2 до сумасшедшего paq8, устанавливаю SIP-звонки,… ну, или неторопливо сканирую все доступные smb-шары на предмет наличия свежескачанного Хауса.
Не подумайте, кстати, я сюда не просто пофлеймиться по поводу PowerShell пришёл — я вполне гибок и с радостью попробую его, когда он появится в репозиториях. Пока же, полагаю, «powershell — powerful terminal emulator for GNOME» — это что-то неблизкое к теме нашей беседы :) И сейчас меня на самом деле больше всего интересует, как вписать программку на Perl/Python в PowerShell-овскую объектную структуру.
Чем оно полезнее и удобнее в интеграции по сравнению с, например, WBEM?
> Посмотрите в википедии. Я бы назвал это современной, более совершенной версией WBEM, но на самом деле там немало нововведений.
>Обязательно расскажу. К сожалению доклад с PDC где я увидел демонстрацию этого с PowerShell был доступен лишь ограниченное время, а я еще не добрался до воплощения. Видимо сказывается то что это действительно нужно лишь спорщикам в комментариях…
Для реальных задач же WS-Man используется например для интеграции OpsMgr с не-win системами, или для управления bare-metal железками (Intel AMT, HP iLO и т.д.).
>управлять удалённо с помощью rexec и rsh
Это вы сравнили блокнот с вордом.
>С башем 1990-го года? Хм.
Да, действительно, неверно выразился. Скорее с sh с набором утилит накопленных за 3 года :)
>zsh вписан в систему, в которой есть тысячи сторонних программ, интерфейс пайпового доступа к которым zsh умеет упрощать.
Да, верно подмечено. PowerShell'у в *nix окружении было бы так же неуютно и беспомощно как и zsh среди .NET, WMI, COM, и т.д. :) Поэтому не стоит ждать PS на *nix, ничего хорошего там он не даст я думаю.
>Что одним и тем же zsh
На PS можно делать не меньше :)
> Посмотрите в википедии. Я бы назвал это современной, более совершенной версией WBEM, но на самом деле там немало нововведений.
>Обязательно расскажу. К сожалению доклад с PDC где я увидел демонстрацию этого с PowerShell был доступен лишь ограниченное время, а я еще не добрался до воплощения. Видимо сказывается то что это действительно нужно лишь спорщикам в комментариях…
Для реальных задач же WS-Man используется например для интеграции OpsMgr с не-win системами, или для управления bare-metal железками (Intel AMT, HP iLO и т.д.).
>управлять удалённо с помощью rexec и rsh
Это вы сравнили блокнот с вордом.
>С башем 1990-го года? Хм.
Да, действительно, неверно выразился. Скорее с sh с набором утилит накопленных за 3 года :)
>zsh вписан в систему, в которой есть тысячи сторонних программ, интерфейс пайпового доступа к которым zsh умеет упрощать.
Да, верно подмечено. PowerShell'у в *nix окружении было бы так же неуютно и беспомощно как и zsh среди .NET, WMI, COM, и т.д. :) Поэтому не стоит ждать PS на *nix, ничего хорошего там он не даст я думаю.
>Что одним и тем же zsh
На PS можно делать не меньше :)
управлять удалённо с помощью rexec и rsh
Это вы сравнили блокнот с вордом.… и мы опять выходим на классическую описанную выше MS-стезю :) Говорят, есть люди, которые используют Word как текстовый редактор для программирования…
управлять удалённо с помощью rexec и rsh
Это вы сравнили блокнот с вордом.
… и мы опять выходим на классическую описанную выше MS-стезю :) Говорят, есть люди, которые используют Word как текстовый редактор для программирования…
Да, действительно, неверно выразился. Скорее с sh с набором утилит накопленных за 3 года :)
Вы знаете… я постепенно как раз и подвожу к той мысли, что. В чём фишка юниксовой консоли? Текст со stdin-а, текст на stdout. Простейший интерфейс, доступный в почти любом из мириадов доступных языков. Благодаря этой простоте, экспоненциальный взрыв и случился. Благодаря этой простоте, сотни тысяч людей регулярно пишут новые программы для этого механизма (и основную часть, пожалуй — не для продажи или напоказ, а просто для решения текущих собственных задач) и прозрачно интегрируют их с уже имеющимися.
Я пока так и не дождался ответа, насколько сложно написать стороннюю программу с «объектно-пайповым» интерфейсом. В идеале — на любом языке, а не ограниченном платформой .NET (ну мало под него интересных языков); если это сложно или невозможно — то хоть на F#/IronPython/whatever.
Вы так говорите будто в наше время передача данных открытым текстом — это что то хорошее.
Вы так говорите, как будто ООП — это что-то хорошее ;)
А вы не согласны? 8()
Тогда конечно, о чем я говорю… текстовые пайпы ваше всё…
Тогда конечно, о чем я говорю… текстовые пайпы ваше всё…
Назовите хоть одну консольную задачу, реализация которой на powershell с её ооп будет лучше, чем в bash/zsh?
Не согласен, разумеется. ООП изредка удобен и забавен, но, как правило, избыточен :)
Кстати, я бы даже заметил некоторую аналогию в сравнении data-oriented подхода powershell и, в некотором роде, «глаголо»-ориентированного подхода юникс-шеллов, со сравнением императивного ООП с функциональной парадигмой ;)
Кстати, я бы даже заметил некоторую аналогию в сравнении data-oriented подхода powershell и, в некотором роде, «глаголо»-ориентированного подхода юникс-шеллов, со сравнением императивного ООП с функциональной парадигмой ;)
НЛО прилетело и опубликовало эту надпись здесь
> какие-то собственные объекты в каком-то собственном внутреннем формате. По-моему, на этом сравнение уже можно закончить
простите, мы на техническом сайте, или на базаре? На техническом сайте с этого сравнение можно только начать.
Скажите, чем вам лично не угодили «собственные объекты в собственном внутреннем формате»? Боитесь, что объекты начнут следить за вами?
Всё остальное в вашем сообщении, простите, мещанская суета — ведь вы даже не испытываете интереса к PowerShell, не смотрели на него в живую, не крутили — но всё же имеете самонадеянность полить говном «просто так», из лучших побуждений…
простите, мы на техническом сайте, или на базаре? На техническом сайте с этого сравнение можно только начать.
Скажите, чем вам лично не угодили «собственные объекты в собственном внутреннем формате»? Боитесь, что объекты начнут следить за вами?
Всё остальное в вашем сообщении, простите, мещанская суета — ведь вы даже не испытываете интереса к PowerShell, не смотрели на него в живую, не крутили — но всё же имеете самонадеянность полить говном «просто так», из лучших побуждений…
Скажите, чем вам лично не угодили «собственные объекты в собственном внутреннем формате»? Боитесь, что объекты начнут следить за вами?
cat access.log | grep GET | perl -e "..."Вот чем. Шелла как такового я и знать особо не хочу. Я пользуюсь не им, а программами, объединяемыми им в пайпы. В т.ч. теми, которые пишу я сам. Ведь согласитесь, на perl или python писать проще, чем на любом из этих шеллов ;)
>Я пользуюсь не им, а программами, объединяемыми им в пайпы.
В PS вы можете пользоваться командлетами, функциями или старыми утилитами. И всё это можно объединять в пайпы. Разумеется старые утилиты будут для взаимодействия использовать текст, это ужасно, но иногда необходимо.
>Ведь согласитесь, на perl или python писать проще, чем на любом из этих шеллов
Не соглашусь. Разве что вам может быть привычнее.
В PS вы можете пользоваться командлетами, функциями или старыми утилитами. И всё это можно объединять в пайпы. Разумеется старые утилиты будут для взаимодействия использовать текст, это ужасно, но иногда необходимо.
>Ведь согласитесь, на perl или python писать проще, чем на любом из этих шеллов
Не соглашусь. Разве что вам может быть привычнее.
НЛО прилетело и опубликовало эту надпись здесь
Ну обработать access.log на bash + awk вроде как сподручнее будет.
НЛО прилетело и опубликовало эту надпись здесь
Конечно, мое выражение справедливо только в контексте реплики Honeyman #
Кстати, да: интересно было бы сравнить PowerShell с тем же самым Python-ом в плане сравнения именно синтаксиса и семантики языков. Надо внимательно посмотреть, что на PowerShell-е написано на RosettaCode :)
не соглашусь 8-[ ] Вы пробовали вообще писать на PowerShell? Одно из основных его достоинств (как минимум, для меня) в том, что скрипты очень органично перерастают в программы — настоящие, читаемые, полезные программы.
Вы пробовали вообще писать на PowerShell
Я предпочитаю писать на Python и Cython, в последнее время интересуюсь OCaml и Haskell. Раньше писал на Perl. В принципе, могу (но не буду) писать на C или C++.
Любой из этих языков — это языки с богатым и удобным синтаксисом, развитой семантикой и огромным количеством биндингов к различным функционалам. На любом из этих языков можно легко и удобно писать в парадигме «текстовых пайпов».
Т.е. вы не пробовали. Ну ок, чо.
> Любой из этих языков — это языки с богатым и удобным синтаксисом, развитой семантикой и огромным количеством биндингов к различным функционалам.
Самое простое — красивый доступ к буферу обмена Windows, пожалуйста. На Python. Буду премного благодарен.
> На любом из этих языков можно легко и удобно писать в парадигме «текстовых пайпов».
Ну напишите мне в одном и том же скрипте на любов вашем любимом языке «в парадигме текстовых пайпов». Только чур без вложенных вызовов функций и всего такого — это нам без интересу.
> Любой из этих языков — это языки с богатым и удобным синтаксисом, развитой семантикой и огромным количеством биндингов к различным функционалам.
Самое простое — красивый доступ к буферу обмена Windows, пожалуйста. На Python. Буду премного благодарен.
> На любом из этих языков можно легко и удобно писать в парадигме «текстовых пайпов».
Ну напишите мне в одном и том же скрипте на любов вашем любимом языке «в парадигме текстовых пайпов». Только чур без вложенных вызовов функций и всего такого — это нам без интересу.
Т.е. вы не пробовали. Ну ок, чо.
Да я и bash-то… не особо. Как сделать в нём массив массивов (и можно ли вообще), так даже и не понял. Не то что более сложные конструкции. Я же говорю — я не люблю пользоваться шеллом, я предпочитаю пользоваться программами.
Самое простое — красивый доступ к буферу обмена Windows, пожалуйста. На Python. Буду премного благодарен.
Проверить работоспособность мне будет слегка сложно, но, думаю, это будет примерно так. Берём текстовый редактор. Пишем в нём:
import win32clipboard
import win32con
def getText():
w.OpenClipboard()
d=w.GetClipboardData(win32con.CF_TEXT)
w.CloseClipboard()
return d
Тьфу. Опять слишком рано.
Берём текстовый редактор. Пишем на нём:
Поздравляю! Только что мы написали первую программу на стороннем языке программирования, использующую внешние биндинги (win32clipboard), интегрируемую в концепцию «текстовых пайпов».
Берём текстовый редактор. Пишем на нём:
#!/usr/bin/python
import win32clipboard as w
if __name__ == "__main__":
w.OpenClipboard()
d=w.GetClipboardData(w.CF_TEXT)
w.CloseClipboard()
print d
Поздравляю! Только что мы написали первую программу на стороннем языке программирования, использующую внешние биндинги (win32clipboard), интегрируемую в концепцию «текстовых пайпов».
Когда на хабре появится кнопка «удалить комментарий»?..
#!/usr/bin/python
import win32clipboard as w
if __name__ == "__main__":
w.OpenClipboard()
d=w.GetClipboardData(w.CF_TEXT)
w.CloseClipboard()
print d
что это CF_TEXT, ёма? А если в нём картинка? А если их несколько? WMF, BMP?
А что вы с содержимым буфера обмена собрались делать? Грепать строку «adult.jpg» и слать результат на специальный емейл-адрес, ресайзить до размера 640x480 с сохранением пропорций и чёрными бордюрами, или сжимать в AAC в максимальном качестве? В зависимости от вашего ответа, подставьте туда нужную константу.
Кстати, вот вам бонусом красивый доступ к буферу обмена в кроссплатформенном варианте, опять же на питоне и с (более правильными) биндингами. Будет работать и под Windows, и под Linux.
Quid Pro Quo. Может, хоть вы напишете решение «типовой интеграционной задачи» на PowerShell — кинуть результат какой-нибудь команды на жаббер-адрес? Мой юниксовый менталитет подсказывает мне, что соответствующие Jabber-мессаджинга API для PowerShell имеет смысл поискать в Qip, Miranda или даже MSN Messenger, но я могу быть не прав…
python -c "from PyQt4 import QtGui; print QtGui.QApplication([]).clipboard().text()"Quid Pro Quo. Может, хоть вы напишете решение «типовой интеграционной задачи» на PowerShell — кинуть результат какой-нибудь команды на жаббер-адрес? Мой юниксовый менталитет подсказывает мне, что соответствующие Jabber-мессаджинга API для PowerShell имеет смысл поискать в Qip, Miranda или даже MSN Messenger, но я могу быть не прав…
bash/прочие консоли используют пайпы и передают через них текст. PowerShell использует пайпы, и передаёт через них какие-то собственные объекты в каком-то собственном внутреннем формате. По-моему, на этом сравнение уже можно закончить, уже после этих слов станет понятно, что PowerShell — это типовое образцовое MS-решение, полностью в MS-духе, основанное на ключевых MS-идеях разработки и маркетинга. Разве нет?
Весь дотнет рантайм давно стандартизирован и никаких секретов того, в каком формате он передает объекты нет. Я вижу другую разницу в подходах. В оригинале большинство информации является объектами. Будь то файл, картинка, XML-документ или что-либо еще. MS просто передает информацию об этих объектах как есть, обеспечивая стандартизированный способ доступа к их свойствам и методам, что характерно. При желании я могу рассматривать все объекты как строки, ибо каждый by design имеет метод ToString и посредством него будет каститься в строку.
Что нам предлагает bash&Co? Какая-то утиль берет информацию о каком-то объекте и сериализует его в текст так, как заблагорассудится автору этой утили. Я изучаю, в каком же виде эта сериализация представлена и при помощи всяких grep/awk пишу десериализацию. Причем, если автору утили в перспективе захочется изменить вывод и он по доброте своей добавит колонку или произойдет еще что-то, то все мои старания могут накрыться медным тазом. Я что-то упустил?
В другом — мы имеем несколько десятков лет эволюции, полную прозрачность спецификаций, кроссплатформенность и кросссистемность
Не могу сказать, что у MS в этом плане все замечательно, но стоит отметить, что CLI, под которой ходит Powershell стандартизирована, исходники доступны, кроссплатформенные реализации есть (как от самой МС для xbox/mobile/embeded/macos/etc, так и от их союзников в лице SUSE в виде Mono). Спецификации Powershell/гайдлайны к нему есть. Используемый язык стандартизирован. Кроссплатформенные реализации в виде того же pash тоже есть. А касательно десятков лет эволюции… этот аргумент далекое не всегда работает.
В оригинале большинство информации является объектами. Будь то файл, картинка, XML-документ или что-либо еще.
В этом и главное преимущество пайпа — мы можем передавать некоторую информацию, не имеющую конкретного представление в машинном виде, но имеет представление в голове автора скрипта. При этом текстовая сериализация обладает рядом качеств:
1) Прозрачность — все что передается по пайпу, можно вывести на экран и ничего более, так же как и ничего менее не будет передано на вход другой программе. Облегчает поиск ошибок и мест их возникновения.
2) Гибкость — сущность, которая передается по пайпу, может меняться очень быстро, например список_пользователей -> e-mail -> md5hash -> url -> avatar.png -> vCard. Для полноценного обьектного пайпа вам пришлось бы реализовать каждую из этих сущностей отдельно и заставить каждую программу понимать эти сущности. Более того, вам придется сохранять обратную совместимость с текстовым представлением сущности. Это накладно, нудно, менее надежно.
3) Совместимость. Проблемы обмена информацией с машинами, работающими под другой версией системы/другой архитектурой, проблемы бинарной несовместимости старых версий программ или отсутствуют, или решаются ещё одной командой.
С другой стороны, современные *nix шеллы не заточены под работу со сложными структурами данных. Эта задача разрешима либо grep/sed/awk в простых случаях, либо программой на perl/python/your-favorite-language в пайпе.
Зато текстовая сериализация обладает кучей недостатков и проблем. Например, не всё можно легко сериализовать в текст, а если и можно, то структура будет очень сложной и парсить их через sed/awk — сущий ад будет, а поддерживать такие скрипты — невозможно. Кроме того, высокая чувствительность к изменениям в формате. Причём эти изменения завалят заранее неизвестное количество скриптов, которые кто-то где-то написал. В случае с объектной сериализацией такого не произойдёт, так как скрипты, которые конечные девелоперы используют не парсят стрим напрямую. Это существенное ограничение для текстовой сериализаци и совместимостью (ваш п.3).
Вас кто-то насильно будет заставлять все скрипты писать на bash?
Можно из bash/zsh вызвать скрипт на питоне и никто не умрёт
Можно из bash/zsh вызвать скрипт на питоне и никто не умрёт
Проблема не в сложности, а в том, что анализ этого «протокола» перекладывается на писателей этих скриптов\программок. А если не дай бог писателю одной из утилит придёт в голову поменять формат вывода? Правильно, будет два текстовых протокола — старый и новый, в результате все программы, которые хотят парсить этот код тоже должны быть переделаны.
Вас кто-то насилно будет заставлять обновлять этот скрипт?
Скрипты обычно пишутся под задачу и за несколько минут, в репозитироий оне не попадают, максимум будут в какой-нибудь хаутушке в интернете, а такие ручками скачанные скрипты неожиданно не обноввятся
Скрипты обычно пишутся под задачу и за несколько минут, в репозитироий оне не попадают, максимум будут в какой-нибудь хаутушке в интернете, а такие ручками скачанные скрипты неожиданно не обноввятся
Конечно нет, мой скрипт просто сломается и всё.
У стандартных вещей вывод не меняется годами, либо его формат можно указывать вручную, отвечая до этого я вас не понял)
Это не отменяет проблему. Не все же утилиты такие древние, как grep и ls.
Не все, но формат вывода либо не меняется, либо настраиваемый, если нет — о его смене предупредят в рассылке заблаговременно.
И тогда это уже не будет страшно, ведь если человек использует скрипт в критичных местах, то он должен читать рассылку нестандартных утилит в его кусках.
+ при обновлении пакетов можно посмотреть чейнжлог, там смена формата вывода будет указана.
И тогда это уже не будет страшно, ведь если человек использует скрипт в критичных местах, то он должен читать рассылку нестандартных утилит в его кусках.
+ при обновлении пакетов можно посмотреть чейнжлог, там смена формата вывода будет указана.
>> о его смене предупредят в рассылке заблаговременно
Ну неьзя предупредить заблаговременно ВСЕХ, заранее неизвестное количество людей
>> если человек использует скрипт в критичных местах
А если не в критических? Да ведь всё равно плохо если всё ломается? К тому же подписываться на рассылки юниксовых тулов — страшное дело: письма там ходят штабелями, так что запаришься фильтровать :D
Ну неьзя предупредить заблаговременно ВСЕХ, заранее неизвестное количество людей
>> если человек использует скрипт в критичных местах
А если не в критических? Да ведь всё равно плохо если всё ломается? К тому же подписываться на рассылки юниксовых тулов — страшное дело: письма там ходят штабелями, так что запаришься фильтровать :D
Ну даже если его будут менять раз в пару лет: скриптом поменять одинаковые куски в других скриптах — дело пяти минут =)
Если бы всё так просто, как вы говорите.
Ну и по мне так не очень адекватно завязывать работу в продакшене(не парсилка логов) на на консольный парсер, всегда можно воспользоваться либами, которые использует «жертва» и самому получить данные)
Да-да, разумеется я не имею в виду домашние поделки. Хотя, когда поделки ломаются — тоже обидно и нудно отлавливать, а что же там сломалось. Диагностика-то никакая… надо ведь сначала понять, почему сломалось. Debug -> Fix -> Test ->…
Ну а для корпоративных решений это вообще труба: такие темы просто нельзя использовать для чего-то серьёзного, потому что это всегда ненадёжно.
Любое отклонение поведения какой-нибудь тулы, не важно какой и по какой причине, может привести к трудно диагностируемым поломкам (скрипт выполнился, а в выхлопе мусор какой-то или пусто… и чёрт поймёшь, что там отсохло).
Ну а для корпоративных решений это вообще труба: такие темы просто нельзя использовать для чего-то серьёзного, потому что это всегда ненадёжно.
Любое отклонение поведения какой-нибудь тулы, не важно какой и по какой причине, может привести к трудно диагностируемым поломкам (скрипт выполнился, а в выхлопе мусор какой-то или пусто… и чёрт поймёшь, что там отсохло).
В этом и главное преимущество пайпа — мы можем передавать некоторую информацию, не имеющую конкретного представление в машинном виде, но имеет представление в голове автора скрипта. При этом текстовая сериализация обладает рядом качеств:
Вообще я предполагал, что всякая информация имеет машинное представление и строка в UTF-7 — в «машинном виде» — это не тоже самое, что строка UCS-4. Даже представление целых чисел может отличаться в зависимости от платформы, а уж про вещественные, даты я вообще молчу. Поэтому когда я работал со строкой в шелле, то я привык воспринимать ее на бытовом уровне, как строку, не вдаваясь, как это выглядит в памяти. Когда я работаю с объектами — я знаю, что получить доступ к свойству объекта я могу через obj.Property, вызвать метод как obj.SomeFunc() и мне никогда не приходило в голову заморачиваться, а как же оно передается. Можете продемонстрировать хотя бы одну задачку, когда это важно?
1) Прозрачность — все что передается по пайпу, можно вывести на экран и ничего более, так же как и ничего менее не будет передано на вход другой программе. Облегчает поиск ошибок и мест их возникновения.
Если вы будете передавать картинку в бинарном виде по пайпу и попробуете ее вывести на экран, то ничего кроме мусора не получите. А я передавая картинку могу получить ширину, высоту, формат цвета, нарисовать параллелепипид и многое другое и все это вывести на экран. Поиск ошибок… Представим себе, что у меня есть переменная даты и времени в powershell'е. Чтобы получить день мне достаточно обратиться как: $d.Day. Теперь представим, что у нас есть текстовое представление даты, которое может быть по стандарту US — «mm/dd/yyyy», может ANSI — «yy.mm.dd», может GB — dd/mm/yyyy, может DE — «dd.mm.yy», может ISO — "[yy]yymmdd". Как ты расшифруешь 01.02.03? Или если взять пример с картинками. Неужчто $img.Width гораздо более сложно диагностируемо для ошибок, чем identify -format "%w"? Не поверю, что операции с датами вроде «До пьянки осталось {0} секунд» -f ($d — [DateTime]::Now).TotalSeconds дается гораздо сложнее, чем аналогичные операции в текстовом виде. И вряд ли в баше 2+2 будет 22. Или для вас скриптинг — это только пайп?
2) Гибкость — сущность, которая передается по пайпу, может меняться очень быстро, например список_пользователей -> e-mail -> md5hash -> url -> avatar.png -> vCard. Для полноценного обьектного пайпа вам пришлось бы реализовать каждую из этих сущностей отдельно и заставить каждую программу понимать эти сущности. Более того, вам придется сохранять обратную совместимость с текстовым представлением сущности. Это накладно, нудно, менее надежно.
Сколько времени работаю с повершеллом и впервые слышу о таких проблемах. Можно пример конкретизировать, а лучше в полном виде, что бы я воспроизвел и мы могли сравнить.
3) Совместимость. Проблемы обмена информацией с машинами, работающими под другой версией системы/другой архитектурой, проблемы бинарной несовместимости старых версий программ или отсутствуют, или решаются ещё одной командой.
Вообще-то объекты .NET замечательно (де)сериализуются хоть бинарно, хоть в xml. Я могу любому пайпу сделать в хвосте Export-CLIXML, а на другом хосте начать пайп с Import-CLIXML. Тут тебе и текст и разметка, а значит данные не зависят от форматирования, которое было использовано на исходной машине.
С другой стороны, современные *nix шеллы не заточены под работу со сложными структурами данных. Эта задача разрешима либо grep/sed/awk в простых случаях, либо программой на perl/python/your-favorite-language в пайпе.
Т.е. решение, которое лаконично как шеллы и имеет возможности языков высокого уровня априори плохое?
Да конечно нечего даже сравнивать plain text потоки с сериализованными объектами (если они, конечно нуждаются в этом… может они передаются прямо в памяти, когда возможно?). Текстовые потоки в связке с sed\awk — вот это действительно ненадёжно, а сериализованные объекты — вот это надёжно. Любая фигня, попавшая в plain text поток будет интерпретироваться как верные данные и один бог знает, что выйдет на конце цепочки пайпов :)
радость калеки что на руках ходить можно.
честно говоря, я когда увидел PowerShell, то первой мыслью было «ну неужели они стали брать правильный пример. Теперь хоть на что-то похожи». А оказывается они совершили что-то революционно новое… ну чё… в стиле майкрософт в принципе. Убрать графику с серверной системы в 2008 году тоже было представлено как революционно новый подходи в безопасности.
Идея объектного шелла оригинальна, пусть даже революционна для кого-то, хотя такие вещи как BeanShell джавишный существуют уже давно. Но BeanShell не позиционируется как замена обычному шеллу ОС, потому что ООП это не то, что нужно в скриптах. (Поэтому в BeanShell нет спецнабора комманд для работы с файлами в стиле grep и find, хотя дописать никто не мешает). Вот что проигнорировали в МС.
Процедурный подход для скриптов использовать более разумно нежели ОО, потому как кол-во скриптов должно быть минимально достаточным для выполнения задачи и баста. Не разумно писать какие-то большие вещи с кучей фич на шелл скриптах. ООП для мелких програмок — из пушки по воробьям (т.е. долго заряжать, большие «накладные расходы» ресурсов, а результат — те же мёртвые воробьи).
Процедурный подход для скриптов использовать более разумно нежели ОО, потому как кол-во скриптов должно быть минимально достаточным для выполнения задачи и баста. Не разумно писать какие-то большие вещи с кучей фич на шелл скриптах. ООП для мелких програмок — из пушки по воробьям (т.е. долго заряжать, большие «накладные расходы» ресурсов, а результат — те же мёртвые воробьи).
Честно говоря, в обычных скриптах иногда ну очень мучительно отсеивать всякую фигню через sed\awk\ect, вместо того, чтобы просто сказать ?$_.propery = 'value'. Это сильно бы упростило и ускорило написание скриптов, да и их отладку упростило.
По поводу BeanShell это вы верно подметили. В конце концов, зачатки этих «революционных» идей давно есть, но как-то в очень зародышевом виде.
По поводу BeanShell это вы верно подметили. В конце концов, зачатки этих «революционных» идей давно есть, но как-то в очень зародышевом виде.
Чисто из флейма, вот список опций grep, описания которых я не нашёл в посте:
Когда я знакомился с дотнетом, после первой радости «о, сделали» пришло разочарование, потому что масса мелких и удобных вопросов оказалась забыта и не реализована. Так же как не реализована совместимость с posix и даже с существующими командами для cmd.
-A NUM, --after-context=NUM
Print NUM lines of trailing context after matching lines. Places a line containing -- between contiguous groups of matches.
-a, --text
Process a binary file as if it were text; this is equivalent to the --binary-files=text option.
-B NUM, --before-context=NUM
Print NUM lines of leading context before matching lines. Places a line containing -- between contiguous groups of matches.
-C NUM, --context=NUM
Print NUM lines of output context. Places a line containing -- between contiguous groups of matches.
-b, --byte-offset
Print the byte offset within the input file before each line of output.
-D ACTION, --devices=ACTION
If an input file is a device, FIFO or socket, use ACTION to process it. By default, ACTION is read, which means that devices are read just as if they were
ordinary files. If ACTION is skip, devices are silently skipped.
-I Process a binary file as if it did not contain matching data; this is equivalent to the --binary-files=without-match option.
-m NUM, --max-count=NUM
Stop reading a file after NUM matching lines. If the input is standard input from a regular file, and NUM matching lines are output, grep ensures that the
standard input is positioned to just after the last matching line before exiting, regardless of the presence of trailing context lines. This enables a call-
ing process to resume a search. When grep stops after NUM matching lines, it outputs any trailing context lines. When the -c or --count option is also
used, grep does not output a count greater than NUM. When the -v or --invert-match option is also used, grep stops after outputting NUM non-matching lines.
--label=LABEL
Displays input actually coming from standard input as input coming from file LABEL. This is especially useful for tools like zgrep, e.g. gzip -cd foo.gz
|grep -H --label=foo something
-R, -r, --recursive
Read all files under each directory, recursively; this is equivalent to the -d recurse option.
-Z, --null
Output a zero byte (the ASCII NUL character) instead of the character that normally follows a file name. For example, grep -lZ outputs a zero byte after
each file name instead of the usual newline. This option makes the output unambiguous, even in the presence of file names containing unusual characters like
newlines. This option can be used with commands like find -print0, perl -0, sort -z, and xargs -0 to process arbitrary file names, even those that contain
newline characters.
Когда я знакомился с дотнетом, после первой радости «о, сделали» пришло разочарование, потому что масса мелких и удобных вопросов оказалась забыта и не реализована. Так же как не реализована совместимость с posix и даже с существующими командами для cmd.
-A NUM, --after-context=NUM
-B NUM, --before-context=NUM
-C NUM, --context=NUM
Параметр -Context.
-R, -r, --recursive
Этого нет.
-Z, --null
Есть ли необходимость в этом, ведь вывод в PowerShell и так unambigous, т.к. объекты?
Про бинарные файлы не могу ничего сказать, не возникало такой необходимости.
-B NUM, --before-context=NUM
-C NUM, --context=NUM
Параметр -Context.
-R, -r, --recursive
Этого нет.
-Z, --null
Есть ли необходимость в этом, ведь вывод в PowerShell и так unambigous, т.к. объекты?
Про бинарные файлы не могу ничего сказать, не возникало такой необходимости.
Если говорить про grep, как средство «для скриптов», то да, вероятность работы с бинарниками мала. А если говорить про греп, как ручной инструмент для «разбирательства» в системе — очень даже актуально. Например, вот так:
grep -a -R "test.ru" * |hexdump -C для выяснения, в каком из бинарников хранится ссылка на test.ru
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Замена для FIND и GREP