Bypassing translation of PSDrive-based path arguments for external (native) executables is obscure and inadequate (PSNativePSPathResolution)

Follow-up from #13640.

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.

While this is likely helpful in most cases, there are two problems, both stemming from the fact that PowerShell cannot know whether a given argument passed to an external program indeed represents a file path:

• There must be a way to bypass this translation, in case an argument that happens to look like a PSDrive-based path should be passed as-is.

  • Currently, the only way to bypass the translation is to use single-quoting (e.g, 'temp:foo' rather than unquoted temp:foo or double-quoted "temp:foo", but this is problematic for two reasons:
    • This distinction is obscure, because the user is likely to conceive of both 'temp:foo' and "temp:foo" as literals, which in any other context they are.
    • More importantly: it only works for literal arguments, and not for variables and expressions.

• Even with such a mechanism, however, the problem is that bypassing may only be situationally necessary, depending on what custom PS drives happen to be defined at the time of the external-program call, so you cannot really anticipate when bypassing is necessary.

I see two possible solutions:

• (a) Roll back the feature, recognizing that it is ultimately too fraught (it hasn’t been in any official release yet).

• (b) Minimize the risk of false positives as follows, but note that their complete elimination isn’t possible:

  • Currently, the translation is triggered by any argument with a prefix that looks like a drive specification of a custom PS drive (e.g., temp:) irrespective of what follows: that is, it doesn’t matter whether the path refers to an existing item or even if the path is syntactically correct.

  • There will be far fewer false positives if the translation is only performed if the argument refers to an existing file-system path; e.g., temp:foo should only be translated if a file or directory at temp:/foo actually exists.

  • However, this implies:

    • Users may be confused when a non-existing path they expected to exist goes untranslated.
    • Arguments may by design represent not-yet-extant paths, such as when passing an output file path.
    • A bypass mechanism is still needed, one that also supports passing arguments via variables and expressions; though perhaps the need for it will be so rare that the limited --% will do.

Steps to reproduce

The following is predicated on suggestion (b) above, i.e., only performing translation for existing PSDrive-based paths, and assumes that no file/dir. exists at temp:/foo

On Unix (use cmd /c echo on Windows):

$arg = 'temp:foo'; /bin/echo $arg | Should -be $arg

Expected behavior

The test should pass, because since temp:foo doesn’t refer to an existing file-system path, it should be passed as-is.

Actual behavior

The test fails, because the temp:foo is translated to (Get-PSDrive temp).Root + ':/foo', even though temp:/foo doesn’t exist; e.g., on macOS:

Expected: 'temp:foo' But was:  '/var/folde...'

Environment data

PowerShell Core 7.1.0-preview.7

[SteveL-MSFT]

I had looked into this and the problem is by the time the NativeCommandProcessor gets the arg, there is no way to differentiate single vs double quotes. At this point, it’s not worth the effort to fix this so I’m removing this feature altogether as other than the default temp drive, I don’t think many people are using custom filesystem psdrives where this feature is useful.

[KyleKolander]

Fair enough. I had to at least ask. 😄 I’ll use Directory Junctions instead. Lacks the syntactic sugar of the PSDrive, but it also works across all of Windows (not just within PowerShell).