[Elven]

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

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

[YuS_2]

или просто операторы цепочки или операторы конвейера? »

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

абейте на ошибки, если они таки будут - вот вам || и радуйтесь этому как хотите. Ну а если ошибки нам неинтересны то и тем более && »

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

[Foreigner]

если исключение слева, то правую часть фиг получим..., что неверно в случае || »

Код:

 > $ErrorActionPreference = 'SilentlyContinue'
 > 1/0 && $true || $false
False
 > 0/1 && $true || $false
0
True

[YuS_2]

$ErrorActionPreference = 'SilentlyContinue' »

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

[Foreigner]

А это вроде, как бы и не при чем? »

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

[YuS_2]

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

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

[Foreigner]

До powershell 7.0 как-то ведь обходились без них... »

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

Код:

$ErrorActionPreference = 'Stop'

Try{}
Catch{}
Finally {} # редко

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

[Elven]

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

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

Try{} Catch{} Finally {} »

кстати поведение || в try может стать еще более неожиданным чем мне до этого казалось.
Вот здесь всё банально и логично:

Код:

Get-ChildItem nonexistfile || $true

Get-ChildItem: Cannot find path '/path/nonexistfile' because it does not exist.
True


1/0 || $true                       

RuntimeException: Attempted to divide by zero.
True

Просим возвращать true если имели ошибку - такое и получаем.
А теперь заворачиваем в try-catch:
c Get-Childitem получаем ожидаемый результат

Код:

try {
  Get-ChildItem nonexistfile || $true
}
catch {
  Write-Error "$?"
}

Cannot find path '/path/nonexistfile' because it does not exist.

True

сиречь True, а вот с 1/0...

Код:

try {
  1/0 || $true
}
catch {
  Write-Error "$?"
}

Write-Error: False

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

[YuS_2]

Я и сейчас не прибегаю к такой конструкции. »

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

Код:

$(ps) -and $(write-output test)

получим True, в отличие от:

Код:

$(ps) && $(write-output test)

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

Код:

ps;if($?){write-output test}

т.е. по сути, вместо && и ||, это соответственно:

Код:

function test-command ($a){return $a}
# && правый будет выполнен только если выполнен левый
test-command '1'; if ($?) {test-command '2'}
# || если левый операнд выполнен
test-command '1'; if (!$?) {test-command '2'}
# || если левый операнд не выполнен, выполняем правый
write-error 'error'; if (!$?) {test-command '2'}

нет. »

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

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

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