Паш это что за программа

а нельзя было сделать по разумному, и вместо гемороя с powershell в windows поставить хотя бы sh? и нервов и денег меньше бы ушло:) да и людям удобно

В форточке несколько лет уже есть 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).

Кстати, разбирающие текст скрипты предназначены для «лёгкой» обвязки программ. Если формат очень сложный, то он должен быть достаточно распространённый, и уже имеются утилиты (или готовые скрипты) для его разбора. Если он простой или редкий, то написание парсера в любом случае оправдывает себя.

PaSh переходит в руки Linux Foundation

Несколько дней назад проект PaSh (разрабатывает инструменты для параллельного выполнения сценариев оболочки) и Linux Foundation объявили, что проект перейдет в руки последнего. который предоставит инфраструктуру и услуги, необходимые для продолжения развития.

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

Linux Foundation, некоммерческая организация, которая обеспечивает массовые инновации с помощью открытого исходного кода, объявила сегодня о размещении в ней проекта PaSh. PaSh — это система для автоматического распараллеливания сценариев оболочки POSIX, которая оптимизирует программы и ускоряет время выполнения, генерируя более быстрые результаты для специалистов по данным, инженеров, биологов, экономистов, администраторов и программистов.

Проект поддерживается Массачусетским технологическим институтом, Университетом Райса, Технологическим институтом Стивенса и Пенсильванским университетом и управляется Техническим руководящим комитетом, в который входят Никос Василакис, научный сотрудник Массачусетского технологического института; Майкл Гринберг, доцент Технологического института Стивенса; и Константинос Каллас, Ph.D. студентка Пенсильванского университета.

ПаШ включает JIT-компилятор, среду выполнения и библиотеку аннотаций:

• Среда выполнения, со своей стороны, предоставляет набор примитивов для поддержки параллельного выполнения скриптов.
• Библиотека аннотаций определяет набор свойств, описывающих ситуации, в которых отдельные команды POSIX и GNU Coreutils могут быть распараллелены.
• Хотя компилятор отвечает за выполнение анализа предлагаемого сценария Shell на лету в абстрактном синтаксическом дереве (AST), он делит его на фрагменты, подходящие для параллельного выполнения, и формирует на их основе новую версию сценария, части которых можно запускать одновременно.
  Компилятор берет информацию о командах, которые можно распараллелить, из библиотеки аннотаций. В процессе создания параллельной исполняемой версии скрипта в код подставляются дополнительные конструкции Runtime.

«Linux Foundation предоставляет инфраструктуру технического управления и услуги, которые необходимы PaSh по мере того, как он становится более зрелым», — сказал Никос Василакис, председатель Технического руководящего комитета проекта PaSh. «Мы создали проект, чтобы улучшить и ускорить выполнение сценария оболочки перед лицом новых изменений сканирования, индексирования и обработки естественного языка».

«Скрипты оболочки широко используются в течение полувека, и недавние тенденции к« контейнеризации »только усилились, — сказал Майкл Гринберг, член Технического руководящего комитета проекта PaSh. «Правильное и автоматическое распараллеливание сценариев оболочки было проблемой в течение нескольких десятилетий. PaSh обещает повышение скорости для всех пользователей оболочки.

Чтобы ускорить сценарии оболочки, PaSh предоставляет компилятор распараллеливания от исходного кода к исходному, программа, которая принимает сценарий оболочки программиста в качестве входных данных и возвращает новую программу, которая значительно быстрее исходной программы.

Поскольку PaSh является источником для источника, позволяет проверять и выполнять оптимизированный сценарий оболочки используя те же инструменты, в той же среде и с теми же данными, что и исходный скрипт.

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

«Проект PaSh представляет собой инновации в области информатики и программного обеспечения с открытым исходным кодом, — сказал Майк Долан, генеральный менеджер и старший вице-президент по проектам Linux Foundation. «По мере того, как разработка программного обеспечения развивается в направлении машинного обучения, контейнеризации, искусственного интеллекта и многого другого, PaSh, похоже, поддерживает разработчиков и специалистов по обработке данных, которым требуется больше от своих инструментов создания сценариев. Мы рады провести эту важную работу в Linux Foundation, естественном доме для такого проекта.

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

Содержание статьи соответствует нашим принципам редакционная этика. Чтобы сообщить об ошибке, нажмите здесь.

Полный путь к статье: Из Linux » новости » PaSh переходит в руки Linux Foundation

Представлен проект Pash, — открытая многоплатформенная реализация MS PowerShell

Представлен проект Pash, — многоплатформенная открытая реализация MS PowerShell с дополнительными возможностями заимствованными из bash. Проект написан использованием .Net 2.0 и требует Mono для своей работы в Linux.

Источники [ править ]

Эта статья содержит материалы из статьи «Представлен проект Pash, — открытая многоплатформенная реализация MS PowerShell», опубликованной OpenNET и распространяющейся на условиях лицензии Creative Commons Attribution (CC BY) — указание автора, источник и лицензию .

Эта статья загружена автоматически ботом NewsBots в архив и ещё не проверялась редакторами Викиновостей.
Любой участник может оформить статью: добавить иллюстрации, викифицировать, заполнить шаблоны и добавить категории.
Любой редактор может снять этот шаблон после оформления и проверки.

Комментарии [ править ]

Викиновости и Wikimedia Foundation не несут ответственности за любые материалы и точки зрения, находящиеся на странице и в разделе комментариев.

Пожалуйста, прочтите правила общения и оформления реплик на портале Викиновости

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

Комментарии на этой странице могут не соответствовать политике нейтральной точки зрения, однако, пожалуйста, придерживайтесь темы и попытайтесь избежать брани, оскорбительных или подстрекательных комментариев. Попробуйте написать такие комментарии, которые заставят задуматься, будут проницательными или спорными. Цивилизованная дискуссия и вежливый спор делают страницу комментариев дружелюбным местом. Пожалуйста, подумайте об этом.

Несколько советов по оформлению реплик:

• Новые темы начинайте, пожалуйста, снизу.
• Используйте символ звёздочки «*» в начале строки для начала новой темы. Далее пишите свой текст.
• Для ответа в начале строки укажите на одну звёздочку больше, чем в предыдущей реплике.
• Пожалуйста, подписывайте все свои сообщения, используя четыре тильды (~~~~). При предварительном просмотре и сохранении они будут автоматически заменены на ваше имя и дату.

Обращаем ваше внимание, что комментарии не предназначены для размещения ссылок на внешние ресурсы не по теме статьи, которые могут быть удалены или скрыты любым участником. Тем не менее, на странице комментариев вы можете сообщить о статьях в СМИ, которые ссылаются на эту заметку, а также о её обсуждении на сторонних ресурсах.

При подготовке материала использовались источники:
https://www.opennet.ru/openforum/vsluhforumID3/41105.html
https://blog.desdelinux.net/ru/%D0%BF%D0%B0%D1%88-%D0%BF%D0%B5%D1%80%D0%B5%D1%85%D0%BE%D0%B4%D0%B8%D1%82-%D0%B2-%D1%80%D1%83%D0%BA%D0%B8-%D1%84%D0%BE%D0%BD%D0%B4%D0%B0-Linux/
https://ru.wikinews.org/wiki/%D0%9F%D1%80%D0%B5%D0%B4%D1%81%D1%82%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82_Pash,_%E2%80%94_%D0%BE%D1%82%D0%BA%D1%80%D1%8B%D1%82%D0%B0%D1%8F_%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE%D0%BF%D0%BB%D0%B0%D1%82%D1%84%D0%BE%D1%80%D0%BC%D0%B5%D0%BD%D0%BD%D0%B0%D1%8F_%D1%80%D0%B5%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F_MS_PowerShell