Wildcard expressions are supported, with all providers, in the -Path
parameter of the Get-Item
cmdlet, and also with Get-Content
, which is preferable here because it returns the environment-variable value directly (no need for (...).Value
); to demonstrate:
$env:RELEASE_ARTIFACTS_FOO_REPOSITORY_ID = 1
Get-Content env:RELEASE_ARTIFACTS_*_REPOSITORY_ID # -> 1
Perhaps surprisingly, they are also supported when you use namespace variable notation, though you must then enclose the reference in {...}
(because a *
would otherwise not be recognized as part of a variable name):
${env:RELEASE_ARTIFACTS_*_REPOSITORY_ID} # -> 1
Caveats:Tip of the hat to Daniel.
If the wildcard pattern matches multiple items (environment variables in this case), a statement-terminating error occurs. Use the Get-Content
(or Get-Item
) approach to retrieve multiple values (items).
- Given this awkwardness, along with the escaping pitfalls discussed below, it would make sense not to support wildcard matching in namespace variable notation, as suggested in GitHub issue #9225; while technically a breaking change, my sense is that not much real-world code would be impacted.
Strangely, namespace variable notation with wildcard patterns does not work with variables (where the notation is rarely used to begin with, however, given that $variable:foo
offers no advantage over $foo
): ${variable:HOM*}
performs no wildcard matching and behaves like an undefined variable (it quietly evaluates to $null
by default).
- While the
Get-Content
/ Get-Item
approach does work, note that there's also a dedicated Get-Variable
cmdlet (use -ValueOnly
to get just the value) - e.g. Get-Variable HOM* -ValueOnly
- which additionally supports accessing variables in different scopes, via the -Scope
parameter.
Namespace variable notation vs. Get-Content
:
Namespace variable notation is both more concise and performs better (because a cmdlet call isn't involved).
However, the Get-Content
approach is sometimes required, namely when you use a variable to specify the environment-variable name or name pattern; that is, assuming variable definition $envVarName = 'RELEASE_ARTIFACTS_*_REPOSITORY_ID'
:
${env:$envVarName}
does not work,
- but
Get-Content env:$envVarName
does.
Escaping pitfalls:
Escaping wildcard metacharacters such as [
that you want to be interpreted verbatim is currently challenging, due to the bugs discussed in this answer.
If the whole name should be used verbatim, you can avoid the need for escaping by using Get-Content
's -LiteralPath
parameter instead; however, this isn't an option with namespace variable notation, where names are invariably treated as wildcard patterns.