New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Namespace variable notation unexpectedly treats paths as wildcard expressions #9225
Comments
Isn't the wildcard behavior a function of the provider? In this case the ENV: provider, but in the case of a drive letter, its the file system provider. Does PowerShell need to tell the provider to accept it as a 'literal' path? I have also run in to the wildcard situation using the ENV provider using the namespace convention, but I think I was testing with a The above example also gives a different error if the wildcard resolved to multiple items.
The double backticking seems peculiar, as it only seems to be accepted as demonstrated, so it appears to be on purpose. It seems to be special to just the namespace variable notation. At this point I would be willing to bet somewhere someone had a use for wildcard paths with the namespace variable notation, and so that's why this exists. I am thinking about if these notations should be added to the PowerShell/EditorSyntax PR that I have been working on. I suspect they only apply to certain providers, of which those providers could be redefined or changed so there is probably no consistent way to scope these specific notations. |
Namespace variable notation applies to all providers that have PSDrives available, but isn't usable with all of them. In order to be usable with this syntax, the provider has to implement It also won't resolve to the provider if the PSDrive name is already taken by an existing scope (e.g., a PSDrive named I think that this is most likely to be an accidental result of the default providers by default applying globbing unless it's specifically requested to process the path as literal. The fact that a path that does resolve to multiple items fails to do anything other than throw an error would appear to support that, I think. 😄 |
Thanks for the clarifications, @vexx32.
I think it's more likely accidental (I'm speculating), perhaps dating back to a time before the great Similarly unhelpful behavior (accepting a wildcard, but requiring resolution to a single item):
|
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you. |
2 similar comments
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you. |
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you. |
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes. |
Conceptually related: #4726.
Note: Fixing this issue would technically be a breaking change.
PowerShell treats the following:
as if you had specified:
This 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.The problem is the use of
-Path
rather than-LiteralPath
(conceptually speaking), because-Path
interprets its argument as a wildcard expression.By 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.
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).
The fact that they are treated as wildcards causes problems with item names that happen to look like wildcard expressions, in one of two ways:
Taking the example of wanting to assign to / query the value of an environment variable literally named
[foo]
with${env:[foo]}
, from this SO question:Steps to reproduce
Expected behavior
That is, implicit creation of the variable via namespace notation should succeed, as should subsequent retrieval.
Actual behavior
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.${env:[foo]}
unexpectedly retrieved the value of${env:o}
, because[foo]
interpreted as a wildcard matcheso
.The workaround is to use double
`
-escaping:${env:``[foo``]}
; that the escape char. must be doubled is an additional quirk - see #7999Environment data
The text was updated successfully, but these errors were encountered: