Skip to content

Powershell does not expand '~' for external programs #20031

Closed

Description

@xudyang1

Prerequisites

Steps to reproduce

PS: ~ > pwsh --version
PowerShell 7.3.6
PS: ~ > cd .config/nvim
PS: .config/nvim > nvim ~/.bashrc # or code ~/.bashrc
  • 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

Visuals

No response

Activity

  1. added
    Needs-TriageThe issue is new and needs to be triaged by a work group.
    on Jul 27, 2023
  2. xudyang1 commented on Jul 27, 2023

    @xudyang1
    Author

    The bug was previously discussed in #10675 and #11386 and was fixed by #12386, but version 7.3.6 breaks it again.

  3. changed the title [-]Powershell does not expand '~' for external program[/-] [+]Powershell does not expand '~' for external programs[/+] on Jul 27, 2023
  4. 237dmitry commented on Jul 27, 2023

    @237dmitry

    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
    
  5. xudyang1 commented on Jul 27, 2023

    @xudyang1
    Author

    Did you type <Tab> to expand the path manually? <Tab> works, but the literal string ~/../file does not work without <Tab>.

    I even tested them (string, non-string, forward-slash, backslash) with an empty $PROFILE in pwsh, none of them worked.

  6. xudyang1 commented on Jul 27, 2023

    @xudyang1
    Author

    I downloaded pwsh from Microsoft Store. Is it possible that the bug only appears in the store version?

  7. 237dmitry commented on Jul 27, 2023

    @237dmitry

    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.

  8. mklement0 commented on Jul 27, 2023

    @mklement0
    Contributor

    xudyang1, you pointed to the relevant issues, but the behavior isn't broken; rather, on Windows ~ expansion was never officially implemented.

    However, the ship hasn't fully sailed yet, given Steve Lee (@SteveL-MSFT)'s comment here:

    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.
  9. xudyang1 commented on Jul 29, 2023

    @xudyang1
    Author

    Thanks for the very detailed information! The ~ expansion in Windows should be a feature request instead of a bug.

  10. added
    Issue-BugIssue has been identified as a bug in the product
    WG-ReviewedA Working Group has reviewed this and made a recommendation
    and removed
    Needs-TriageThe issue is new and needs to be triaged by a work group.
    on Feb 5, 2024
  11. added
    Issue-Enhancementthe issue is more of a feature request than a bug
    and removed
    Issue-BugIssue has been identified as a bug in the product
    on Feb 5, 2024
  12. rkeithhill commented on Feb 5, 2024

    @rkeithhill
    Collaborator

    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).

  13. microsoft-github-policy-service commented on Sep 5, 2024

    @microsoft-github-policy-service
    Contributor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Issue-Enhancementthe issue is more of a feature request than a bugResolution-No ActivityIssue has had no activity for 6 months or moreWG-Enginecore PowerShell engine, interpreter, and runtimeWG-ReviewedA Working Group has reviewed this and made a recommendation

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions