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
{{ message }}
Repository navigation
Powershell does not expand '~' for external programs #20031
The last command opens an empty .bashrc file in current directory in neovim/vscode
Expected behavior
`~` should be expanded to `$HOME`
Actual behavior
pwsh does not expand `~` for external command
Error details
No response
Environment data
Name Value
---------
PSVersion 7.3.6
PSEdition Core
GitCommitId 7.3.6
OS Microsoft Windows 10.0.19045
Platform Win32NT
PSCompatibleVersions {1.0,2.0,3.0,4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Could not be reproduced on either Windows (with the forward-slash path separator) or Linux. For testing used micro editor on both platforms.
# on Windows (pwsh 7.3.6)
$ micro ~/Desktop/desktop.ini # open
$ micro ~\Desktop\desktop.ini # not open
Could not find user: user: unknown user \Desktop\desktop.ini
Press enter to continue
# on Linux (pwsh 7.4.0-preview.4)
$ micro ~/.bashrc # open
Just tried in other editor (internal Far manager's editor far -e ) and behavior as in your issue. I think micro itself parses the filepath. That's why it works. And your issue is right.
maybe someone can take my PR and address the edge cases in the future
For now:
Only on Unix do you get ~ expansion, namely if the ~ is _unquoted and followed by / (notably, this means that something like ~<username> to refer to a given user's home dir. is not supported - see Implement ~username expansion on Windows and Linux #12387)
On Windows, ~ expansion is not implemented (nor is automatic globbing, though the latter sensibly so).
Note that the scope of #12386 was larger than just ~ expansion: It tried to automatically convert paths based on PowerShell drives to file system-native drives, given that native (external) utilities don't know about PowerShell drives; e.g. temp:/foo.txt would be converted to C:\Users\jdoe\AppData\Local\Temp\foo.txt
If done robustly - and fully doing so is ultimately impossible - PowerShell on Unix would benefit from this conversion too.
It's also worth noting that the never-introduced implementation in #12386 handled ~ on Windows differently than the already-implemented ~ expansion on Unix:
Unlike the Unix implementation, ~inside "..." was - surprisingly also expanded (only '...' quoting prevented the expansion).
E.g., ~ in cmd /c echo "~"was expanded on Windows, whereas /bin/echo "~" on Unix is not.
The Engine WG reviewed this issue today. As Michael Klement (@mklement0) notes above, the original PSNativePathResolution experimental feature, which implemented ~ expansion for native apps on WIndows, had a number of issues that resulted in it being removed. Good news is that there is a PR to bring back this support on Windows (~ expansion for native apps is already available on Linux and macOS).
Reacted by Michael Klement, Y.D.X., Dominic Slee, koalr and xudyang1
This issue has not had any activity in 6 months, if there is no further activity in 7 days, the issue will be closed automatically.
Activity in this case refers only to comments on the issue. If the issue is closed and you are the author, you can re-open the issue using the button below. Please add more information to be considered during retriage. If you are not the author but the issue is impacting you after it has been closed, please submit a new issue with updated details and a link to this issue and the original.
Activity
xudyang1 commentedon Jul 27, 2023
The bug was previously discussed in #10675 and #11386 and was fixed by #12386, but version 7.3.6 breaks it again.
[-]Powershell does not expand '~' for external program[/-][+]Powershell does not expand '~' for external programs[/+]237dmitry commentedon Jul 27, 2023
Could not be reproduced on either Windows (with the forward-slash path separator) or Linux. For testing used micro editor on both platforms.
xudyang1 commentedon Jul 27, 2023
Did you type
<Tab>to expand the path manually?<Tab>works, but the literal string~/../filedoes not work without<Tab>.I even tested them (string, non-string, forward-slash, backslash) with an empty
$PROFILEin pwsh, none of them worked.xudyang1 commentedon Jul 27, 2023
I downloaded pwsh from Microsoft Store. Is it possible that the bug only appears in the store version?
237dmitry commentedon Jul 27, 2023
Just tried in other editor (internal Far manager's editor
far -e) and behavior as in your issue. I thinkmicroitself parses the filepath. That's why it works. And your issue is right.mklement0 commentedon Jul 27, 2023
xudyang1, you pointed to the relevant issues, but the behavior isn't broken; rather, on Windows
~expansion was never officially implemented.PSNativePSPathResolution), which, after the discussion in Bypassing translation of PSDrive-based path arguments for external (native) executables is obscure and inadequate (PSNativePSPathResolution) #13644, was removed (Revert "ChangePSNativePSPathResolutionto not be Experimental" #13734)However, the ship hasn't fully sailed yet, given Steve Lee (@SteveL-MSFT)'s comment here:
For now:
Only on Unix do you get
~expansion, namely if the~is _unquoted and followed by/(notably, this means that something like~<username>to refer to a given user's home dir. is not supported - see Implement ~username expansion on Windows and Linux #12387)On Windows,
~expansion is not implemented (nor is automatic globbing, though the latter sensibly so).Note that the scope of #12386 was larger than just
~expansion: It tried to automatically convert paths based on PowerShell drives to file system-native drives, given that native (external) utilities don't know about PowerShell drives; e.g.temp:/foo.txtwould be converted toC:\Users\jdoe\AppData\Local\Temp\foo.txtIf done robustly - and fully doing so is ultimately impossible - PowerShell on Unix would benefit from this conversion too.
It's also worth noting that the never-introduced implementation in #12386 handled
~on Windows differently than the already-implemented~expansion on Unix:~inside"..."was - surprisingly also expanded (only'...'quoting prevented the expansion).~incmd /c echo "~"was expanded on Windows, whereas/bin/echo "~"on Unix is not.xudyang1 commentedon Jul 29, 2023
Thanks for the very detailed information! The
~expansion in Windows should be a feature request instead of a bug.rkeithhill commentedon Feb 5, 2024
The Engine WG reviewed this issue today. As Michael Klement (@mklement0) notes above, the original
PSNativePathResolutionexperimental feature, which implemented~expansion for native apps on WIndows, had a number of issues that resulted in it being removed. Good news is that there is a PR to bring back this support on Windows (~expansion for native apps is already available on Linux and macOS).microsoft-github-policy-service commentedon Sep 5, 2024
This issue has not had any activity in 6 months, if there is no further activity in 7 days, the issue will be closed automatically.
Activity in this case refers only to comments on the issue. If the issue is closed and you are the author, you can re-open the issue using the button below. Please add more information to be considered during retriage. If you are not the author but the issue is impacting you after it has been closed, please submit a new issue with updated details and a link to this issue and the original.