Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Ок, но это ничего не даст. Текст, который выводится в результате работы скриптов PS — является лишь одним из способов визуального представления возвращаемых командами объектов.
Только фича в том, что для типичных shell-скриптов ничего кроме текста особо и не нужно. А если нужно — то стоит уже явно написать это на чём-то типа Python.

Здравствуйте, Кодт, Вы писали:

К>Я поэтому и запротестовал: xset является элементом ОС, а не шелла.

Я бы сказал, что xset является частью Х-сервера, предназначенной для использования в шелл-скриптах.

TK однажды (26 июня 2008 17:50) писал в rsdn.flame.comp:

>>> Вобщем, что делать с

# There is a known issue that DRI doesn't work on pre-965 if maximum is larger than 2048x2048.

?
> S>Подсказать или сам догадаешся?
> Что, Gentoo это не задета?
Эх...
Поставь тазик рядом. Ибо зная вкусы местный горе-программистов я уверен — буэ потянет.
Поставил? Итак...
Лезеш в ядро, ищеш исходник драйвера видеокарточки, открываеш в редакторе и правиш в нужную сторону до того момента, пока не покажется, что все что мог — сделал.
Потом делаеш diff и отсылаеш в багтрак ядра.
Все довольны и тебе говорят спасибо.

--
...belive in the matrix...

Здравствуйте, Roman Odaisky, Вы писали:

RO>xset является элементом unix way. /bin/bash беспомощен без ls, cp, mv, cat, echo, sort, uniq, find и т. д., и что?

В цигвине все эти ls, cp и прочий феншуй (пардон, юниксвей) есть. А иксов нет...

Здравствуйте, Кодт, Вы писали:

RO>>xset является элементом unix way. /bin/bash беспомощен без ls, cp, mv, cat, echo, sort, uniq, find и т. д., и что?
К>В цигвине все эти ls, cp и прочий феншуй (пардон, юниксвей) есть. А иксов нет...
Вообще говоря, есть (посмотри сам в программе установки). Но оно работает как обычное приложение Windows, следовательно не имеет контроля над экраном и разрешением.

Здравствуйте, Sheridan, Вы писали:

S>Все довольны и тебе говорят спасибо.

Потом считаешь потраченное время, умножаешь на часовую ставку среднего программиста и понимаешь, что дешевле было купить Висту

Roman Odaisky пишет:
>
> Во-первых, спасибо Владимиру за примеры.
>
> Вот что я понял. Что такое оболочка, она же shell, представителями
> которой являются bash, PowerShell и многие другие? Это язык
> программирования, отличающийся тем, что он в первую очередь приспособлен
> для запуска внешних программ (синтаксически, большинство оболочек
> запускает программы простым указанием их имени) и его интерпретатор,
> который позволяет исполнять программы на этом языке как интерактивно,
> так и неинтерактивно.
>
Вот именно.

>
> Проблема только в том, что ни то, ни то не приносит существенных
> преимуществ.
+1

Существенным преимуществом для меня было бы, например, экспорт делагатов
на файловую систему. Или директория как first order object. Чтобы
директорию можно было вернуть из функции, например. IIRC в Plan9
переменные среды были директориями.

На уровне ассемблера нужно думать, где разместить ту или иную
переменную, в регистре или памяти. Объекты в памяти адресовать косвенно
или со стека. bash — это как шелловый аналог ассемблера. Хорошо,
МАКРОассемблера, но всё равно ассемблера. Он не позволяет действительно
подняться на уровень выше.

> Вывод: PowerShell — это видоизменение C# путем смены синтаксиса,
> добавления интерпретатора и интерактивного режима, цель чего избегает
> моего понимания.
+1

И то, и другое из того, что я предложил навскидку, можно реализовать в
виде библиотек. Однако, в шелле им самое место.

--
ISO/IEC 8652:1995/Amd 1:2007

Lloyd однажды (26 июня 2008 23:46) писал в rsdn.flame.comp:

> Потом считаешь потраченное время, умножаешь на часовую ставку среднего программиста и понимаешь, что дешевле было купить Висту
Вот именно изза этого я и называю вас горе-программистами.
Потому как у вас все исчисляется не готовыми продуктами/красивым кодом/законченными проектами/участием в открытых проектах, а баблом, баблом и еще ленью.
Казалось бы — вот программист, он знает язык, он знает механизмы, умеет читать доки и искать нужное в этих доках, ну что ему стоит сесть и подправить чужой код?
Ан нет — только брезгливо морщатся. Куда ж им, императорам личности в руки марать...

--
...belive in the matrix...

Здравствуйте, Sheridan, Вы писали:

>> Потом считаешь потраченное время, умножаешь на часовую ставку среднего программиста и понимаешь, что дешевле было купить Висту
S>Вот именно изза этого я и называю вас горе-программистами.

Ты совершенно прав, как программист-железячник я — горе, у меня другая специализация.

S>Потому как у вас все исчисляется не готовыми продуктами/красивым кодом/законченными проектами/участием в открытых проектах, а баблом, баблом и еще ленью.

О, пошла новая риторика. Как кто начинает сравнивать линух с виндой, так вы сразу ныть начинаете, что дорого. А теперь оказывается, что для вас главное — красота

S>Казалось бы — вот программист, он знает язык, он знает механизмы, умеет читать доки и искать нужное в этих доках, ну что ему стоит сесть и подправить чужой код?

Ну языком-то просто болтать, ты взял бы и поправил, если так все просто.

S>Ан нет — только брезгливо морщатся. Куда ж им, императорам личности в руки марать...

нет, просто прежде чем принимать решение, нужно оценивать эффективность решения. в описанном сценарии линукс чисто сливает.

Здравствуйте, OCTAGRAM, Вы писали:

OCT>Существенным преимуществом для меня было бы, например, экспорт делагатов
OCT>на файловую систему. Или директория как first order object. Чтобы
OCT>директорию можно было вернуть из функции, например. IIRC в Plan9
OCT>переменные среды были директориями.
Это в теории хорошо выглядит, на практике появляются вопросы. В частности, возможны неустранимые race-condition'ы и прочие проблемы.

Это в Reiser4 была такая возможность — монтировать каталоги как файлы. Разработчики Linux VFS как раз из-за этих проблем и забраковали такую фичу.

С другой стороны, в Линуксе, на Маках и прочих FreeBSD (и даже уже на Windows ) есть FUSE — на его основе такое можно попробовать сделать.

Lloyd однажды (27 июня 2008 00:10) писал в rsdn.flame.comp:

> Ну языком-то просто болтать, ты взял бы и поправил, если так все просто.
Когда меня касалось — правил.

--
...belive in the matrix...

Cyberax пишет:
>
> Здравствуйте, OCTAGRAM, Вы писали:
>
> OCT>Существенным преимуществом для меня было бы, например, экспорт
> делагатов
> OCT>на файловую систему. Или директория как first order object. Чтобы
> OCT>директорию можно было вернуть из функции, например. IIRC в Plan9
> OCT>переменные среды были директориями.
> Это в теории хорошо выглядит, на практике появляются вопросы. В
> частности, возможны неустранимые race-condition'ы и прочие проблемы.
>
Неустранимые проблемы, какие есть, есть и сейчас, только сейчас
устранимых больше.

> Это в Reiser4 была такая возможность — монтировать каталоги как файлы.
> Разработчики Linux VFS как раз из-за этих проблем и забраковали такую фичу.
>
А как это вообще связано с 9P?

> С другой стороны, в Линуксе, на Маках и прочих FreeBSD (и даже уже на
> Windows ) есть FUSE — на его основе такое можно попробовать сделать.

Такое — это что? экспорт делагатов на файловую систему или директория
как first order object? Ни для того, ни другого FUSE не нужен.

Экспорт делегатов на файловую систему реализуется как исполняемые
файлы–заглушки с содержимым типа #!/usr/bin/delegate-stub /path/to/IPC
delegate-stub связывается по IPC с оригинальным процессом, и затем, как
зомби, выполняет все приходящие ему команды. Пишет в stdout, читает
stdin — всё по команде от оригинального процесса. FUSE здесь как раз не
поможет. Я не знаю, было ли это сделано в Plan9, но вообще, там можно
было бы обойтись без хаков типа "#!/usr/bin/delegate-stub /path/to/IPC",
если эффект запуска программы так же программируем, как и сама файловая
система.

Директория как first order object тоже FUSE вполне реализуема. Да и FUSE
тут ничего не решает. Директорию надо где–то хранить, на диске или в
памяти. Временные объекты в /tmp, постоянные на ЖД. А FUSE как бы никуда
и не вписывается здесь. Тут главное, чтобы shell сам размещал временные
директории где–нибудь, а где — не прослеживалось бы так явно, как сейчас.

--
ISO/IEC 8652:1995/Amd 1:2007

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Ок, но это ничего не даст. Текст, который выводится в результате работы скриптов PS — является лишь одним из способов визуального представления возвращаемых командами объектов.
C>Только фича в том, что для типичных shell-скриптов ничего кроме текста особо и не нужно.

Да? Хочешь сказать, что содержимое каталога легче и проще обрабатывать в виде plain-text, нежели в виде связного списка или хэш-таблицы?

Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, Кодт, Вы писали:

К>>Я поэтому и запротестовал: xset является элементом ОС, а не шелла.

RO>xset является элементом unix way. /bin/bash беспомощен без ls, cp, mv, cat, echo, sort, uniq, find и т. д., и что?

Протестую! echo is builtin! В остальном,

function ls()
{
echo $1/*
}

function cat() {
while read; do
echo $REPLY
done < $1 > $2
}

и т.д. Я сейчас слишком пьян, чтобы написать на баше sort, но uniq, согласитесь, пишется тривиально.

vnp> done < $1 > $2

vnp>и т.д. Я сейчас слишком пьян

поэтому перенаправления не нужны.

Здравствуйте, Roman Odaisky, Вы писали:

RO>Во-первых, спасибо Владимиру за примеры.



RO>PowerShell — это C# со специфическим синтаксисом (впрочем, то же самое можно сказать про любые другие два языка из .NET) и интерпретатором. Что она может? То же, что и C#. Что она может удобнее и проще, чем C#? Работать интерактивно и взаимодействовать с другими программами.

PS не имеет никакого отношения ни к С# и его синтаксису в частности, ни к .NET в целом, за исключением того, что является "мостиком" для использования возможностей .NET в задачах управления и конфигурирования ОС.

RO>Проблема только в том, что ни то, ни то не приносит существенных преимуществ. В интерактивной работе PowerShell заметно проигрывает той же zsh, преимущественно из-за автодополнялки

следующий код в PS:

$folder1 = Get-ChildItem("C:\Temp")
$folder2 = Get-ChildItem("C:\Compaq")
Compare-Object $folder1 $folder2

набирается (в стандартной PS-консоли) следующим образом:

$folder1 = Get-C<Tab>("C:\T<Tab>")
$folder2 = Get-C<Tab>("C:\C<Tab>")
Comp<Tab-Tab> $f<Tab> $f<Tab-Tab>

Путь можно было бы пролистывать "C:<Tab-Tab-Tab...>", вторую команду можно было бы не набирать заново, а нажав стрелку вверх вернуть предыдущую команду и откорректировать ее и т.д. и т.п. В чем тут PS проигрывает zsh?

RO>и сложных shell patterns (они же шаблоны или wildcards). Первое к PowerShell приделать можно, а второе — очень затруднительно из-за того, что традиционно со времен DOS программы сами обрабатывают свои аргументы и раскрывают шаблоны. Взаимодействие же с другими программами затруднено тем, что взаимодействовать-то не с чем. В Unix традиционно большинство возможностей доступны в виде программ командной строки, которые хорошо взаимодействуют между собой, но не так обстоят дела в MS Windows. Много ли толку от сокращенной записи
<skipped>
RO>если мало программ имеют вывод, годный для переадресации в другие программы?

Хм...

$ipstring = ipconfig.exe | select-string "IP-" | select-object; $ipstring.ToString().Split(":")[1].Trim() | echo

— выведет IP первого интерфейса, полученный из стандартной ipconig.

И?

Куча програм, которые можно связать между собой средствами шелла — это Unix-way, да. Но я же и не утверждаю, что PS лучше подойдет в nix-среде, чем ее родные оболочки? Спор был о том, что PS дает windows-администратору не менее полноценный и удобный контроль над ОС нежели аналогичные средства под никсах

Winway'ем в данном случае (а точнее — psway'ем), является наличие кучи командлетов (бинарных модулей, либо сценариев PS), взаимодействующих между собой в т.ч. и по тем же пайпам, используя в качестве формата данных не простой текст, а более структурированные и управляемые сущности. Возможность же вызвать стандартную ping.exe и легко распарсить ее вывод — никто у PS не отбирал. Просто этот unix-way не так удобен, как например, использование .NET'овского ping'a.

RO>В MS Windows это делается не шелловым скриптом, а целой программой, которая в лучшем случае выглядит как library2.process_data(library1.get_data()).

С чего это ты взял?

RO>Если я кого-то не убедил, предлагаю посчитать, сколько раз Владимир вызывал из своих скриптов внешние программы, что так легко делать в шеллах, стоит лишь упомянуть их имя. Положительного числа не получится.

Задача шелла — не облегчить взаимодействие внешних программ. Это — лишь один из путей решений общей задачи управления системой, стоящей перед любым шеллом.

RO>В Unix на шелле никто не пишет большие программы. Шелловые скрипты просто служат для «склейки» воедино разных кусочков системы. Например, есть папка /etc/acpi/suspend.d, в которой находятся исполняемые файлы, которые система исполняет при переходе в ждущий режим. Если я хочу выгрузить какой-нибудь модуль, или отправить куда-то сообщение, или еще что-нибудь, я положу туда свой файл. Что, как не шелл, лучше всего подойдет для этого? Я могу написать бинарник хоть на C, системе всё равно, но проще всего положить туда «for i in $INTERFACES; do ifconfig $i down; done», чем пытаться сделать то же на «серьезном» языке программирования. Т. е., этот скрипт будет просто мостиком между /etc/acpi/hibernate.sh и /sbin/ifconfig, не делая сам по себе никакой особенной работы.

В никсах шелл-скрипты — фактически являются частью ОС. Это не говорит о том, что под виндой должно быть точно также.

RO>Типичная юниксовая система (основанная на SysV init, т. е., почти любая, даже Ubuntu с ее upstart) исполняет при загрузке несколько сотен шелловых скриптов для запуска нужных программ. PowerShell бы для этого не подошла.

А кто утверждал, что она подойдет для init'a никсовой системы?

RO>Вывод: PowerShell — это видоизменение C# путем смены синтаксиса, добавления интерпретатора и интерактивного режима, цель чего избегает моего понимания.

"это видоизменение C# путем смены синтаксиса" — это сильно. Синтаксис паскаля тоже можно доработать напильником, чтобы perl получился Цель создания PS — дать возможно полноценно управлять ОС из командной строки, как в интерактивном режиме, так и из сценариев.

S>Лезеш в ядро, ищеш исходник драйвера видеокарточки, открываеш в редакторе и правиш в нужную сторону до того момента, пока не покажется, что все что мог — сделал.
S>Потом делаеш diff и отсылаеш в багтрак ядра.
S>Все довольны и тебе говорят спасибо.

Ну. Его. Нафиг.

Я лучше в бассейн схожу/айкидо позанимаюсь

Здравствуйте, Mamut, Вы писали:

M>Я лучше в бассейн схожу/айкидо позанимаюсь

Айкидо гон. Айкидо не занимайся. Тут тебе щаз реально скажут чем занятся

Здравствуйте, Sheridan, Вы писали:

S>Лезеш в ядро, ищеш исходник драйвера видеокарточки, открываеш в редакторе и правиш в нужную сторону

А мне что делать? Нет, я серьезно... У меня вот на ноуте PCMCIA EDGE-модем в линуксе глючит, я уже писал об этом. Навыков программирования драйверов под линукс — у меня нет, тема — слишком серьезная для меня как для непрограммера, чтобы заняться ее изучением ради настройки модема. Что делать-то?

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Предлагаю баттл. Каждый нечетный раунд — мой, каждый четный — твой. "Хозяин" раунда озвучивает задачу, решенную им с помощью одного из сабжевых средств и представляет, собственно — решение. Второй — решает эту же задачу с помощью своего средства. Остальные — оценивают каждое из сообщений (1,2,3). Играем 10 раундов, каждый ведет по 5. По результатам — сложим оценки и определим победителя. Готов?

Шеридан, третий раунд играть будем, или и так — уже каждый свои выводы сделал и все понял? Если будем — закину условия задачи.