Prerequisites
Steps to reproduce
Note:
-
I think-RelativeBasePath shouldn't even accept wildcard expressions, so to me the preferable resolution is to simply treat -RelativePath arguments as literal paths. (Currently, a wildcard is accepted, but only if it resolves to exactly one item).
-
Doing so would make the problem at hand go away; if this is decided against, at least the inconsistency below must be fixed.
# Matching with *literal* path.
Resolve-Path System32 -Relative -RelativeBasePath C:\Windows
# Matching the same path *via wildcard*
Resolve-Path System32 -Relative -RelativeBasePath C:\Window[s]
Expected behavior
Actual behavior
.\System32
..\Windows\System32
That is, even though in both commands C:\Windows was ultimately used as the base path, the wildcard matching resulted in different output.
Error details
No response
Environment data
Visuals
No response
Prerequisites
Steps to reproduce
Note:
I think
-RelativeBasePathshouldn't even accept wildcard expressions, so to me the preferable resolution is to simply treat-RelativePatharguments as literal paths. (Currently, a wildcard is accepted, but only if it resolves to exactly one item).-OutFileparameter ofInvoke-WebRequestand-InvokeRestMethod, which used to accept wildcards, but now interprets paths literally - see Make-OutFileparam in web cmdlets to work like -LiteralPath #11701 (comment)Doing so would make the problem at hand go away; if this is decided against, at least the inconsistency below must be fixed.
Expected behavior
Actual behavior
That is, even though in both commands
C:\Windowswas ultimately used as the base path, the wildcard matching resulted in different output.Error details
No response
Environment data
Visuals
No response