@PowerShell/powershell-committee This is a breaking change. Please review. We made a similar change for matching commands. Where we prefer literal matches over wildcard matches.

Travis Plunk (@TravisEz13) So I can categorize these correctly in the future, can you educate me as to why this would be considered a breaking change?

@PowerShell/powershell-committee agrees that the current behavior is broken where:

set-location -literalpath ?

must treat ? as a literal value and not a wildcard. We don't believe this is a breaking change that causes concern, however, we are concerned with the location of the code change in a helper that is used by many code paths which itself may introduce a regression somewhere else.

I'm not sure your change addressed the committee's concern about the location of the change.

Travis Plunk (@TravisEz13) Sorry, the day job has distracted me from following through on this and one other PR. I honestly thought the "location of the code change" comment was sort of meant to be rhetorical. The bug itself can be scoped to that helper function: In what scenario would I possibly pass a literal, existing directory path to GetCorrectCasedPath() and it would be acceptable to get back a reference to an existing different directory? The function exists solely to normalize case within a path --- it should NEVER be returning a path to a different file.

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Mainainer, Please provide feedback and/or mark it as Waiting on Author

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Mainainer, Please provide feedback and/or mark it as Waiting on Author

Is this ready for merge or are we still waiting for reviews? Travis Plunk (@TravisEz13)

Travis Plunk (@TravisEz13) Sorry, the day job has distracted me from following through on this and one other PR. I honestly thought the "location of the code change" comment was sort of meant to be rhetorical. The bug itself can be scoped to that helper function: In what scenario would I possibly pass a literal, existing directory path to GetCorrectCasedPath() and it would be acceptable to get back a reference to an existing different directory? The function exists solely to normalize case within a path --- it should NEVER be returning a path to a different file.

Here is the direct call:
https://sourcegraph.com/search?q=repo:powershell/powershell+GetCorrectCasedPath&patternType=literal

Then, NormalizePath is used in these places:
https://sourcegraph.com/search?q=repo:powershell/powershell+content:%22Microsoft.PowerShell.Commands%22+content:%22NormalizePath%28%22+lang:c%23++-file:%22src/System.Management.Automation/namespaces/RegistryProvider.cs%22&patternType=literal#1

We need to make sure we didn't break any of these calls.

I'll let the Provider working group review from here.

The GetCorrectCasedPath() is not in right place. This would only have to be used in Formatting System and completors.

Travis Plunk (@TravisEz13) All of the non-file system paths you reference end up calling a base class version or provider-specific version of NormalizePath() so this change luckily does not affect them.

Ilya (@iSazonov) I think that might be splitting hairs to some degree. When somebody does a Set-Location to a specific path, do you want the resultant path at the prompt to be case-accurate or not? I think it might be hard to address all the "what if" sort of cases. Regardless, this PR was authored to address the "bug" within GetCorrectCasedPath() itself so I was hoping not to boil the ocean to get this committed. :-)

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author