[YuS_2]

-Identity:"$User" »

-Replace:@ »

Если не секрет, почему двоеточие, а не пробел?

[Kazun]

Код:

-Replace:@{"logonHours"=[byte[]]("0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0")}

[YuS_2]

Kazun, тогда к Вам вопрос: так почему, всё же, двоеточие? В документации другой синтаксис...

[Elven]

YuS_2, а чем плохо двоеточие? нормальный символ
Kazun, спасибо, как всегда коротко и точно.

[Kazun]

Kazun, тогда к Вам вопрос: так почему, всё же, двоеточие? В документации другой синтаксис... »

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

Код:

PS > function foo([switch]$force=$true) {$force}
PS > foo

IsPresent
---------
     True


PS > foo -force:$false

IsPresent
---------
    False


PS > foo -force $false

IsPresent
---------
     True

[YuS_2]

Для передачи параметров можно использовать ":" »

Спасибо!
А в какой документации существует описание?

а чем плохо двоеточие? нормальный символ »

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

[Kazun]

Windows PowerShell Language Specification Version 3.0 - https://www.microsoft.com/en-us/down....aspx?id=36389

• When specifying an argument that matches a parameter having the [switch] type constraint (§8.10.5), the presence of the argument name on its own causes that parameter to be set to $true. However, the parameter's value can be set explicitly by appending a suffix to the argument. For example, given a type constrained parameter p, an argument of -p:$true sets p to True, while -p:$false sets p to False.

Код:

8.10.5 The [switch] type constraint
When a switch parameter is passed, the corresponding parameter in the command must be constrained by the type switch. Type switch has two values, True and False.
Consider the following function definition and calls:
function Process ([switch]$trace, $p1, $p2) { … }

Process 10 20					# $trace is False, $p1 is 10, $p2 is 20
Process 10 -trace 20			# $trace is True, $p1 is 10, $p2 is 20
Process 10 20 -trace			# $trace is True, $p1 is 10, $p2 is 20
Process 10 20 -trace:$false	# $trace is False, $p1 is 10, $p2 is 20
Process 10 20 -trace:$true		# $trace is True, $p1 is 10, $p2 is 20

Комментарий от разработчика по поводу синтаксиса(+ касательно PowerShell Core, где -switch bool не поддерживается) - https://github.com/PowerShell/PowerS...ment-311759499

BrucePay commented on 28 Jun 2017

@mklement0 The -switch: [bool] syntax is deliberately awkward as there is really only one scenario for passing an actual parameter to a switch: commands calling commands (which you described nicely in an earlier comment.) If you expect the user to pass an actual parameter, then you should be using boolean. If your cmdlet requires the user to pass arguments to a switch parameter then your cmdlet should be redesigned.

@SteveL-MSFT No we can't support -switch [bool]. The current behavior is fundamental to how the parameter binder works.

-Command and -File are very different operations. -Command gathers all of the arguments into a string and then processes that string as a PowerShell script. On the other hand, -File points at a script and passes the remaining arguments to the process. The application receives these arguments through argv[] as strings. Process creation simply doesn't allow for the parent to pass anything but strings to the child process. The PowerShell runtime does do some interpretation on these strings (e.g. treating strings that start with '-' as parameters instead of arguments) but this is necessarily limited by the lack of type information.