использование && и || при готовом true или false
 

Такс, кто мне объяснит за пошик у меня мозг слегка подвисать начал от того во что я уперся:
есть такой фрагмент на баше
и тут всё понятно, отдаем true или false и в зависимости от принятого выводим ОК или KO. пробуем сделать аналогично в пошике:
с этим всё путём, так и ожидалось. а теперь
втф? начал глубже копаться, добавил в вывод $? дык оказывается $? возвращает true и при $true, и при $false
у кого есть сцыль на то чтобы почитать что-то про это дело? ну или своими словами можно, я не привередливый.

фрагменты, разумеется, до крайности упрощенные, на самом деле там многоэтажная конструкция (или многопайповая?) результатом которой является либо "true" либо "false", но не в виде "$?", а просто сами по себе. разумеется я это всё дело заменил if, но как и зачем оно так работает таки интересно.

upd: about_pipeline_chain_operators
Если кратко и по сути: есть то что мы передаем, а есть то что пошик читает. в данном случае мы передаем конкретное значение $true или $false, а пошик смотрит исключительно в $?
и на его взгляд вывод значения переменной $false как и $true вполне даже прошел успешно (т.е. вернул в $? - true) на основе чего и строятся условия этих pipeline chain operators (как бы это культурнее перевести? операторы цепочки конвейера? или просто операторы цепочки или операторы конвейера? - любой вариант режет слух). Не могу сказать что это хорошо, хотя и не могу утверждать что плохо. Это просто так, и никак иначе.

субъективное мнение: пошик создавался не за один день, было много на него накручено, когда я добрался до try catch finally - вообще полный восторг, наконец можно скрипт просто и элегантно завернуть в адекватную обработку ероров и/или ворнингов, настроить правильные постдействия... а теперь есть официальные примеры, в которых англицким по-белому написано (хоть и несколько иносказательно): забейте на ошибки, если они таки будут - вот вам || и радуйтесь этому как хотите. Ну а если ошибки нам неинтересны то и тем более &&

Как по мне, это самые, что ни на есть логические -И- и -ИЛИ-

это вряд ли...
https://docs.microsoft.com/en-us/pow...or-interaction
если исключение слева, то правую часть фиг получим..., что неверно в случае ||

А это вроде, как бы и не при чем? :)
В таком варианте вообще не будет прерывающих исключений...

Это чтобы подавить вывод ошибки.

Да, это понятно... но:
Подавляя вывод ошибок при возникновении непрерывающих исключений, можем получить неожиданные результаты при разработке скрипта в целом. Можно, конечно, уповать на свою память и думать, что ошибки мы нигде не совершим, но... мне кажется, что это несколько самонадеянно. :)
Да, можно, в каждом командлете переопределять действие этой переменной параметром erroraction, но все эти действия точно нужны, для использования этих синтетических И и ИЛИ? До powershell 7.0 как-то ведь обходились без них...

Я и сейчас не прибегаю к такой конструкции. В основном:

Главным образом при веб-запросах, например при обновлении FAR.

нет. или по крайней мере не совсем. даже в bash или cmd/bat это не "И" и "ИЛИ", хоть их так и называют.

кстати поведение || в try может стать еще более неожиданным чем мне до этого казалось.
Вот здесь всё банально и логично:
Просим возвращать true если имели ошибку - такое и получаем.
А теперь заворачиваем в try-catch:
c Get-Childitem получаем ожидаемый результат
сиречь True, а вот с 1/0...

внезапно вываливаемся в catch.
Вот реально!

Ну, вряд ли, эта конструкция предназначена для замены try-catch-finally, она скорее замена условному блоку, т.е. упрощение записи, а существующие -and и -or, выдают не результат выполнения операторов и их операндов, а булевый... скажем:
получим True, в отличие от:
и до версии 7.0, подобное выражение, нам пришлось бы записать так:
т.е. по сути, вместо && и ||, это соответственно:
Да, только результат будет не булевым, а именно то, что выполняет левый или правый операнд, всё просто, см. выше...

там, как раз, полные аналоги этих введеных операторов в ps 7.0

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

хмм, а у меня так:
Файл 164523

YuS_2, не тот кусок кода скопировал, мой косяк.
так и есть, но согласно логике описанной у ms строка
вроде как не содержит ошибки (точнее содержит, но превращает ее все равно в true), т.о. в catch вываливать не должно, но вываливается.

Try ее и отлавливает, оно не руководствуется конечным результатом ($true или $false не важны), а лишь отлавливает ошибку:

Значит отлавливает ее по-разному, иначе почему точно так же содержащая ошибку
возвращает True и в catch не вываливается?

Потому, что ее надо прерывать:

Не объясняет поведения try-catch. Разумеется если дергать стоп при ошибке, то так оно и будет, но вопрос не в том как заставить пош делать так как нужно, а понять как же он вообще работает в данном случае, при находящемся $ErrorActionPreference в дефолтном Continue.

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

конечно, по-разному. try-catch-finally не ловит непрерывающие исключения.
То бишь, чтобы всё было в одинаковых условиях, должно быть так:

ок, если уровнять обе строки посредством $ErrorActionPreference = 'Stop', значит вроде как они рАвно должны отработать и при $ErrorActionPreference = 'Continue'.

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