Представлен (http://igorshare.wordpress.com/2008/04/06/pash-cross-platfor.../) проект Pash (http://pash.sourceforge.net/), - многоплатформенная открытая реализация MS PowerShell с дополнительными возможностями заимствованными из bash. Проект написан использованием .Net 2.0 и требует Mono для своей работы в Linux.URL: http://igorshare.wordpress.com/2008/04/06/pash-cross-platfor.../
Новость: http://www.opennet.me/opennews/art.shtml?num=15169
а нельзя было сделать по разумному, и вместо гемороя с powershell в windows поставить хотя бы sh? и нервов и денег меньше бы ушло:) да и людям удобно
http://mingw.org/msys.shtml
В форточке несколько лет уже есть csh, в SFU - точно есть. А вот напуркуа в Unix это [..beeep..]? Разве что заказ мелких ....
Сразу оговорюсь, все написанное мое личное мнение, я не являюсь гуру в PowerShell, просто немного интересуюсь этой темой.На мой взгляд идея PowerShell очень интересна, и это очень «юниксвейно», даже странно, что то придумал не кто то из мира UNIX а Microsoft.
Если не смотреть на авторство и конкретную реализацию, а рассматривать саму технологию, то это могло бы стать серьезным шагом вперед. Ведь в чем фишка UNIX, в каналах и перенаправлении, в построении цепочек из программ. Текстовые каналы замечательно работали во времена чистой консоли, и простых тестовых форматов, но начинают пробуксовывать если форматы данных сложные. Например, с помощью grep, sed и.т.д. вы можете легко удалить или добавить строки в файл aliases, но изменение XML уже будет довольно сложной задачей. А как вы будете редактировать файлы OO?
Плюс для написания хорошего скрипта вам надо досканально знать формат файла, а после выхода новой программы скрипт может перестать работать (например в конфиге появился новый праметр, этот параметр вашему скрипту и не нужен совсем, но регулярное выражение в скрипте перестало работать), соответственно вам нужно постоянно следить за изменениями во всех программах, с которыми работает ваш скрипт. IMHO это причина почему нет полноценных, универсальных, графических конфигураторов.В классические каналы вообще толком не работают, иксовые программы нелинейны. Да, есть графические "морды" к консольным утилитам, но интерактивность их оставляет желать лучшего, поэтому и появляются различные Bonobo, KPart, D-bus и.т.д. но это все скорее для программиста а не для простого пользователя.
Переход от чисто ткстовых каналов к ООП, позволит убрать многие проблемы, сделать скрипты проще, упростить сопровождение. А если вместо линейного канала, ввести разветвленный граф то это может изменить всю систему взаимодействия иксовых приложений.
>Сразу оговорюсь, все написанное мое личное мнение, я не являюсь гуру в
>PowerShell, просто немного интересуюсь этой темой.Аналогично, все нижесказанное, только IMO
>На мой взгляд идея PowerShell очень интересна, и это очень «юниксвейно», даже
>странно, что то придумал не кто то из мира UNIX а Microsoft.Возможно идея и интересна, но реализация несколько... монстрообразная
>Если не смотреть на авторство и конкретную реализацию, а рассматривать саму технологию,
>то это могло бы стать серьезным шагом вперед.в потребности бОльшего количества гигагерц, гигабайт, геммороя, возможно
>фишка UNIX, в каналах и перенаправлении, в построении цепочек из программ.
а зачем для простых файлов сложные форматы? фишка -- не усложнить себе и другим жизнь
>Текстовые каналы замечательно работали во времена чистой консоли, и простых тестовых
>форматов, но начинают пробуксовывать если форматы данных сложные.да и сейчас неплохо работают, но для всего свой инструмент
>Например, с помощью
>grep, sed и.т.д. вы можете легко удалить или добавить строки в
>файл aliases, но изменение XML уже будет довольно сложной задачей. Азачем например для файла aliases XML формат??? если все и так достаточно просто обрабатывается grep'ом
>как вы будете редактировать файлы OO?
в openoffice наверное, или предварительно сконвертировав
>Плюс для написания хорошего скрипта вам надо досканально знать формат файла, а
>после выхода новой программы скрипт может перестать работать (например в конфиге
>появился новый праметр, этот параметр вашему скрипту и не нужен совсем,
>но регулярное выражение в скрипте перестало работать), соответственно вам нужно постоянно
>следить за изменениями во всех программах, с которыми работает ваш скрипт.Наверное новые версии програм, но тогда это уже вопрос о backward compatibility и следованию стандартам итп. Точно так же возможны изменения в любом коде (втч и в самом PowerShell)
>IMHO это причина почему нет полноценных, универсальных, графических конфигураторов.
причина частично и в том, что например на сервере без Х'ов это попросту ненужно (не всем и далеко не всегда такое по-настоящему нужно)
>В классические каналы вообще толком не работают, иксовые программы нелинейны. Да, есть
>графические "морды" к консольным утилитам, но интерактивность их оставляет желать лучшего,
>Переход от чисто ткстовых каналов к ООП, позволит убрать многие проблемы, сделать
>скрипты проще, упростить сопровождение. А если вместо линейного канала, ввести разветвленный
>граф то это может изменить всю систему взаимодействия иксовых приложений.И это проще?
+во многих ситуациях, к сожалению, тот же XML крайне неподходящ, а про, например ABNF благополучно забывают, ибо "не модно"
>Возможно идея и интересна, но реализация несколько... монстрообразнаяСогласен, но про реализацию я написал в первом посте.
>>то это могло бы стать серьезным шагом вперед.
>в потребности бОльшего количества гигагерц, гигабайт, геммороя, возможноНе факт, предположим нам в скрипте надо получить текущий ip-шник, для этого мы парсирим вывод ifconfig. Но разбор текста задача довольно ресурсоемкая, а в сложном скрипте таких задач может быть множество, да еще и в разных системах формат вывода ifconfig отличается. Я как то натыкался (сейчас искал, искал не могу найти) на статью как получить ip-шники в разных системах, так там кода было довольно много, для FreeBSD один, для старых Linux-ов другой, для новых третий, к тому же перед этим надо определить какая система. А это простейшая операция, которая в объектной модели будет тривиальна(конечно при условии стандартизации).
>а зачем для простых файлов сложные форматы? фишка -- не усложнить себе
>и другим жизнь
>да и сейчас неплохо работают, но для всего свой инструмент
>зачем например для файла aliases XML формат??? если все и так достаточно
>просто обрабатывается grep'омЯ не предлагал перевести aliases в XML. Aliases я привел, как пример простого файла, который идеально обрабатывается через консоль, (grep для удаления, echo для добавления). Но если взять к примеру smb.conf, то уже сложнее, надо как-то отслеживать секцию(это конечно возможно, но...). При этом ini формат тоже не верх сложности, есть и более сложные.
>>как вы будете редактировать файлы OO?
>в openoffice наверное, или предварительно сконвертировавЯ имел в виду через скрипты и с сохранением форматирования.
>Наверное новые версии програм, но тогда это уже вопрос о backward compatibility
>и следованию стандартам итп. Точно так же возможны изменения в любом
>коде (втч и в самом PowerShell)Здесь все чуть сложнее. Например я написал программу показывающую статистику по загруженности канала, а в следующей версии, по просьбам радиослушателей я добавил вывод макс. пикового значения. Конфиг остался неизменным, зависимости от библиотек не изменились. Backward compatibility есть? Конечно. А ваши скрипты поехали. Мне, как разработчику, это может даже в голову не прийти. А если бы моя программа имела PowerShell интерфейс, то получение только средних значений осталось бы неизменным, я как разработчик должен был бы обеспечить backward compatibility. Конечно разработчики могут менять PowerShell интерфейс, от версии к версии, но это уже вопрос плохого дизайна.
>причина частично и в том, что например на сервере без Х'ов это
>попросту ненужно (не всем и далеко не всегда такое по-настоящему нужно)Отчасти, но UNIX используется не только на серверах. Тем более, что конфиги изменяют не только графические конфигураторы, а например скрипты в пакетных менеджерах.
>>А если вместо линейного канала, ввести разветвленный
>>граф то это может изменить всю систему взаимодействия иксовых приложений.
>
>И это проще?Здесь я не говорил что проще, возможно это будет мощнее.
>+во многих ситуациях, к сожалению, тот же XML крайне неподходящ, а про,
>например ABNF благополучно забывают, ибо "не модно"Согласен, но в некоторых бывает нужен.
> Например я написал программу показывающую статистику по загруженности канала, а в следующей версии, по просьбам радиослушателей я добавил вывод макс. пикового значения. Конфиг остался неизменным, зависимости от библиотек не изменились. Backward compatibility есть? Конечно. А ваши скрипты поехали. Мне, как разработчику, это может даже в голову не прийти.
Хорошие UNIX-программы вообще ничего не выводят в stdout, если об этом их не попросят параметрами. И да, многие из старых программ не являются хорошими в этом смысле.
Кроме того, даже если программа "информативная", она должна выдавать информацию построчно (например, как сообщения ядра Linux, см. dmesg). Такой вывод разбирать легко, даже если добавилось что-то новое. А для наглядного представления нужен ключ (напр. --human-readable).
Кстати, разбирающие текст скрипты предназначены для "лёгкой" обвязки программ. Если формат очень сложный, то он должен быть достаточно распространённый, и уже имеются утилиты (или готовые скрипты) для его разбора. Если он простой или редкий, то написание парсера в любом случае оправдывает себя.
интересно, но все же, для составления окончательного мнения, еще немного поковыряю на выходных:)