You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Get-Variable / Set-Variable and Test-Path attempt to support wildcarding on the name supplied. They all fail if you pass them a name as follows: a[b-a] because they see [b-a] as a broken wildcard range.
This bites psake when it attempts to push variables into child scopes for task execution, and apply supplied -properties arguments over the top of those in the script. Psake passes the name of the properties literally to Test-Path, which causes the error:
Or as follows (which is what psake ends up doing as a result):
Test-Path 'Variable:\a[b-a]'
I've raised a (Connect article for this)[https://connect.microsoft.com/PowerShell/feedback/details/926973/set-variable-throws-the-specified-wildcard-pattern-is-not-valid-if-variable-name-contains-or-chars-in-some-cases], because I feel existing PowerShell behavior is actually broken. However, there is a workaround that I think psake should implement till they fix it :-) which is to escape the names passed to set-variable / get-variable / test-path by prefixing the square brackets with backticks as follows (if I can get the markdown right :)
This bit me with OctopusDeploy, because (in my case) it passes in properties of exactly that form which - just because of my role names - end up having backwards ranges within them. If interested, I blogged about this
The text was updated successfully, but these errors were encountered:
@nightroman nice. Unfortunately that's not going to work for me. Nesting the properties in that way would would bypass the reason for using properties in the first place (having defaults set in psake that can be overridden from the outside). It'd be 'pass them all or nothing'.
What instead I've ended up doing is pre-filtering the hashtable of variables that OctopusDeploy provides, prior to passing to PSake (since the properties that are causing problems aren't ones I care about anyway). Like this:
This way I still get to override any property in my psake script by creating a variable with the same name in Octopus, but I filter out the OctopusDeploy intrinsic/built-in ones (which are the ones causing the issue)
Get-Variable / Set-Variable and Test-Path attempt to support wildcarding on the name supplied. They all fail if you pass them a name as follows: a[b-a] because they see [b-a] as a broken wildcard range.
This bites psake when it attempts to push variables into child scopes for task execution, and apply supplied -properties arguments over the top of those in the script. Psake passes the name of the properties literally to Test-Path, which causes the error:
You can replicate this as follows:
Or as follows (which is what psake ends up doing as a result):
I've raised a (Connect article for this)[https://connect.microsoft.com/PowerShell/feedback/details/926973/set-variable-throws-the-specified-wildcard-pattern-is-not-valid-if-variable-name-contains-or-chars-in-some-cases], because I feel existing PowerShell behavior is actually broken. However, there is a workaround that I think psake should implement till they fix it :-) which is to escape the names passed to set-variable / get-variable / test-path by prefixing the square brackets with backticks as follows (if I can get the markdown right :)
This bit me with OctopusDeploy, because (in my case) it passes in properties of exactly that form which - just because of my role names - end up having backwards ranges within them. If interested, I blogged about this
The text was updated successfully, but these errors were encountered: