You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Per #1081, we have the known issue of not supporting a path with a literal backward slash for PowerShell cmdlets. This branch is work-in-progress that investigated PowerShell's path normalization.
The summary is that it's a mess. PowerShell has half a dozen different path normalization functions (all essentially just blindly replacing / with \, or the reverse on Linux), another dozen locations where these are ignored and a path.Replace() is done, and completely separate code to handle escape character parsing (which is tied into the globbing system); and all of this is spread across several systems.
My WIP branch removes all the normalization functions and adds some (dumb, so far) logic to handle a path with a backtick escaped backward slash (but it needs to be improved to handle backtick escaped backticks). Normalization of all backticks can only happen once, and we need to figure out how to make this happen, because parsing globs must be handled around the same time (since glob characters may be escaped). As of now, the WIP does allow escaping a backward slash with a backtick.
Bruce Payette (@BrucePay): I think we're "good enough" in this regard already. Since you've been in the globbing code lately, do you know of any shortcoming we still have from a functional perspective? I'd like to close this in lieu of more specific issues.
FWIW, In issue #3414 I mentioned that part of the issue is "premature normalization".
Also, paths ending up fully-qualified (I believe by the globbing mechanism) makes it difficult to provide relative paths to cmdlets like New-Item -ItemType SymbolicLink (#3500).
jeffbi: thanks for the context. I'm adding this to our Usability project. At some point, I need to look at all these and figure out holistically what we're okay with.
This is very high-level and broad kind of issue, which is too risky at this point.
Closing this as duplicate of more specific and narrow #3666 and #3500.
Activity
andyleejordan commentedon Jun 16, 2016
Bookmarking for reference, NavigationCmdletProvider API.
vors commentedon Jul 21, 2016
Maybe we can move it for Future?
1 remaining item
andyleejordan commentedon Oct 4, 2016
Removing assignment as this is future work that will require going through RFC.
joeyaiello commentedon May 22, 2017
Bruce Payette (@BrucePay): I think we're "good enough" in this regard already. Since you've been in the globbing code lately, do you know of any shortcoming we still have from a functional perspective? I'd like to close this in lieu of more specific issues.
jeffbi commentedon May 22, 2017
FWIW, In issue #3414 I mentioned that part of the issue is "premature normalization".
Also, paths ending up fully-qualified (I believe by the globbing mechanism) makes it difficult to provide relative paths to cmdlets like
New-Item -ItemType SymbolicLink(#3500).joeyaiello commentedon May 22, 2017
jeffbi: thanks for the context. I'm adding this to our Usability project. At some point, I need to look at all these and figure out holistically what we're okay with.
joeyaiello commentedon Aug 7, 2017
Andrew (@anmenaga) do you have enough context from jeffbi for this to be actionable?
anmenaga commentedon Sep 18, 2017
This is very high-level and broad kind of issue, which is too risky at this point.
Closing this as duplicate of more specific and narrow #3666 and #3500.