Repository navigation
windows: '~' Home reference bug #20761
Description
Prerequisites
- Write a descriptive title.
- Search the existing issues.
- Make sure you are able to repro it on the latest released version
- Refer to the FAQ.
- Refer to Differences between Windows PowerShell 5.1 and PowerShell.
Steps to reproduce
when i update PowerShell in my windows 11 workstation version to 7.4.0 below is version
$ $PSVersionTable
Name Value
PSVersion 7.4.0
PSEdition Core
GitCommitId 7.4.0
OS Microsoft Windows 10.0.22621
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
when i use the ~ to refer my work home, that may conjunct with current path; at old version that method like resolve ~ to $HOME environment variation.
Hope can resolve this problem. thanks
Expected behavior
ps> more ~\test
1Actual behavior
# xxxxxx @ SHC5CG33131WZL in ~\AppData\Local\Temp\tmphcnstt.tmp [18:41:39]
$ more ~\test
Cannot access file C:\Users\xxxxxx\AppData\Local\Temp\tmphcnstt.tmp\~\testError details
No response
Environment data
Name Value
---- -----
PSVersion 7.4.0
PSEdition Core
GitCommitId 7.4.0
OS Microsoft Windows 10.0.22621
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0Visuals
No response
Reacted by YANG Qi and Adam
Activity
yuanjs-0108 commentedon Nov 23, 2023
it actually use more.com in powershell, and it still not work in such like
code.exe(vscode) --diff
This kinds of external command that need path as parameters.
So have u fix it or add this feature?
Or I need to take an issue to vscode to remain them to fix this problem ? 😃
237dmitry commentedon Nov 23, 2023
If you about powershell.exe you are confusing a function with an application
mklement0 commentedon Nov 23, 2023
To summarize:
On Windows,
~is only recognized by the provider cmdlets, such asGet-ContentandGet-ChildItem(there it refers to the home location of the provider underlying the current location; for theFileSystemprovider, that is$HOME, i.e. the current user's home directory (same as$env:USERPROFILEon Windows).External programs - such as
more.comorcode- do not understand~and - unlike on Unix-like platforms - on Windows PowerShell performs no translation of~to the value of$HOMEbehind the scenes.In Windows Powershell
more ~\testhappened to work, because theremorerefers to a PowerShell function by that name (run$function:moreto see its body) that wrapsmore.comand passes the file-path argument toGet-Content, which, as stated, does understand~.Because this function was removed in PowerShell Core,
more ~\testnow passes~\testdirectly tomore.com, which therefore fails (becausemore.comdoesn't understand~).~-prefixed path would instantly convert~to the value of$HOME- this was changed in 7.4.0; again, see 7.4.0 Breaking Change: Tab expansion no longer converts tildes to full paths, breaking path passing to executables on Windows #20750237dmitry commentedon Nov 23, 2023
Nice summary of several recent topics.
tats-u commentedon Dec 6, 2023
In Bash in WSL:
Bash expands
~at the beginning as an appropriate home directory, but PowerShell will not at all.This specification of PowerShell must be changed.
~is not converted if quoted.tats-u commentedon Dec 6, 2023
This means pwsh for Windows has intentionally disabled this feature.
$env:USERPROFILEis tooooooooooo loooooooooong to be typed frequently.tats-u commentedon Dec 6, 2023
Unlike Unix, we do not have to expand
~userbecause we do not have to care about user profile folders of other users in Windows.Also Bash does not expand
~notexistinguser.It is not affected because it does not start with
~.tats-u commentedon Dec 6, 2023
I forgot Windows Server.
~useris necessary even in Windows. However, it will be difficult to take users whose names contain space into account.tats-u commentedon Dec 6, 2023
~useris not expanded in cmdlets and the tab completion 7.3 or prior in Windows. Current user profile~has much higher priority than other users' ones.mklement0 commentedon Dec 6, 2023
Implementing
~<username>expansion is the subject of this long-standing feature request:As for usernames with spaces (which are rare, as is
~<username>use in general, but there's no reason not to fully emulate the tilde expansion of POSIX-compatible shells): The spaces need to be`-escaped, e.g.,~jane` doeAs for bringing the emulation of tilde expansion to Windows (for native programs only, as on Unix): In addition to the discussion in the previously linked issue, there is a also a PR, though it would initially be just an experimental feature:
mklement0 commentedon Dec 6, 2023
I agree that
~<username>isn't terribly useful, rhubarb-geek-nz, and personally I don't miss it.But, as stated, there's no reason not to fully emulate the tilde expansion features of POSIX-compatible shells.
Good point re the different behaviors in different shells - I was only aware of the Bash behavior, where only a verbatim username works: This is in line with the POSIX spec (you can infer it from the fact that tilde expansion is prescribed to occur before parameter expansion).
This, and the prevalence of Bash, point to the fact that
~<username>is primarily an interactive convenience, such as typingls ~j<tab>, which expand tols ~jdoeand therefore refers to userjdoe's home directory.Thus, one option is to limit PowerShell to emulating the POSIX-compliant / Bash behavior and allow verbatim usernames only.
To also support variable-based usernames, the logic would have to be (as implied by the usual quoting rules of POSIX-compatible shells), with
$user = 'jdoe':~jdoe,~$user,~"$user"should expand tojdoe's home dir. (but only - as usual - if either followed by no additional characters or an unquoted/)'~jdoe',"~$user")This would make it a bit more useful, because it makes it suitable for use in scripts too, as you note.
I suggest continuing this discussion in #12387, if necessary.