Skip to content

Translating PSDrive-based path arguments for external (native) executables is overzealous (PSNativePSPathResolution) #13640

@mklement0

Description

@mklement0

PR #12386 introduced experimental feature PSNativePSPathResolution, which as of (at least) PowerShell Core 7.1.0-preview.7 has become a default feature.

Its purpose is to translate PowerShell-drive-based paths to native filesystem paths, because external executables only understand the latter.

This translation is currently overzealous in that it nonsensically translates an argument that starts with : (which clearly isn't a drive-based path).

@DHowett has pinpointed the problematic behavior to:

if (path.Contains(':'))
{
LocationGlobber globber = new LocationGlobber(context.SessionState);
try
{
ProviderInfo providerInfo;
// replace the argument with resolved path if it's a filesystem path
string pspath = globber.GetProviderPath(path, out providerInfo);
if (string.Equals(providerInfo.Name, FileSystemProvider.ProviderName, StringComparison.OrdinalIgnoreCase))
{
path = pspath;
}
}
catch
{
// if it's not a provider path, do nothing
}
}

Steps to reproduce

On Unix:

/bin/echo :foo | Should -Be ':foo'

On Windows:

cmd /c echo :foo | Should -Be ':foo'

Expected behavior

The test should succeed.

Actual behavior

The test fails, because the the current location's path is unexpectedly prepended to :

Expected strings to be the same, but they were different. Expected length: 4 Actual length:   44 Strings differ at index 0.
Expected: ':foo' But was:  '/Users/jdoe...'

Environment data

PowerShell Core 7.1.0-preview.7

Metadata

Metadata

Assignees

Labels

Issue-BugIssue has been identified as a bug in the productResolution-FixedThe issue is fixed.WG-Engine-Providersbuilt-in PowerShell providers such as FileSystem, Certificates, Registry, etc.

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions