René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Namespace variable notation unexpectedly treats paths as wildcard expressions","articleBody":"\u003csup\u003eConceptually related: #4726.\u003c/sup\u003e\r\n\r\nNote: Fixing this issue would technically be a breaking change.\r\n\r\nPowerShell treats the following:\r\n\r\n    ${\u003cdrive\u003e:\u003cname\u003e}\r\n\r\nas if you had specified:\r\n\r\n    Get-Content -Path \u003cdrive\u003e:\u003cname\u003e  # or, with assignment, Set-Content -Path ...\r\n\r\nThis notation - though often used with the `Env:` drive (e.g., `$env:Path`) -  is little-known as a *general paradigm* named **_namespace variable notation_**, which is explained in [this SO answer](https://stackoverflow.com/a/55036515/45375).\r\n\r\n**The problem is the use of `-Path` rather than `-LiteralPath`** (conceptually speaking), because `-Path` **interprets its argument as a _wildcard expression_**.\r\n\r\nBy design, you can only ever target a _single_ item with namespace notation and if you intentionally specify a wildcard that resolves to _multiple_ items, the statement _breaks_.\r\n\r\n**There is no good reason for namespace notation to treat paths as wildcard expressions to begin with**, just as it makes no sense to do so for executable invocations and redirections (see #4726).\r\n\r\nThe fact that they are treated as wildcards causes problems with item names that _happen to look like_ wildcard expressions, in one of two ways:\r\n\r\n* You may not be able to create a new item, such as a new environment variable, at all.\r\n* Perhaps worse, you may inadvertently target a different, preexisting item.\r\n\r\nTaking the example of wanting to assign to / query the value of an environment variable literally named `[foo]` with `${env:[foo]}`, from [this SO question](https://stackoverflow.com/q/55343828/45375):\r\n\r\n# Steps to reproduce\r\n\r\n```powershell\r\n# Try to create env. var. literally named '[foo]'\r\n${env:[foo]} = 'bar'\r\n# Create a seemingly unrelated env. var. whose name happens to match\r\n# [foo] *if interpreted as a wildcard expression*\r\n$env:o = 'no'\r\n# Get the value\r\n${env:[foo]}\r\n```\r\n\r\n# Expected behavior\r\n\r\n```none\r\nbar\r\n```\r\n\r\nThat is, implicit creation of the variable via namespace notation should succeed, as should subsequent retrieval.\r\n\r\n# Actual behavior\r\n\r\n```none\r\nCannot find path 'env:[foo]' because it does not exist.\r\nno\r\n```\r\n\r\n* That is, implicit creation of the variable failed, because the wildcard resolution of `[foo]` matched nothing and so there was effectively no variable name to assign to / create.\r\n\r\n* `${env:[foo]}` unexpectedly retrieved the value of `${env:o}`, because `[foo]` interpreted as a wildcard matches `o`.\r\n\r\nThe **workaround** is to use _double_ `` ` ``-escaping: `${env:``[foo``]}`; that the escape char. must be doubled  is an additional quirk - see #7999\r\n\r\n# Environment data\r\n\r\n```none\r\nPowerShell Core 6.2.0-rc.1\r\nWindows PowerShell v5.1\r\n```\r\n","author":{"url":"https://github.com/mklement0","@type":"Person","name":"mklement0"},"datePublished":"2019-03-25T19:17:08.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":7},"url":"https://github.com/9225/PowerShell/issues/9225"}