PowerShell - How to get Environment Variable value using wildcards

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.