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

Первый раз запускается долго (как прогрев виртуальной машины выглядит). Второй раз - меньше секунды.

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

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

ой да ладно, все понимают что это наброс на вентилятор, а не реальная проблема. В виндовой ПШ на curl всем пофиг (а кому не пофиг, тот пишет «curl.exe» или тупо удаляет алиас), а в линуксовой таких алиасов просто нет.

for DIR in */; do

Так не сработало, а так

for DIR in /*; do

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

for DIR in *; do

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

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

Чтобы подставить в строку произвольное выражение - $(expression), например «$($arch.baseName)»

Спасибо, попробую. О том, что после точки вызывается свойство знал, но где-то находил, что если запихнуть саму переменную в кавычки (решил, что и с переменной со свойством прокатит), то подставится значение.

достаточно добавить параметр -File/-Directory

Спасибо. Недавно как раз на это наткнулся. И в PS 2.0 действительно этого не хватало, поэтому с сверялся с атрибутами.

Может быть диск на 5600 оборотов так работает. Некоторые папки (например, загрузки) долго открываются.

У тебя какой-то поломанный bash!

Так не сработало

А у меня всё работает, и это вообще известная идиома.

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

Это вообще «все файлы из корневого каталога».

bash обычный, гентушный, в виртуалбоксе.

Честно проверил, один из результатов удивил, но проверил несколько раз - поведение не поменялось.

Сейчас нашёл, что у меня были лишние слэши: в двух местах должно быть ./outdir/$DIR вместо ./outdir/$DIR/ , после исправления этого если оставить «*/», то в выводе в терминал будет лишний слэш висеть между названием директории и именем файла, что на работоспособность не влияет. Можно подправить это, заменив for ARCH in $DIR/*.7z; do на for ARCH in $DIR*.7z; do, так как переменная $DIR уже содержит в конце слэш.

Спасибо за подсказку, так действительно короче. Даже короче, чем «ls -d */», который аналогичен, но меня почему-то смущал слэш к конце и хотелось вывод без лишних символов, а зря :)

jq не предназначен для работы со структурированными данными, он позволяет только делать запросы к жсону, и это _все_

А что JSON это не структурированные данные? Ты дебил?

А что JSON это не структурированные данные?

Таблицы - это тоже структурированные данные. Что дальше? Еще раз - кроме выборок (и то костыльным способом) оно не позволяет ничего делать.

Потому что скрипты пишутся

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

Структура у данных есть в любом случае

Её необязательно восстанавливать. И давай не будем повторять те же аргументы ещё раз.

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

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

Её необязательно восстанавливать.

Ну и попробуй найти, допустим, все хромовские процессы, не восстанавливая структуру данных, которые тебе выплевывает ps. В поше это возможно (т.к. данные структурировали за тебя, можно забыть про то, что структура есть и спокойно писать команду в терминал), а в баше как?

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

Вот об этом же и речь. Отнесись к этой фразе, как к задачке на сообразительность, и поймёшь(если осилишь).

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

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

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

Конечно же лучше, по двум параметрам:

1. он _намного_ быстрее и проще

2. он гарантирует тебя от ошибок

Откуда выигрыш во времени?

Оттуда, что информации для анализа на порядок меньше. Для анализа выхлопа надо:

1. Сперва этот выхлоп получить (уже здесь времени потрачено столько, сколько требуется на выбор поля в автокомплите, все остальное, что идет дальше - идет в минус)

2. Выхлоп промотать наверх

3. Найти глазами нужную колонку

3. а. если колонки нет - идти и курить мануалы

4. прочитать и запомнить название колонки

5. ввести это название

6. убедиться в правильности ввода (нет опечаток и т.п.)

Все это занимает более 10 секунд в лучшем случае. В поше весь флоу в общемз анимает секунду, максимум 2. Выигрыш времени - в разы.

И немалая латентность работы мозга умножается на кол-во точек-минусов.

Это ты про что вообще?

Вот об этом же и речь. Отнесись к этой фразе, как к задачке на сообразительность, и поймёшь(если осилишь).

Не вижу смысла решать задачи, которые неразрешимы по своему построению (восстановить структуру данных, не восстанавливая структуру данных? лихо).

Откуда вывод о меньшем удобстве при работе в терминале? Длинные команды? Get-Alias/Set-Alias (а так же alias:/), прописываешь в окружение как тебе удобно. Можешь хоть однобуквенными сделать часто используемые команды. Не нравится CamelCase? Пиши строчными, он не регистро-чувствительный. Боишься, что вызывать классические утилиты сложнее? Точно так же, если команда - однозначно исполняемый файл, то все объекты в строке преобразуются в текст. Боишься что объектный вывод не читабелен? Так в ПШ заданы читабельные форматы для большинства нужных .NET объектов, причем их можно настраивать (Get-Help about_Format) и задавать формат для своих объектов. Не нравятся длинные имена параметров? Их можно сокращать (до тех пор пока сокращение однозначно, например, -InputObject до -in) и для них так же обычно заданы короткие алиасы. Кроме того объектный шелл дает возможность делать универсальную подстановку для параметров команд.

Так в чем конкретно он проигрывает традиционным текстовым шеллам?

Не вижу смысла решать задачи, которые неразрешимы

«Вы меня удивляете, сударь! Какой же смысл решать задачи, которые заведомо имеют решение?»(копирайт не мой). Вопрос был «в каких условиях это имеет смысл?» (не восстанавливать...).

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

Что, прости? Так ты расскажешь как отфильтровать процессы, возвращаемые пс, не зная формата выхлопа пс?

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

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

Не было такого вывода. Вывод был о меньшем удобстве для задач обычного пользователя шела. И не ПШела, а именно структурированных типизированных данных. И не вообще, а для вот этого конкретного случая - пользователя, которому «мышкой тыкать» недостаточно, а полноценно «программы писать» - слишком много.

Проигрывает тем, что этому пользователю не нужны «объекты» вообще. Ему нужны имена объектов(чтобы передавать их туда-сюда) и редкие аттрибуты объектов(чтобы их анализировать). Скажем, в объекте «процесс» больше аттрибутов/методов, чем я за всю свою жизнь вообще запрашивал у всех объектов своей системы вместе взятых за всю свою жизнь. Что ты выиграл от рассматривания нев^Hцензурного количества никода не нужной информации в твоём автокомплите?

Это ты про что вообще?

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

Автокомплит помогает в 2х случаях - опечатки и автоматизация ввода длинных известных заранее названий. Первое - полезно, но есть далеко не только в ПШ и мало полезно в случае коротких команд(как исправлять опечатки в слове «w»?), второе - не даёт преимуществ при коротких командах (слово «ps» нет смысла автодополнять). Есть вымышленное преимущество в простоте использоавния новичками. Я был в этой позе(:и, вероятно, ещё буду:), ничего оно не помогает, правильная команда не ищется ни в автодополнении (что ожидаемо, вопрос=половина ответа) ни в документации (что странно, МС могли бы гуглёбельный мануал выложить).

Ну давай посмотрим.

PS C:\Users\Demo> ps | ? __NounName
__NounName                  Id                          PagedSystemMemorySize       PSConfiguration
BaseAddress                 InternalName                PagedSystemMemorySize64     PSResources
BasePriority                IsDebug                     Path                        PSStandardMembers
Comments                    IsPatched                   PeakPagedMemorySize         Responding
Company                     IsPreRelease                PeakPagedMemorySize64       SafeHandle
CompanyName                 IsPrivateBuild              PeakVirtualMemorySize       SessionId
Container                   IsSpecialBuild              PeakVirtualMemorySize64     SI
CPU                         Language                    PeakWorkingSet              Site
Description                 LegalCopyright              PeakWorkingSet64            Size
EnableRaisingEvents         LegalTrademarks             PM                          SpecialBuild
EntryPointAddress           MachineName                 PriorityBoostEnabled        StandardError
ExitCode                    MainModule                  PriorityClass               StandardInput
ExitTime                    MainWindowHandle            PrivateBuild                StandardOutput
FileBuildPart               MainWindowTitle             PrivateMemorySize           StartInfo
FileDescription             MaxWorkingSet               PrivateMemorySize64         StartTime
FileMajorPart               MinWorkingSet               PrivilegedProcessorTime     SynchronizingObject
FileMinorPart               ModuleMemorySize            ProcessName                 Threads
FileName                    ModuleName                  ProcessorAffinity           TotalProcessorTime
FilePrivatePart             Modules                     Product                     UserProcessorTime
FileVersion                 Name                        ProductBuildPart            VirtualMemorySize
FileVersionInfo             NonpagedSystemMemorySize    ProductMajorPart            VirtualMemorySize64
FileVersionRaw              NonpagedSystemMemorySize64  ProductMinorPart            VM
Handle                      NPM                         ProductName                 WorkingSet
HandleCount                 OriginalFilename            ProductPrivatePart          WorkingSet64
Handles                     PagedMemorySize             ProductVersion              WS
HasExited                   PagedMemorySize64           ProductVersionRaw

PS C:\Users\Demo> ps

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
-------  ------    -----      -----     ------     --  -- -----------
    372      21    28096      17888   2 631,72   7836   1 Agent
    556      27    23916      27604       6,22    852   1 ApplicationFrameHost
    129       9     6260      10748       0,08   3716   0 audiodg

факт, что это объект дает куда больше удобства тогда, когда на этот список нужно не просто посмотреть

А зачем ты повторяешь мне то, что я тут с первого поста утверждаю?

Еще раз - кроме выборок (и то костыльным способом) оно не позволяет ничего делать.

А что ещё тебе надо, хороняка? По-моему, ты просто жидко обосрался и не знаешь как оправдаться, твой ПШ тоже не умеет ничего «кроме выборок (и то костыльным способом)».

Давай упростим

Не, давай к реальному миру. Интересный для обоснования полезности автокомплита и т.п. случай смогу рассказать только в черверг, памяти не хватает. Пока простой: дано-кластер, на котором гоняется приложение из 30 чёрных ящиков, иногда отдающее трафик другому, ещё более чёрному ящику на таком же кластере. Трафик приходит через фильтрующий проксятник в 20 разных форматах, частично хмл, частично формочки. + много мусора(интернет). Большинство полей называются непонятно и содержат base64 блобы. Трафик поставляют 40к «партнёров», некоторые со своих серверов, некоторые перенаправляя клиенсткие бровзеры. На некоторые запросы задний ящик перенаправляет клиента на внешний сервер, и ждёт от того возврата ещё с одним блобом для завершения операции. Иногда, скажем в одном десяти тысяч случаев, задний яящик не получает свой блоб. Нужно найти причину и список жертв.

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

Хочу услышать, насколько в этой ситуации мне поможет автокомплит и структурированные данные(допустим, оно всё в красивом евентлоге).

Проигрывает тем, что этому пользователю не нужны «объекты» вообще. Ему нужны имена объектов(чтобы передавать их туда-сюда) и редкие аттрибуты объектов(чтобы их анализировать).

То есть все то, что предоставляет пош и не предоставляет баш.

Что ты выиграл от рассматривания нев^Hцензурного количества никода не нужной информации в твоём автокомплите?

Зачем мне ее рассматривать? О чем ты вообще?

Давеча по ящику рассказывали о том, что мозгу нужно секунды 2, чтобы принять решение в неизвестной заранее ситуации. Ты нажимаешь кнопку, автокомплит тебе что-то подсказывает, ты принимаешь решение, тот ли это метод(время ушло).

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

А что ещё тебе надо, хороняка?

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

Не, давай к реальному миру. Интересный для обоснования полезности автокомплита и т.п. случай смогу рассказать только в черверг, памяти не хватает. Пока простой: дано-кластер, на котором гоняется приложение из 30 чёрных ящиков, иногда отдающее трафик другому, ещё более чёрному ящику на таком же кластере.

Ты вроде чтото кукарекал про «нужно только пользователю для команд в шелле»?

Хочу услышать, насколько в этой ситуации мне поможет автокомплит и структурированные данные(допустим, оно всё в красивом евентлоге).

Помочь чему? Ты не описал задачу. Ну и главная прелесть структурированного подхода - даже когда он не помогает (что бывает редко, конечно), он гарантированно не делает хуже. То есть даже в тех случаях когда объекты не нужны, задача будет решена _как минимум так же удобно__ как в баше.

А тепер ьвсе-таки объясни как ты собрался работать с выхлопом, формат которого тебе неизвестен.

Нужно найти причину и список жертв.
Хочу услышать, насколько в этой ситуации мне поможет автокомплит и структурированные данные(допустим, оно всё в красивом евентлоге).

Пишем Get-EventLog (команда которая выдает нам структурированные логи) -LogName (подсказано автокомплитом) Application (выбрали нужный лог из автокомплита) | ? {$_.EntryType (выбрали с автокомплита) -like 'Error'} | select {$_.Message (автокомплит), $_.Source (автокомплит}

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

И ни одного мануала не пришлось читать.

Надо уметь преобразовывать данные к структурированной форме

jq умеет, еще что придумаешь?

-LogName подсказано автокомплитом Application

Автокомплит выдал тебе пару десятков аббревиатур от «нужных» компонентов, и нещё неизвестное количество «ненужных»(операционка там, и всё подобное). Как ты догадаешься, что нужно выбрать один из нескольких online-xyz?

EntryType (выбрали с автокомплита) -like 'Error'}

От «правильного» приложения получил несколько десятков интересных тебе «таймаутов» от последнего ящика, не содержащий намёка на причины. Если повезло угадать application - несколько сотен ошибок самого разного рода, иногда со стектрейсами. Обнаружил, что вчера было внешнее сканирование, т.ч. интересные нам сообщения сильно разбавлены точно так же выглядящими неуклюжими попытками нессусов. Если не повезло - получил список событий никак не связанный с проблемой(к примеру, в проксятнике «интересные» события числятся как «200 OK» - т.е. ошибки просто нет).

Message (автокомплит), $_.Source

Получил список названий ява-классов с номерами строк, идентификаторов нитей, или, если сильно повезло, динамических адресов домашних пользователей в перемешку с твоими внутренними.

Ты пока нигде.

Но тебе не нужно было искать причину пробемы, тебе нужно оценить выигрыш от структурированности данных. Очевидно, он есть там, где тебе не нужно писать парсеры входного мусора, и твой скрипт выдал бы сразу правильный ответ. Он не выдал. Ты можешь быстро написать ещё пару десятков таких же скриптов, но, поскольку ты не знаешь, что искать(как отличить «интересное» сообщения от «неинтерсного»), получишь столько же пользы.

Ты можешь автоматизировать только то, что знаешь, как сделать руками, а ты сейчас не знаешь. В моём случае ответ был не в сообщении об ошибке, а в успешной операции минут за несколько ранее. Успешные операции деталей в логи не пишут, и очевидного способа связать их с ошибкой не обнаружилось, т.ч. пришлось убить несколько часов. Парсер входных данных, в результате, занимал аж cat | grep | 3 строки sed-a(каждая сильно короче того, что ты привык писать в ПШ, но + немного копипейста) и 4 питона(стандартные заклинания). Т.ч. выигрыш ограничен сверху вот этими строками и, думается мне, питон отыграл мне несколько строк на остальном коде, т.ч. нижний предел не понятен даже без учёта выгоды от применения мозга на поиске аномалий в 2мерном тексте vs. psh «пойди-туда { $_.не знаю куда} | принеси-то { $_.не знаю что }». Даже если я очень часто делаю ошибки в «line.split()», «strptime()» и «int()», потолок обсуждаемого выигрыша составил какой-то 1-2% времени, из которого основная масса - смотреть, придумывать и дебажить отнюдь не парсер.

Ты не описал задачу

Оценить выигрыш от испольования структурированных данных в пш.

нужно только пользователю для команд в шелле

Ну да. «Обычные пользователи» до этого уже истыкали все доступные кнопки.

как ты собрался работать с выхлопом, формат которого тебе неизвестен

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

он гарантированно не делает хуже

Структурированную информацию можно задампить в удобный для «этого» вид. Проблема в том, что при этом либо потеряется информация о структуре(и нужно будет угадывать, как называется аттрибут, нарисовавший 5), либо информация о структуре забъёт собой полезный пользователю текст (см. большинство xml-конфигов и логов). То же в обратную сторону - добывать из человека структуру в xml-виде негуманно, а в гуманном - нужно парсеры писать. Вот преимущество и рассеялось.

без автокомплита этот шаг тоже есть, но кроме него есть еще много другинх шагов

Конечно есть. Итераций меньше. «grep -r запрос /etc» выдаст мне всё из всех плохоструктурированных объектов, что хоть как-то похоже на запрос, и я точно буду знать как добраться до того из них, который мне понравился.

В хорошоструктурированных я должен либо угадать тип объекта, чтобы потом просматривать автокомплитом, либо название аттрибута, чтобы написать условие для сравнения, либо написать цикл по всем аттрибутам (вероятно такой есть встроенный, но автокомплит не поможет мне его найти), либо задампить всё в строки для подсказанного тут sls, и потом угадывать, какие слова нужно писать, чтобы добраться до того, который оказался нужным (или вывести эту инфу рядом с найденым, и забить пользовательский видеовход метаданными). Сам этот выбор уже может заставить человека думать об инструменте, вместо задачи.

Бесплатного сыра не бывает.

например (образно)

def whois(domain)
    return `whois #{domain} | grep -v '^$' | grep -v '^%'`
end

Загрузив его в мозги

То есть, проанализировать выхлоп и разобрать формат. Зачем делать это своими мозгами (которые, кстати, очень неэффективно справляются с подобными задачами), если машина сможет решить указанную задачу быстро и надежно?

Структурированную информацию можно задампить в удобный для «этого» вид. Проблема в том, что при этом либо потеряется информация о структуре(и нужно будет угадывать, как называется аттрибут, нарисовавший 5), либо информация о структуре забъёт собой полезный пользователю текст (см. большинство xml-конфигов и логов).

Не понял, как тут баш выигрывает у павершелла. Вот тулзы из coreutils дампят структурированную информацию в удобный для польователя вид, при этом информация о структуре теряется (тот же ps который выводит по дефолту лишь несколько из сотни доступных колонок). В павершеле же и структура не теряется и информация текст пользователя не забивает, т.к. ты выбираешь нужные поля автокомплитом.

а в гуманном - нужно парсеры

Они уже написаны. В том и дело.

jq умеет,

Давай линк. Тот jq, что я нашел (https://stedolan.github.io/jq/) не умеет.

Автокомплит выдал тебе пару десятков аббревиатур от «нужных» компонентов, и нещё неизвестное количество «ненужных»(операционка там, и всё подобное). Как ты догадаешься, что нужно выбрать один из нескольких online-xyz?

Я понял твою проблему. Ты так привык к костыльному линуксвею, что просто не понимаешь, как шелл должен работать нормально. Смотри, в чем дело, - вместо линуксовых названий вроде hurdd-durrABC, смысл которых нельзя определить без чтения документации, в поше названия выбираются длинные и говорящие. Очень редко бывает такая ситуация, при которой по названию нельзя полностью и вполне точно понять, какая сущность этим названием именуется. Верно и обратное - если тебе нужна какая-то сущность, то ты просто начинаешь писать ее имя, например, если тебе нужны свойства процесса, связанные с памятью, то ты пишешь $_.mem - и дальше в автокомплите выдается список полей, содержащих 'mem' (штук десять, а не все сто). И ты выбираешь нужное из уже всего лишь десятка, что тривиально и бытро.

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

И при чем тут шелл?

Получил список названий ява-классов с номерами строк, идентификаторов нитей, или, если сильно повезло, динамических адресов домашних пользователей в перемешку с твоими внутренними.

Аналогично. Шелл то тут при чем?

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

Ты уходишь от главного аргумента - важно, что, в первую очередь, структурированность данных НИКОГДА не приводит в проигрышу. А в некоторых случаях - приводит к выигрышу. Чем сложнее задача - тем больше выигрыш. Вот и все.

Ты можешь автоматизировать только то, что знаешь, как сделать руками, а ты сейчас не знаешь. В моём случае ответ был не в сообщении об ошибке, а в успешной операции минут за несколько ранее. Успешные операции деталей в логи не пишут, и очевидного способа связать их с ошибкой не обнаружилось, т.ч. пришлось убить несколько часов. Парсер входных данных, в результате, занимал аж cat | grep | 3 строки sed-a(каждая сильно короче того, что ты привык писать в ПШ, но + немного копипейста) и 4 питона(стандартные заклинания). Т.ч. выигрыш ограничен сверху вот этими строками и, думается мне, питон отыграл мне несколько строк на остальном коде, т.ч. нижний предел не понятен даже без учёта выгоды от применения мозга на поиске аномалий в 2мерном тексте vs. psh «пойди-туда { $_.не знаю куда} | принеси-то { $_.не знаю что }». Даже если я очень часто делаю ошибки в «line.split()», «strptime()» и «int()», потолок обсуждаемого выигрыша составил какой-то 1-2% времени, из которого основная масса - смотреть, придумывать и дебажить отнюдь не парсер.

Зачем так много писанины? Мог и проще сказать: если при решении задачи 99% труда тратится не на работу с шеллом, и 1% усилий - на работу с шеллом, то, очевидно, никакой шелл не даст выигрыша больше 1% (даже если магическим образом сведет часть работы с шеллом к нулю). ДА, если в задаче шелл не нужен и не используется - то более продуманный шелл не дает выигрыша. С этим никто не спорил.

Конечно есть. Итераций меньше.

С чего бы их было меньше? Каждую колонку надо искать и запоминать отдельно.

«grep -r запрос /etc» выдаст мне всё из всех плохоструктурированных объектов, что хоть как-то похоже на запрос

Выдаст только в том случае, если ты _заранее_ узнал структуру объектов и задал правильный запрос (построенный на основе знаний этой структуры). Запрос же в поше знания структуры объектов не требует. Напиши мне, пожалуйста, grep для выхлопа ps, который вернет все процессы с «22» в названии.

В хорошоструктурированных я должен либо угадать тип объекта

Зачем? Зачем тебе вообще знать что-то о типе объекта или о структуре данных?

чтобы потом просматривать автокомплитом,

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

Бесплатного сыра не бывает.

Конечно, не бывает. Что-то не берется из ниоткуда - в данном случае праздник оплачен трудом программистов микрософт, чей труд в свою очередь оплачен пользователями винды.

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

Что ты несешь вообще?

либо задампить всё в строки для подсказанного тут sls, и потом угадывать, какие слова нужно писать, чтобы добраться до того, который оказался нужным (или вывести эту инфу рядом с найденым, и забить пользовательский видеовход метаданными)

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

Только если в баше у тебя альтернаитв нет - только «задампить всё в строки для подсказанного тут sls, и потом угадывать, какие слова нужно писать, чтобы добраться до того, который оказался нужным (или вывести эту инфу рядом с найденым, и забить пользовательский видеовход метаданными)», то в поше в 99% случаев ты просто напечатаешь два-три символа и выберешь нужное поле из нескольких оставшихся в автокомплите.

Тот jq, что я нашел (https://stedolan.github.io/jq/) не умеет.

Просто ты не умеешь читать. Видимо ПШ так на мозг влияет, да? Вот тебе пример http://unix.stackexchange.com/questions/243484/how-do-i-convert-the-output-of...

Но вообще забавно, что ты не протестуешь против jq в принципе. Т.е. если вместо jq я использую перл или питон - это тоже ok?

Не «разобрать формат», а понять, что именно [не]стоит разбирать. Говорят, компы так долго проигрывали людям в шахматы потому, что пытались анализировать все варианты там, где человеку что-то изнутри подсказывало, какие варианты не стоит рассматривать вообще. В роботов такое пока не встроили. Решить, что на этой странице нет ничего интересного ты можешь и без чтения и понимания каждой буквы, и будешь прав в 90%.

как тут баш выигрывает у павершелла

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

Простой критерий. Мера шельности - насколько решение клиентской задачи в измеряемом шеле выглядит проще и красивше хотя бы питонского аналога. В рекламных примерах ПШ очень хорош. 2 из 3х «реальных» и довольно тривиальных задач, возникавшие «тут и сейчас», почему-то изрядно испортили впечатление(3ю не успел увидеть до уничтожения). Может клиенты ещё не научились правильно пошлить?

# ps | jq -sR '[sub(«\n$»;"") | splits(«\n») | sub(«^ +»;"") | [splits(" +")]]'

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

Т.е. если вместо jq я использую перл или питон - это тоже ok?

Конечно, например:

https://pythonhosted.org/psutil/#psutil.Process

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

Не «разобрать формат», а понять, что именно [не]стоит разбирать.

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

Тут - никак. баш вообще, вероятно, у пш не выигрывает.

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

Тогда, я полагаю, можно остановиться на следующем:

1. пош ~= баш на на элементарных однострочниках (кто выиграет в конкретной такой элементарной задачи скорее зависит от того, как реализована конкретная ф-я, которая будет дергаться, и с которой работаем, а не от шелла)

2. в случае более сложных задач пош выигрывает

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

Может клиенты ещё не научились правильно пошлить?

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

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

Я же не решал проблемы ПШа. Я пытался решить проблемы с левыми программами других авторов, используя в т.ч. ПШ для уменьшения нагрузки на мозг. У авторов этих программ своё представление о том, что как и где хранится. В одном случае это было со структурой, ПШем, автокомплитом, гуглом и документацией; нужно было просто вытащить из системы какие-то данные. То, что должно было решиться как-то типа «a|b|c». Воображение писателей этой программы сделало задачу труднее второй - упомянутой каши в выхлопе чёрных ящиков без шансов на структуру данных и подсказки. Вывод пока такой: реальные преимущества - на уровне погрешности измерений и эстетики.

У авторов этих программ своё представление о том

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

Смысл автокомплита как раз в том что тебе ничгео не ндао, чтобы что-то просматривать

Можем продолжить завтра, когда до примера доберусь. Если не забуду.

будешь пользоваться тем же, чем и в баше, с такой же скоростью

Почти. В мойм случае я знаю, что исправить значение можно, написав «vi скопировать-имя-файла». Что куда нужно скопировать в ПШ?

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

Да. И что он с этим сделает?

в случае более сложных задач пош выигрывает

Поправка: в случае чуть более сложных скриптов выигрывает у баша. Если говорить про «задачи вообще» - начинают вмешиваться вопросы поиска данных, которые слишком хорошо прячутся внутрь структурированных объектов. Представим, что в юниксе все данные хранятся в посвоему закодированных блобах и у каждого своя программа для добычи оных (кто сказал «man journald»?!). До того мне достаточно было помнить cat - оно открывало почти все «объекты» + и 3 аналога для пожатых файлов. Сколько вариантов выдаёт ПШ при автокомплите слова get-?

Что куда нужно скопировать в ПШ?

Ну ставишь тот же ви и так же копируешь.

Говнотулза что на линуксе, что на винде будет говнотулзой, с которой будет трудно работать

Вот. Не столь важно, передаёшь ли ты данные потоком байтов или объектов, важно есть ли в этом потоке нужные данные, не слишком ли много мусора, и легко ли отличить одно от другого. Сам факт «ужеразобранности» экономит небольшую и самую простую часть работы.