1.1, Аноним (-), 12:59, 08/04/2008 [ответить]
| +/– |
а нельзя было сделать по разумному, и вместо гемороя с powershell в windows поставить хотя бы sh? и нервов и денег меньше бы ушло:) да и людям удобно
| |
1.3, Аноним (3), 17:00, 08/04/2008 [ответить]
| +/– |
В форточке несколько лет уже есть csh, в SFU - точно есть. А вот напуркуа в Unix это [..beeep..]? Разве что заказ мелких ....
| |
1.4, sokoloff (ok), 12:56, 09/04/2008 [ответить]
| +/– |
Сразу оговорюсь, все написанное мое личное мнение, я не являюсь гуру в PowerShell, просто немного интересуюсь этой темой.
На мой взгляд идея PowerShell очень интересна, и это очень «юниксвейно», даже странно, что то придумал не кто то из мира UNIX а Microsoft.
Если не смотреть на авторство и конкретную реализацию, а рассматривать саму технологию, то это могло бы стать серьезным шагом вперед. Ведь в чем фишка UNIX, в каналах и перенаправлении, в построении цепочек из программ. Текстовые каналы замечательно работали во времена чистой консоли, и простых тестовых форматов, но начинают пробуксовывать если форматы данных сложные. Например, с помощью grep, sed и.т.д. вы можете легко удалить или добавить строки в файл aliases, но изменение XML уже будет довольно сложной задачей. А как вы будете редактировать файлы OO?
Плюс для написания хорошего скрипта вам надо досканально знать формат файла, а после выхода новой программы скрипт может перестать работать (например в конфиге появился новый праметр, этот параметр вашему скрипту и не нужен совсем, но регулярное выражение в скрипте перестало работать), соответственно вам нужно постоянно следить за изменениями во всех программах, с которыми работает ваш скрипт. IMHO это причина почему нет полноценных, универсальных, графических конфигураторов.
В классические каналы вообще толком не работают, иксовые программы нелинейны. Да, есть графические "морды" к консольным утилитам, но интерактивность их оставляет желать лучшего, поэтому и появляются различные Bonobo, KPart, D-bus и.т.д. но это все скорее для программиста а не для простого пользователя.
Переход от чисто ткстовых каналов к ООП, позволит убрать многие проблемы, сделать скрипты проще, упростить сопровождение. А если вместо линейного канала, ввести разветвленный граф то это может изменить всю систему взаимодействия иксовых приложений.
| |
|
2.5, yan (??), 14:54, 09/04/2008 [^] [^^] [^^^] [ответить] | +/– | Аналогично, все нижесказанное, только IMO Возможно идея и интересна, но реализац... большой текст свёрнут, показать | |
|
3.6, sokoloff (ok), 16:19, 09/04/2008 [^] [^^] [^^^] [ответить] | +/– | Согласен, но про реализацию я написал в первом посте Не факт, предположим нам в... большой текст свёрнут, показать | |
|
4.8, text (?), 13:12, 23/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Например я написал программу показывающую статистику по загруженности канала, а в следующей версии, по просьбам радиослушателей я добавил вывод макс. пикового значения. Конфиг остался неизменным, зависимости от библиотек не изменились. Backward compatibility есть? Конечно. А ваши скрипты поехали. Мне, как разработчику, это может даже в голову не прийти.
Хорошие UNIX-программы вообще ничего не выводят в stdout, если об этом их не попросят параметрами. И да, многие из старых программ не являются хорошими в этом смысле.
Кроме того, даже если программа "информативная", она должна выдавать информацию построчно (например, как сообщения ядра Linux, см. dmesg). Такой вывод разбирать легко, даже если добавилось что-то новое. А для наглядного представления нужен ключ (напр. --human-readable).
| |
4.9, text (?), 13:15, 23/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
Кстати, разбирающие текст скрипты предназначены для "лёгкой" обвязки программ. Если формат очень сложный, то он должен быть достаточно распространённый, и уже имеются утилиты (или готовые скрипты) для его разбора. Если он простой или редкий, то написание парсера в любом случае оправдывает себя.
| |
|
|
|
1.7, yan (??), 21:29, 10/04/2008 [ответить]
| +/– |
интересно, но все же, для составления окончательного мнения, еще немного поковыряю на выходных:)
| |
|