@microsoft-github-policy-service agree

The place it is done for cmdlets like Get-ChildItem is here, and it supports ~, startsWith("~/") and startsWith("~\"):

This PR has 59 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Label      : Small
Size       : +48 -11
Percentile : 23.6%

Total files changed: 4

Change summary by file extension:
.cs : +23 -10
.ps1 : +23 -0
.json : +2 -1

Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

Steve Lee (@SteveL-MSFT) James Truher (@JamesWTruher) Dominic Slee (@domsleee) The fact that PowerShell on Linux quotes space-containing paths during tab expansion is broken behavior since 7.4.0, because it breaks translation of ~ when calling executables.

This PR will now break Windows in the same way, because of the same tab expansion behavior.

Additionally, trying to use PowerShell's native escaping for spaces to work around this behavior on Linux is also currently broken:

In my unvarnished opinion, the dumpster fire around tab expansion behavior with ~ introduced in 7.4.0 was ill thought out, and this one PR is not remotely a complete fix, even on Windows. Frankly: where are the test cases for all of this? How was this feature allowed out into the wild without realizing how many things were being broken, and how is the team working to resolve them before 7.5.0? The fact that the team has been 100% silent on #20750 is extremely disappointing, given that the issue has been open since November 2023. Will anybody ever respond?

While I share your frustration around the lack of responses / a decision on #20750,
what you're describing are known bugs that must be fixed separately and their existence is not an argument against the value or implementation of this PR:

• Broken tab-completion with file or directory names with spaces in the context of tilde-prefixed paths (~) #20851
• Unix: Emulation of ~ (tilde) expansion for native utilities is syntactically incomplete #20754

Michael Klement (@mklement0) Not to be overly pessimistic, but neither of your issues have any comment from anybody on the team, either. Right now you're we're basically hoping they agree and create (or allow) a fix in time for 7.5.0.

Fair point, Brad Wilson (@bradwilson) - let's hope that this exchange helps.

The behavior of this implementation of tilde expansion seems utterly unintuitive to me and breaks basic assumptions that I (and I assume many other PowerShell users) have:

$Path = "~"
cmd /c echo $Path # C:\Users\admin
cmd /c echo "$Path" # ~

One of the things I like about PowerShell is that I don't have to think about quoting rules – if I want to pass a variable as a parameter, I just pass a parameter and don't worry about quoting. This feature breaks that, and means that whenever I'm passing a variable to a native command, I have to actively think whether I want to expand ~ and quote accordingly. PowerShell is complex enough as it is, and I don't see any way this feature can pull its weight. I disagree with the original implementation of this feature, where ~ was always expanded, but at least it was consistent, unlike this implementation.

I first encountered this feature when doing something like

ssh <host> cp ... ~/...

as part of a longer command and receiving mysterious errors that C:Usersadmin... is not an existing directory, which took me quite a lot of time to debug. I would not intuitively expect that ~ will be expanded in this context, much less so when it wrapped in a PowerShell function and the ~ is passed as a parameter.

In POSIX shells, ~ is expanded immediately when written, and not when passed to a native command:

x1=~
x2="~"
echo $x1 # /home/...
echo "$x1" # /home/...
echo $x2 # ~
echo "$x2" # ~

This is not ideal, but it is much more intuitive than expanding ~ in the command invocation. I understand why PowerShell cannot resolve ~ in the same way.

I'd personally happily sacrifice the resolution of ~ when calling native commands if it means that PowerShell quoting rules will remain simple and interact nicely with remote ssh calls and other places where literal ~ is passed. I understand that this is a bigger problem on Linux compared to Windows, but tab-expanding ~ seems like a safer, simpler and well-tested alternative.

The ssh example is an interesting one, as it mixes the worlds of Windows and Unix-like platforms.

Were you to run your example command on Unix, you would have to escape or quote the ~ to prevent instant expansion or - and with this feature you'll now need to do it on Windows too.

• In POSIX-compatible shells, you'd have to do echo \~ or echo '~', for instance.
• While /bin/echo '~' / cmd /c echo '~' also prevents instant expansion from PowerShell, the echo \~ equivalent, /bin/echo `~/ cmd /c echo `~ currently does not: see Unix-like platforms: native globbing and tilde expansion cannot be prevented with backtick-escaping #21304

Similarly, expansion still happening via variables - $p = "~"; /usr/bin/echo $p / $p = "~"; cmd /c echo $p should be considered a bug too, so I've created:

• Unix-like platforms, Windows with the experimental PSNativeWindowsTildeExpansion feature: Native tilde expansion unexpectedly expands tilde in variable references #21323

Were you to run your example command on Unix, you would have to escape or quote the ~ to prevent instant expansion or - and with this feature you'll now need to do it on Windows too.

Yes, but I use PowerShell because it's better than Unix shells. :)

More seriously, PowerShell takes different approach than Unix-style shells, and not having to quote variables is an important part of what makes PowerShell more intuitive and comfortable for daily usage. In Unix shells, you're expected to quote more-or-less everything, which is not expected in PowerShell, and this PR makes PowerShell quoting more complex, for imo lesser benefit.

I understand the desire for consistent ~ behavior between cmdlets and native commands, but adding special cases for quoting (a much more commonly used and core feature of PowerShell) to achieve that seems too great of a sacrifice to me.