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

N>На конвейер подобного рода есть библиотеки
Вы их не привели. И в любом случае, то что в powershell делается элементарно и на уровне базового синтаксиса от питона требует изучения библиотек

N>но ты учти, что sort по любому должен всосать весь вывод. Или пример плохой, надо было вместо sort какой-нибудь cut вызвать.
Какая разница "надо или не надо" всосать всё? Вы дополнительно делайте пару локальных копий данных, которые могут быть очень немаленькими.

N>В данном случае я этому Рабиновичу доверяю. И ещё проверил по документации от MS. Или там безнадёжно кривая и неполная документация, или средств, которые были бы полезны для Unix (а не какие-нибудь WMI), отсутствуют от слова "совсем".
N>И зачем он тогда нужен — только как специфически подвинутый bash? Я лучше таки тогда собственно bash применю.
Смешно, учитывая что для маломальски сложного скрипта зачастую рекомендуют выкинуть баш и взять питон. Вот именно для этого и нужен powershell — как удобный инструмент именно для shell-скриптинга.

N>Да. Ну если документировано, то не совсем хаки? Хотя при отношении MS к командной строке (в родном интерфейсе это не массив, а одна строка) не удивляюсь.
Не хак, наверно, но я не понимаю зачем такое может понадобиться в принципе.

N>>>Не катит, на убунте по умолчанию не присутствует в репах.
S>>И что? А у меня питон не установлен в винде. Или ставьте powershell, или гуглите — гугль первым результатом выдаёт ссылку на онлайновую документацию.

N>Ну вот я и погуглил. Есть рассказы, как его ставить под десяток линуксовых дистрибутивов, но ни одного, где бы пояснялось, нафига он там вообще нужен — как сделать какие-нибудь стандартные фокусы типа "вывести самый наевший процессора тред из текущих в системе", "какой юзер захватил порт N", "сколько у нас активных контейнеров со своими именами и cgroups" и т.п.
За тем же, для чего и питон — для создания скриптов сложнее чем "scp bla-bla-bla root@host:".

N>Для начала — отсутствие кодового усложнения (контроль на хранении в FS, на чтении и интерпретации имён файлов и т.д.) там, где и без него много проблем.
То, что в линуксе это не осилили не делает это не правильным.

N>Нет хаков под несуществующие проблемы => нет проблем, созданных этими хаками.
И это не "упрощение", это перенос проблем на сторону пользователя.

S>>Можно примеры случаев, когда проблемы от CI в файловой системе не были бы вызваны плохой архитектурой приложения? Потому что файловая система не предназначена для хранения произвольных данных в именах файлов, а вы, насколько я понимаю, защищаете именно возможность не сохранить именованые данные, а сохранить данные в имени.
N>Это именно что вопрос именования (не каламбур). Нет необоснованных ограничений => нет неожиданных конфликтов.
"Обоснованные ограничения" есть в свои в сотнях файловых систем, и далеко не все касаются регистра файлов (ограничения на длинну имени, на спецсимволы, глубину каталогов), поэтому использовать имена файлов для хранения данных в общем случае не получится. А считать что "вот тут должно работать так, на всё остальное плевать" — изначально глупо.