PowerShell открыт и доступен для Linux

баш позволяет так писать

???

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

какая разница как оно было в лохматых годах?

Как это какая? Настоящее — это отражение прошлого. Ответы на вопрос «почему сегодня так» всегда ищутся в прошлом, а не в настоящем. Странно это не понимать.

а ты чего [слово] «корявый» опустил?

А что мне с ним надо было сделать? Ответ на вопрос «зачем нужен простой язык» существует. Ответа на вопрос «зачем нужен корявый язык» не существует, поскольку это не вопрос, а наезд.

Я правда не понял смысла брать только топ-5 из тех процессов, у каких приоритет больше семи, но то как вам удобнее.

Ну это просто чтобы продемонстрировать наличие логики. Вот вариант на поше:

ps | where BasePriority -gt 7 | sort WorkingSet | select -Last 5 | measure WorkingSet -Average

обратив внимание на следующее:

Сортировочка и парсинг вывода фактически сделаны методами самого пс, а не баша, то есть разработчики утилиты пс позаботились о том, чтобы ты мог выводить колоночки по именам, каким-то понятным образом сортировать и т.п. (как в павершеле). Причем, чтобы это сделать, тебе надо прочитать ман по пс. Если ты захочешь решить ту же задачу для другой тулзы, то тебе надо будет читать ман для другой тулзы (и запоминать), а если таких тулз 10, 20, 100? Если же разработчики не позаботятся а наличии нужный параметров - то тебе придется парсить грепом/авком, и это будет вообще ад.

В павершеле же, если ты знаешь как работает сортировка или фильтрация - то ты можешь сортировать все, что угодно, выхлоп любого командлета. Не надо курить 20-страничные мануалы, не надо ничего вот этого - я когда писал вышеприведенный однострочник, то никаких мануалов не смотрел, и любой человек которого только посадили за пош напишет элементарно этот однострочник без подглядывания куда бы то ни было, ему только нужно знать как работает where/sort/measure/select (да и при том необязательно хорошо)

Это сумма выделенных для процесса физических страниц.

То есть RSZ за вычетом выделенного на разделяемые библиотеки?

Я же выше сказал, не парься,...

С чего бы? Здесь только вы кругозор повышаете, что ли, мне нельзя?

То есть RSZ за вычетом выделенного на разделяемые библиотеки?

Разделяемые библиотеки тоже входят в рабочий набор. Working set - это resident set за исключением тех страниц, которые можно деаллоцировать, не опасаясь, что процесс сломается. Например, jvm не возвращает однажды выделенную память системе, т.о. resident set при работе не уменьшается. А вот working set - вполне уменьшается, т.к. может быть куча памяти, которую системе отдать можно, т.к. она не используется де-факто.

и парсинг вывода фактически сделаны методами самого [ps]

???

ps здесь не парсит ничей вывод. Вы хотели отметить, что мне позволено выбрать только желаемые колонки?

Если же разработчики не позаботятся а наличии нужный параметров - то тебе придется парсить грепом/авком

Сфигли бы здесь «придется» что-то «парсить Грепом» (хотя, разумеется, не возбраняется)? Вся разница будет в том, что мне придется оперировать большим числом колонок — и смотреть документацию для этого как раз не обязательно, надо посмотреть на фактический вывод.

и это будет вообще ад.

Если я захочу, что «парсить АВКом», то это будет ровно то, что вы написали на ПШ, с той лишь разницей, что опять же — придется оперировать номерами колонок. Собственно с этой писательской парадигмы ПШ и содран. Мне она не очень нравится, но странно, что вы ее одновременно зовете «адом» и превозносите.

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

Ага, только это ваше «все, что угодно» — это ограниченный набор утилит, написанных специально для ПШ.

т.о. resident set при работе не уменьшается.

Точнее, он может уменьшится, если например будет скинут в пейджфайл, в этом случае и ws уменьшается. Ну, в общем, смысл понятен.

ps здесь не парсит ничей вывод. Вы хотели отметить, что мне позволено выбрать только желаемые колонки?

Именно. Выбор желаемых колонок по названию и сортировка.

Сфигли бы здесь «придется» что-то «парсить Грепом» (хотя, разумеется, не возбраняется)? Вся разница будет в том, что мне придется оперировать большим числом колонок — и смотреть документацию для этого как раз не обязательно, надо посмотреть на фактический вывод.

Ну это тебе повезло, что пс кастрированный и в нем колонок мало. Вот представь себе, если бы он был аналогичен Get-Process из поша, у которого их сто с лишним.

? Собственно с этой писательской парадигмы ПШ и содран.

Конечно нет, пош с нее не содран, а сделан как раз обратным образом.

Если я захочу, что «парсить АВКом», то это будет ровно то, что вы написали на ПШ, с той лишь разницей, что опять же — придется оперировать номерами колонок.

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

Ага, только это ваше «все, что угодно» — это ограниченный набор утилит, написанных специально для ПШ.

Это абсолютно все системное апи. Командлеты - это обертки вокруг системных вызовов, которые дают более удобный и лаконичный синтаксис, не более того.

Командлеты - это обертки вокруг системных вызовов, которые дают более удобный и лаконичный синтаксис, не более того.

собственно, в этом еще одно важное преимущество поша над башем - если пош фактически напрямую работает с апи ситемы, то баш работает со сторонними утилитами, которые там уже сами как-то в меру своей испорченности дергают апи.

Любой язык позволяет писать через заднее место.

в баш, кроме корявого, плохо читаемого синтаксиса, нужно еще знать о кучи pitfalls. не так уж это «просто»

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

с культурой в других языках тоже лучше

Как это какая? Настоящее — это отражение прошлого. Ответы на вопрос «почему сегодня так» всегда ищутся в прошлом, а не в настоящем. Странно это не понимать.

зачем сейчас нужен баш?

Вот представь себе, если бы он был аналогичен Get-Process из поша, у которого их сто с лишним.

Ну уж чем богаты. Позвольте, я не буду сейчас выписывать все 119 (сто девятнадцать) колонок которые есть у ps(1) из procps-ng (который обычно стоит в ГНУ, и которым выше я и пользовался), тем паче что часть из них — синонимы других, а выберу для иллюстрации штук шестнадцать, ОК?

$ export PS_FORMAT='%cpu,time,nice,pri,%mem,rsz,vsz,size,pid,ppid,user,group,fuser,fgroup,tty,args'

При этом тебе надо гарантировать, что все данные корректны, что будет, если в имени процесса, например, есть пробельные символы?

То это поле либо будет последним, либо разделителем колонок будет другой символ — не пробел.

И как потом этот скрипт читать, с номерами?

«Константы? Не, не слышал».

$ Priority=4
$ VSize=7

Собственно с этой писательской парадигмы ПШ и содран.

Конечно нет, пош с нее не содран, а сделан как раз обратным образом.

Я не говорю о том, как МС ПШ сделан — сделан он разумеется с точностью до наоборот — вместо простого, но универсального инструмента, дико сложная вещь в себе. Я говорю о том, с чего содран интерфейс — то есть язык. Вот с этого:

$ ps -e | awk "\$$Priority > 7" | sort -nk $VSize | tail -5 | awk "{ vsz+=\$$VSize }; END { print vsz / NR }"

И это будет жуткий вырвиглаз.

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

И почему вы ее превозносите, когда ее самую внезапно берет на вооружение уже Микрософт — не понимаю. Любовь ко всему, что бы ни сделал МС?

Это абсолютно все системное апи. Командлеты - это обертки вокруг системных вызовов, которые дают более удобный и лаконичный синтаксис, не более того.

То есть ограниченный набор утилит, написанный специально для МС ПШ. «Выбор желаемых колонок по названию и сортировка», но не для одного ps(1), а для много большего числа программ, только и всего.

Позвольте, я не буду сейчас выписывать все 119 (сто девятнадцать) колонок которые есть у ps(1)

А где можно посмотреть список? что-то не гуглится. Ну и ты тут сам себе противоречишь - как ты собрался без курения манов выбирать эти поля?

То это поле либо будет последним, либо разделителем колонок будет другой символ — не пробел.

А если не будет? А если другой разделитель окажется там? А если это не одно поле, в котором может оказаться данный разделитель?

Я не говорю о том, как МС ПШ сделан — сделан он разумеется с точностью до наоборот — вместо простого, но универсального инструмента, дико сложная вещь в себе.

Все наоборот. Пош как раз прост и универсален - если ты умеешь в сорт, то этот сорт везде одинаков. В случае баша каждая тулза имеет (в лучшем случа) свой собственный сорт работающий по своим собственным правилам, со своим собственным синтаксисом и своими pitfalls. В итоге баш невозможно использовать без курения многостраничных мануалов на каждый чих.

Я говорю о том, с чего содран интерфейс — то есть язык. Вот с этого:

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

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

Ага, я тоже. Но баш альтернатив не представляет, по факту, так что преимущества поша очевидны.

То есть ограниченный набор утилит, написанный специально для МС ПШ.

Я не понимаю, о чем ты. Никаких утилит, написанных специально для пош, не существует. Ни одной. Командлеты пишутся на самом поше и дергают системное апи, то же самое, которое дергают любые другие приложения, например, на С#. Или на си.

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

а для много большего числа программ

Для ВСЕХ программ.

«Константы? Не, не слышал».

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

BSOD

Это уже было реализовано в 90-х в xscreensaver :)

Синтаксис команд придуман обдолбанными в хлам индусами.

Наследие winapi. Меня вот тоже «радовали» название функций в нем. А отдельно доставляло несовместимость параметров между версиями винды.

Там полный синтаксис команд логичен и последователен. Нет зоопарка из разных вариантов сокращений, разных стилей передачи параметров и т.п. Всегда Verb-Noun -ParameterName ParameterValue ..., причем Verb желательно использовать из списка рекомендованных (хотя никто не запрещает использовать любой). Это принятый стиль для скриптов, а для терминала есть сокращения. Во-первых можно для любой команды / команды + параметров задать алиас, делается это элементарно (Set-Alias/sal). Во-вторых сами командлеты не чувствительны к регистру - можно писать хоть ЗаБоРчИкОм. В-третьих параметры тоже могут иметь алиасы + любое недвусмысленное сокращение параметра автоматически является корректным алиасом (то есть -InputObject можно сократить то -in если нет других параметров начинающихся с -in, даже если -in не задан как алиас). Зато с такими правилами именования читать скрипты вполне можно без чтения сотен манов.

119 колонок которые есть у ps(1)

А где можно посмотреть список?

В ps(1). :-) Так ссылки на man-страницы пишутся, если что. Если у вас под рукой нет запущенной ГНУ, чтоб приказать $ man 1 ps, то всегда можно найти где-нибудь в Сети, например.

Ну и ты тут сам себе противоречишь - как ты собрался без курения манов выбирать эти поля?

Перечитайте наш с вами диалог, пожалуйста. Я в ответ на ваше «именно выбор желаемых колонок и сортировка» привел пример работы с программой, что якобы *не умеет* фильтровать поля сама, а выводит *все*, что может не сортируя.

А если не будет?

То это ошибка в проектировании интерфейса, пишите багрепорт.

А если это не одно поле, в котором может оказаться данный разделитель?

Вы дико невнимательны. «Разделителем колонок будет [может быть] другой символ».

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

А при чем здесь Баш? Эти программы никакого отношения к Башу не имеют. И, вы может быть, не в курсе, но большинство программ, выводящих что-то на стандартный вывод, никаких сортировок и фильтров не имеет. В итоге даже там, где они есть, люди ими часто не пользуются, вызывая универсальный sort(1), как я это сделал выше.

Я не понимаю, о чем ты. Никаких утилит, написанных специально для пош, не существует.

Ага. А это что?

ps | where BasePriority -gt 7 | sort WorkingSet | select -Last 5 | measure WorkingSet -Average
^^

Я говорю о том, с чего содран интерфейс — то есть язык. Вот с этого:

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

Ну посмейтесь — может быть пройдет и вы перестанете отрицать очевидное, а именно то, что придуман МС ПШ именно под влиянием программирования текстовыми фильтрами типа sort, uniq, grep, wc через конвейер.

Одноразовая вещь, короче — написал, прочитал вывод, и выкинул. Я поэтому эту парадигму и не люблю.

Ага, я тоже. Но баш альтернатив не представляет, по факту,

Ну как же не предоставляет? Я же вам выше написал пример, как писать такое именно на Баше, а не цепочкой фильтров.

так что преимущества поша очевидны.

Какие еще «преимущества»? Я не знаю, можно ли на МС ПШ писать по-нормальному (алгоритмически) — наверное, можно, но вы-то ваш образцовый пример на МС ПШ написали именно в парадигме «однострочника», то есть выпятили ее недостаток.

get-alias ps

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Alias           ps -> Get-Process

man get-process -detailed

ИМЯ
    Get-Process

ОПИСАНИЕ
    Gets the processes that are running on the local computer or a remote computer.


СИНТАКСИС
    Get-Process [[-Name] <String[]>] [-ComputerName <String[]>] [-FileVersionInfo] [-InformationAction {SilentlyContinu
    e | Stop | Continue | Inquire | Ignore | Suspend}] [-InformationVariable <System.String]>] [-Module] [<CommonParame
    ters>]

    Get-Process [-ComputerName <String[]>] [-FileVersionInfo] [-InformationAction {SilentlyContinue | Stop | Continue |
     Inquire | Ignore | Suspend}] [-InformationVariable <System.String]>] [-Module] -InputObject <Process[]> [<CommonPa
    rameters>]

    Get-Process [-ComputerName <String[]>] [-FileVersionInfo] [-InformationAction {SilentlyContinue | Stop | Continue |
     Inquire | Ignore | Suspend}] [-InformationVariable <System.String]>] [-Module] -Id <Int32[]> [<CommonParameters>]

    Get-Process [-InformationAction {SilentlyContinue | Stop | Continue | Inquire | Ignore | Suspend}] [-InformationVar
    iable <System.String]>] -Id <Int32[]> -IncludeUserName [<CommonParameters>]

    Get-Process [-InformationAction {SilentlyContinue | Stop | Continue | Inquire | Ignore | Suspend}] [-InformationVar
    iable <System.String]>] -IncludeUserName -InputObject <Process[]> [<CommonParameters>]

    Get-Process [[-Name] <String[]>] [-InformationAction {SilentlyContinue | Stop | Continue | Inquire | Ignore | Suspe
    nd}] [-InformationVariable <System.String]>] -IncludeUserName [<CommonParameters>]

ps - это алиас командлета Get-Process. Он не является утилитой, командлеты скорее являются функциями (они могут быть как реализованы на .NET, так и на самом PowerShell), которые могут работать с объектным пайпом. Сама по себе эта функция просто использует системное API для получения списка процессов и возвращает его в виде массива .NET объектов (System.Diagnostics.Process). Ничто не мешает на самом PowerShell реализовать аналог самому. Она никак не занимается форматированием, сортировкой, она делает только то, для чего она предназначена. Если ничего дополнительно не делать с её результатом PowerShell просто будет использовать форматирование по-умолчанию для вывода на терминал. Дальше с этим массивом можно делать что угодно - можно сохранить в переменную и работать как в обычном императивном ЯП общего назначения с ним (поскольку PowerShell является по сути полноценным интерпретируемым языком общего назначения), можно через пайп передать в другие командлеты.

Я в ответ на ваше «именно выбор желаемых колонок и сортировка» привел пример работы с программой, что якобы *не умеет* фильтровать поля сама, а выводит *все*, что может не сортируя.

Ну так в пс позаботились о возможности вывода отдельных полей, то есть оно работает только благодаря заботливым разработчиком пс. И тут варианты такие: либо разработчики вынуждены реализовывать выборку по полям, либо они не могут делать много полей (чтобы пользователь мог взглядом окинуть и сам посмотреть), либо мы получаем ад и погибель. Варианта при котором «все just works», как в случае поша, баш не предоставляет.

То это ошибка в проектировании интерфейса, пишите багрепорт.

В чем ошибка? Интерфейс в виде плейнтекста принципиально нельзя спроектировать так, чтобы подобных проблем не было.

Вы дико невнимательны. «Разделителем колонок будет [может быть] другой символ».

А если это не одно поле, в котором окажется данный разделитель?

А при чем здесь Баш? Эти программы никакого отношения к Башу не имеют.

Он тут при том, что баш без них полностью бесполезен. По факту, когда мы говорим о баше, то подразумеваем и coreutils, как минимум. И то, что баш без этих программ бесполезен, делает проблемы этих программ проблемами баша.

Ага. А это что?

Это простенький враппер вокруг обычной системной функции, которую с тем же успехом можно вызывать и напрямую:

PS C:\> [System.Diagnostics.Process]::GetProcesses() | ? ProcessName -match "chrome"

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id  SI ProcessName                                                                                  
-------  ------    -----      ----- -----   ------     --  -- -----------                                                                                  
   2824      94   269716     157372   755 2 161,16   4724   1 chrome                                                                                       
...

Ну посмейтесь — может быть пройдет и вы перестанете отрицать очевидное, а именно то, что придуман МС ПШ именно под влиянием программирования текстовыми фильтрами типа sort, uniq, grep, wc через конвейер.

И по-этому весь дизайн поша построен вокруг структурированных объектов, то есть обратного плейнтексту подхода? Где тут логика? А конвеер - это уже точно не изобретение баша.

Ну как же не предоставляет? Я же вам выше написал пример, как писать такое именно на Баше, а не цепочкой фильтров.

Баш бы предоставлял альтернативу, если бы было решение как на поше - то есть с одной стороны краткое, с другой стороны простое и поддерживаемое. Но его нет.

Какие еще «преимущества»? Я не знаю, можно ли на МС ПШ писать по-нормальному (алгоритмически) — наверное, можно, но вы-то ваш образцовый пример на МС ПШ написали именно в парадигме «однострочника», то есть выпятили ее недостаток.

Так в том и дело, что «быть однострочником» - это не недостаток, это достоинство. Недостатки - это если код запутан, непонятен, нерасширяем и т.д.., обычно однострочники этими недостатками обладают, и потому плохи (а не потому что они однострочники)

Этими недостатками обладает и однострочник на баше, а вот однострочник на поше - нет. Он проще и понятнее вашего кода, но при этом краток.

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

На дворе мочало — начинай сначала.

Никто не писал getProcess() специально для пош, конечно же.

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

И по-этому весь дизайн поша построен вокруг структурированных объектов, то есть обратного плейнтексту подхода?

Нет, он по другой причине построен вокруг структур.

А конвеер - это уже точно не изобретение баша.

И что? Я где-то утверждал что-то подобное?

Этими недостатками обладает и однострочник на баше, а вот однострочник на поше - нет

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

«Выбор желаемых колонок по названию и сортировка», но не для одного ps(1), а для много большего числа программ, только и всего.

Для ВСЕХ программ.

Ладно, давайте так. Вы мне уже давали задачку, можно теперь я вам дам? Она вполне реальна — это из моих недавних одноразовых скриптов, поэтому написана далеко не самым аккуратным образом:

#!/bin/bash

while read f; do
    [[ $(file --brief --mime-type "$f") == video/* ]] || continue
    i=0
    while IFS='=' read key val; do
	case "$key" in
	    'ID_AUDIO_ID') (( i++ )) ;;
	esac
    done < \
         <(mplayer 2>&- -identify -frames 0 -really-quiet "$f")
    printf '%d %s\n' $i "$f"
done < \
     <(find -type f)

Эта штука выводит количество аудиодорожек (две колонки: количество дорожек и имя файла) для всех файлов ниже по дереву (рекурсивно), что похожи на файлы с видео.

Критически важно, чтоб файл читался по-минимуму — ФС может быть смонтирована весьма удаленно.

Нисколько не сомневаюсь, что написать это на МС ПШ можно, но посмотреть на результат было бы крайне интересно, а узнать, как при этом можно было «не курить маны» — вдвойне.

Сама по себе эта функция просто использует системное API для получения списка процессов и возвращает его в виде массива .NET

пш использует не системные функции, а именно классы .net, которые, в свою очередь работают с соответствующими системными ф-циями.

Когда-то давно я писал скрипт, который обходит виртуалки на esx. Он проверял состояние и откатывал нужные до снэпшота. Так вот этот скрипт, из 10 строчек, на моей машине отжирал ~650mb.

Ну в этом случае да, но системные функции никто не запрещает вызывать через P/Invoke.

Ну если буквально перевести на PowerShell, то будет как-то так:

foreach ($f in Get-ChildItem -file) {
    $mime = & 'file' "--brief --mime-type $f"
    if ( -not $mime -like 'video/*' ) {
        continue
    }
    $data = & 'mplayer' "2>&- -identify -frames 0 -really-quiet $f"
    $i = 0
    foreach ( $kv in ($data -split "`n") ) {
        if ( $kv -like 'ID_AUDIO_ID=*' ) {
            $i++
        }
    }
    echo "$i `"$f`""
}

разумеется, но думаю, что нас ожидает проблема иного рода: https://github.com/PowerShell/PowerShell/pull/1901#issuecomment-240840910

То, что пш появился на самом деле плюс. Еще один инструмент в копилке. А вот то, что он за собой тащит - не хорошо. Когда всякий энтерпрайз и соответствующие платформо-Зависимые архитекторы начнут использовать привычный им подход в работе - будет фигово.

Ну P/Invoke подразумевает платформо-зависимость (Platform Invoke). Но там где нужна кроссплатформенность и без P/Invoke никак - можно сделать разные реализации внутри, проверять платформу и в зависимости от платформы вызывать разные внутренние реализации. Без этой возможности в такой ситуации все было бы еще хуже - пришлось бы писать очередную утилиту на Си, например, даже если все что требуется - вызвать одну системную функцию.

а среда исполнения скриптов тоже портирована?

Ну если буквально перевести на PowerShell, то будет как-то так:

Да нет, ну господь с вами — это же все через ненавистное вами плоское текстовое представление. В структурах я конечно же хотел увидеть.

Кто сказал, что оно «ненавистное»? Просто PowerShell позволяет использовать объектное представление, а не только текстовое, но при этом не лишает ничего при работе с текстовым. При этом еще обладает более адекватным синтаксисом. В ПШ нельзя просто кроссплатформенно получить MIME, поэтому использование GNU file вполне логично, если уж нужно. Можно сделать ПШ модуль реализующий эту функциональность, если нужно часто использовать (не обязательно даже через file, можно реализовать все самому или дергать какую-нибудь библиотечную функцию). Там где запускается mplayer вообще дикая специфика, опять же можно реализовать полностью объектный модуль для работы с такими файлами если нужно. Ну и даже на таком примере, где почти везде приходится прибегать к внешним утилитам можно заметить некоторые преимущества объектного подхода - например, вместо запихивания результата find в read можно просто получить список файлов и пройтись по нему foreach, что куда более читабельно и понятно (кроме того $f является объектом, а не строкой и работать с ним можно как с объектом, хотя тут это не понадобилось), во-вторых единообразный синтаксис для разных переменных, так как есть информация о типах - не нужно использовать арифметический контекст для работы с числом.

Разница тут в том, что все, что можно сделать в других шеллах можно сделать в ПШ так же или лучше, а вот то, что на ПШ делается очень легко в других шеллах может потребовать дрочки текста, а некоторые вещи, которые можно сделать на ПШ вообще принципиально невозможно сделать в других шеллах без написания утилит на других языках.

Ну и если предположить существование этих самых объектных реализаций, то как-то так выглядело бы:

foreach ($f in get-childItem -file) {
    if ( -not (get-MimeType $f) -like 'video/*' ) {
        continue
    }
    $mediaInfo = get-mediaInfo $f
    $i = ($mediaInfo.tracks | ? type -eq audio | measure).count
    echo "$i `"$f`""
}

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

А вот это - прямая ложь. Именно для баша (точнее - в общем для дерганья из шелла) их и писали.

Нет, он по другой причине построен вокруг структур.

Тогда каким образом конвеер мог быть сделан по образу и подобию конвеера баша, если он работает принципиально по-другому?

Другие указанные вами недостатки: запутанность и непонятность, как раз цепочке фильтров-то не свойственны.

Варианту с авк/греп/сорт свойственны, т.к. непонятно откуда брать колонки.

почему цепочка фильтров на МС ПШ не обладает недостатком «однострочника» — а именно плохой расширяемостью.

Ну попробуй представить кейс, в котором оно плохо расширяется.

пш использует не системные функции, а именно классы .net

Методы классов .net в современной винде - это и есть системные функции.

Эта штука выводит количество аудиодорожек (две колонки: количество дорожек и имя файла) для всех файлов ниже по дереву (рекурсивно), что похожи на файлы с видео.
Критически важно, чтоб файл читался по-минимуму — ФС может быть смонтирована весьма удаленно.

Если задача формулируется как «читать куски файла», то ее иначе и не решить, кроме как читая куски файла, очевидно. Если же хочется работать с объектами - можно взять любую библиотеку для работы с метаданными под .net

Не спорь! Опенсорсные командлайны, придуманные студаками без года опыта работы - это лучшее средство для управления промышленным софтом!

у них как раз хватило ума этого не делать не надо путать фреймворк и ос

снова не правы трудно называть ровесников кернигана и рачи студентами почитайте про те же gnu utils

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

Каким образом ты догадаешься, что тебе надо вырезать именно нную колонку

Посмотрю выхлоп. Человеческие мозги всё ещё достаточно хороши для таких случаев.

Как мне потом, читая этот код, догадаться

Правильный вопрос «Зачем тебе потом догадываться?»! «Потом» у тебя будет другая задача, и ты опять посмотришь и напишешь новую команду, потому, что это одноразовые случаи, и дешевлее наваять новое, чем вспоминать где лежит и что означает старое. Помнишь, я говорил не об средствах разработки программ, а о конечнопользовательской среде? Да, умный конечный пользователь заметит, если «вот это приходится делать часто», и напишет/закажет для этого отдельную программу на настоящих языках настоящего программирования, с документацией, шахматами и поэтессами, и забудет об этой задаче - теперь она решается роботами, а на его мозг хватает того, с чем мозги справляются лучше - нерегулярные одноразовые экспромты.

Аналог грепа - это слс

Good for you. А аналого всего остального мусора, который мне захочется засунуть между ||?

это будет невнятная write-only портянка

Разумеется. Это же главный юзкейс *Ш. Я подразумеваю, что человек достаточно разумны, чтобы отличить случаи, в которых «правильное» программирование эффективнее одноразовых костылей и наоборот.

результат пса, выбрав процессы с приоритетом больше 7, а потом посчитай средний workingset для топ-5 процессов с максимальным workingset

Сделал, для примера:

ps axo pri,rss | sort -n | less

Восстанавливать структуру данных надо в случае плейнтекста

Зачем? Человек и так справится, если данных немного или формат «нормальный»(сериализация «фильруема»). И то и другое - негарантировано, и тогда может оказаться, что ПС не сильно хуже. Но! это подразумевает изрядную степень безумия авторов. Будь уверен, структурированные данные безумного автора не сладко разгребать хоть в ПШ, хоть в чём угодно. Да, мне не повезло с объектом исследования для знакомства с ПШ :)

шелл кроме поша назвать, который работает со структурированными данными

Ну сколько можно! Говорю же, пользовательский шелл - плохое место для структурированных данных! Ибо человек! Есть всякие «REPL"ы у всяких „настоящих“ языков со структурированными данными и прямым доступом к кишкам - но это не „пользовательский“ шел, Думаете, потому что заговор разработчиков языков программирования? Нет, это объективная реальность - пользователю не нужны сложные структуры данных, он их хочет воспринимать в виде простого короткого текста, т.к. на другое у него разъём не вырос. Заставлять его вспоминать, какая структура привела к появлению на экране цифры „5“ - непродуктивно, если он может её обработать просто как цифру „5“.

А аналого всего остального мусора, который мне захочется засунуть между ||?

Какого именно?

Зачем?

Как зачем? Автокомплита нет, имена и номера колонок, а также формат вывода неизвестен. И написать скрипт до тех пор, пока эта информация неизвестна - невозможно.

ответ: 0.

Ну выставь другой приоритет, значит. Я не, знаю какой диапазон в линуксе.

И то и другое - негарантировано, и тогда может оказаться, что ПС не сильно хуже.

Ты хотел сказать, не сильно лучше? Потому что пример, в котором пс был бы не лучше пока что не придумывается. А вот примеры, в которых решение на пс выигрывает... да что угодно бери. Вот хоть тот же ps | ? { $_.ProcessName -match patt}

Ну сколько можно! Говорю же, пользовательский шелл - плохое место для структурированных данных!

Да говори сколько хочешь, от многократного повторения ложное утверждение не становится истинным.

Заставлять его вспоминать, какая структура привела к появлению на экране цифры „5“ - непродуктивно, если он может её обработать просто как цифру „5“.

Так ему и не надо ничего помнить - и в этом как раз и есть основное преимущество явно структурированных данных над плейн текстом (в случае с плейнтекстом - структуру данных помнить надо). Структура у данных есть в любом случае, по факту. Если у тебя на выходе таблица - это структурированные данные. Даже если таблица представлена плейнтекстом - все равно мы имеем массив записей определенной структуры. Разница явной структурированности и неявной в том, что при наличии явной структуры ее знать не нужно, т.к. _она заложена в данных_ и работает сама по себе, без вмешательства пользователя. Пользователь о ней не в курсе. А вот когда явной структуры на уровне данных нет - пользователь должен ее _восстанавливать_, в данных она не содержится и во время работы пользователь должен ее к этим данным добавить. Анализировать выхлоп, выбирая номера и названия колонок, фильтруя эти колонки,обходя питфоллсы с особенностями форматирования и т.д. - вот это вот все.

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

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

Посмотрю выхлоп.

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

Правильный вопрос «Зачем тебе потом догадываться?»!

Потому что скрипты пишутся не только в терминале.

Вот только VS Code совсем не ня

В сторону IDE Rider смотрел?

У Микрософта агония, они уже не знают чем заняться и куда податься.

Мне плюсцы нужны. На MS Windows лучшее C++ IDE это штудия.

Может кто заодно подскажет?

В подкаталогах некоторой текущей директории лежали 7z-архивы, перепаковывал их zip-архивы с такими же именами, сохраняя структуру каталогов. Рабочие варианты скриптов написал, но осталось пара вопросов по поводу PowerShell. Сразу оговорюсь, ни bash, ни cmd, ни ps (использовалась версия 2.0) я не знаю, так что уж что получилось.

bash-скрипт:

#~/bin/bash

# redefining of IFS to ignore a " "("space") as delimiter during "DIR"-variable assignment
IFS_init=$IFS
IFS=$'\n'
# file extenstion for zip compression
EXT=dat
for DIR in $(find . -mindepth 1 -maxdepth 1 -type d -printf '%f\n'); do  
    for ARCH in $DIR/*.7z; do 
        7z e -o"./outdir/$DIR/" "$ARCH" \
        && cd "./outdir/$DIR/" \
        && zip "$(basename $ARCH .7z)".zip -m *.$EXT \
        && cd "../../"
    done
done
IFS=$IFS_init

то же самое для bat-файла:

@echo off
rem path to 7z.exe:
set path7z="C:\Program Files\7-Zip\7z.exe"
rem file extension for zip comression:
set ext=dat
for /D %%A in (*) do (
        for %%B in ("%%~A\*.7z") do (
            %path7z% e -o".\outdir\%%~A\" "%%B" ^
            && cd ".\outdir\%%~A\" ^
            && zip "%%~nB".zip -m "*.%ext%" ^
            && cd ..\..\
            )
        )

то же самое для PowerShell (2.0):

# path to 7z.exe:
$path7z="C:\Program Files\7-Zip\7z.exe";
# file extension for zip comression:
$ext="dat";
foreach ($diritem in ls .\ | ? {$_.mode -match "d"}) {
        foreach ($arch in ls .\$diritem\*.7z) {
                # здесь параметр командной строки и его описание должен быть в кавычках:
                &$path7z e "-o.\outdir\$diritem\" $arch; 
                cd .\outdir\$diritem\; 
                # приходится заводить новую переменную, чтобы сработала следующая строчка:
                $archname=$arch.basename;     
                # здесь приходится заключать ".zip" в кавычки:
                zip $archname".zip" -m *.$ext;
                cd ..\..\
                }
        }

Собственно вопрос относительно 2 моих последних русскоязычных комментарием самому себе в PS-скрипте:

1. Как обойтись без создания дополнительной переменной $archname=$arch.basename, потому что следующая строка с записью $arch.basename".zip" вместо указанной не сработает.

2. Почему в команде создания zip-архива понадобилось писать $archname".zip", то есть заключать в кавычки расширение архива ".zip",а не переменную «$archname», чтобы подставить её значение, чтобы было "$archname".zip? Так получилось методом множественного тыка, иначе некоторые zip-архивы в лучшем случае упаковывались, но имена получившихся файлов были без расширения ".zip" на конце.

Вот еще немного по теме: «Автор сurl просит Microsoft удалить алиасы curl и wget из PowerShell, так как это мешает запустить нормальные привычные программы.»

Могу подсказать, как упростить bash-версию. Если не вдаваться в крайние случаи (впрочем, исправляется с помощью shopt -s nullglob dotglob), то всю эту белиберду с find можно переписать как

for DIR in */; do
    ...
done

1. Как обойтись без создания дополнительной переменной $archname=$arch.basename, потому что следующая строка с записью $arch.basename".zip" вместо указанной не сработает.

Замени на «$($arch.basename).zip» или ($arch.basename+".zip")

1. Чтобы подставить в строку произвольное выражение - $(expression), например «$($arch.baseName)» 2. Потому что PowerShell объектный, а не текстовый шелл и написав "".zip ты пытаешься обратиться к св-ву Zip строкового объекта (которого там есс-но нет)

Ну и в дополнение - начиная с 3.0 не нужно проверять аттрибуты для выбора только файлов или директорий, достаточно добавить параметр -File/-Directory