7.4.0 Breaking Change: Tab expansion no longer converts tildes to full paths, breaking path passing to executables on Windows

[bradwilson]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.
• Refer to the FAQ.
• Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

With versions prior to 7.4.0, pressing Tab to get completion on a path with ~ converted that path into the full path for my home folder.

Type dir ~\down and press Tab:

• In 7.3.9, it will be completed as dir C:\Users\bradwilson\Downloads\
• In 7.4.0, it will be completed as dir ~\Downloads\

For built-in commands (like dir), this is fine. For executables, this passes a path with ~ in it, which makes using such paths impossible unless the executable has its own support for mapping ~ to the home folder. For example, if I try to run notepad ~\.config\git\config, it will tell me the path isn't found; if I run notepad C:\Users\bradwilson\.config\git\config, it will open the file appropriately.

This breaks more than a decade of muscle memory expecting ~ to be translated into the correct path, as I've been using PowerShell as my shell since it was called Monad.

This appears to have been purposefully introduced in #19489. I cannot find any way to restore the old behavior short of sticking w/ version 7.3.9.

Expected behavior

PS> TabExpansion2 '~\Downloads' | select -ExpandProperty CompletionMatches

CompletionText                ListItemText        ResultType ToolTip
--------------                ------------        ---------- -------
C:\Users\bradwilson\Downloads Downloads    ProviderContainer C:\Users\bradwilson\Downloads

Actual behavior

PS> TabExpansion2 '~\Downloads' | select -ExpandProperty CompletionMatches

CompletionText ListItemText        ResultType ToolTip
-------------- ------------        ---------- -------
~\Downloads    Downloads    ProviderContainer C:\Users\bradwilson\Downloads

Error details

No response

Environment data

Name                           Value
----                           -----
PSVersion                      7.3.9
PSEdition                      Core
GitCommitId                    7.3.9
OS                             Microsoft Windows 10.0.22631
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0


Name                           Value
----                           -----
PSVersion                      7.4.0
PSEdition                      Core
GitCommitId                    7.4.0
OS                             Microsoft Windows 10.0.22631
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

[237dmitry]

In fact, when this behavior finally appeared in 7.4.0-rc.1, I was glad about it. But perhaps this is not as relevant in Windows as it is in Linux.

[bradwilson]

It's very counterproductive in Windows.

You could argue it's somewhat counterproductive in Linux as well unless every single application you use from the command line already maps ~. Many of the built-in utilities probably already have to do this, so it's less obvious when failures will materialize.

PowerShell follows POSIX (partially) and translates ~ before calling executables on Linux/macOS.

[237dmitry]

On Linux, all native applications interpret the tilde as a synonym for the user's home directory. It’s just that the command line is shorter due to the fact that it does not expand the path to the full one. The same cannot be said about Windows; most utilities probably simply will not understand what this path is.

[bradwilson]

It's worth pointing out that the Unix-y apps on Windows (for example, all the tools that ship with Git) do map ~ but will only do it if you pass Unix-y separators.

Using less version 563 (shipped with Git 2.29.2.windows.2), these work:

7.3.9: less C:\Users\bradwilson\.config\git\config
And crafted by hand: less ~/.config/git/config

But this doesn't:

7.4.0: less ~\.config\git\config results in ~.configgitconfig: No such file or directory

Since PowerShell uses the backslash when tab completing, it's creating command lines that will be broken with these Unix-y tools.

[bradwilson]

To be clear, I don't think the use of the backslash is wrong for PowerShell Core on Windows, as the Unix-y tools do work as expected with backslashes but only with fully qualified paths (which Tab completion no longer generates in 7.4.0).

[237dmitry]

I was talking specifically about Linux as the actual installed OS. Not WSL, not ported utilities, but about my main OS, which is the only one on the computer (Windows on the older notebook).

Therefore, I would like everything to remain as it is, at least on Linux.

[bradwilson]

I'm fine with the new behavior being the default, as long as I have a trivial way to opt out.

[MartinGC94]

Yes, as you've discovered this was an intentional change and there's currently no way to change the behavior. A quick workaround you can implement on your own machine is to update the tabexpansion2 function to replace the ~ character in the completion results with your home path.

Assuming this is something that people want fixed, I can think of the following solutions:

1. Permanently revert this change
2. Add a command to control the behavior, like in: WIP: Add commands for controlling completion options #19518 or if that will take too long, revert the change until such a command is added
3. Make PS resolve ~ before passing it in as an argument to native commands.

Quick and dirty tabexpansion2 workaround:

function TabExpansion2
{
    <# Options include:
         RelativeFilePaths - [bool]
             Always resolve file paths using Resolve-Path -Relative.
             The default is to use some heuristics to guess if relative or absolute is better.

       To customize your own custom options, pass a hashtable to CompleteInput, e.g.
             return [System.Management.Automation.CommandCompletion]::CompleteInput($inputScript, $cursorColumn,
                 @{ RelativeFilePaths=$false }
    #>

    [CmdletBinding(DefaultParameterSetName = 'ScriptInputSet')]
    [OutputType([System.Management.Automation.CommandCompletion])]
    Param(
        [Parameter(ParameterSetName = 'ScriptInputSet', Mandatory = $true, Position = 0)]
        [AllowEmptyString()]
        [string] $inputScript,

        [Parameter(ParameterSetName = 'ScriptInputSet', Position = 1)]
        [int] $cursorColumn = $inputScript.Length,

        [Parameter(ParameterSetName = 'AstInputSet', Mandatory = $true, Position = 0)]
        [System.Management.Automation.Language.Ast] $ast,

        [Parameter(ParameterSetName = 'AstInputSet', Mandatory = $true, Position = 1)]
        [System.Management.Automation.Language.Token[]] $tokens,

        [Parameter(ParameterSetName = 'AstInputSet', Mandatory = $true, Position = 2)]
        [System.Management.Automation.Language.IScriptPosition] $positionOfCursor,

        [Parameter(ParameterSetName = 'ScriptInputSet', Position = 2)]
        [Parameter(ParameterSetName = 'AstInputSet', Position = 3)]
        [Hashtable] $options = $null
    )

    End
    {
        $TempRes = if ($psCmdlet.ParameterSetName -eq 'ScriptInputSet')
        {
            [System.Management.Automation.CommandCompletion]::CompleteInput(
                <#inputScript#>  $inputScript,
                <#cursorColumn#> $cursorColumn,
                <#options#>      $options)
        }
        else
        {
            [System.Management.Automation.CommandCompletion]::CompleteInput(
                <#ast#>              $ast,
                <#tokens#>           $tokens,
                <#positionOfCursor#> $positionOfCursor,
                <#options#>          $options)
        }

        [System.Management.Automation.CompletionResult[]]$NewCompletionList = foreach ($Item in $TempRes.CompletionMatches)
        {
            if ($Item.CompletionText -like "*~*")
            {
                [System.Management.Automation.CompletionResult]::new(
                    $Item.CompletionText.Replace('~', $HOME),
                    $Item.ListItemText,
                    $Item.ResultType,
                    $Item.ToolTip
                )
            }
            else
            {
                $Item
            }
        }

        $TempRes.CompletionMatches = $NewCompletionList
        $TempRes
    }
}

[mklement0]

Let me provide some context:

On Unix-like platforms it is the (POSIX-compatible) shell (such as bash) that performs tilde (~) expansion, not the standard utilities (such as as ls) themselves; the same applies to globbing (wildcard expansion in filenames), among other such so-called shell expansions. You can verify this with /bin/ls --% ~ from PowerShell.

• On Unix-like platforms only, PowerShell emulates this behavior (as well as globbing) when calling external programs:

  • That is, it expands an unquoted ~ - either in isolation of if followed by/ (but not \) - to the value of $HOME.
  • As an aside: This emulation is incomplete:
    • Syntactically: Use of ` to escape ~ - /bin/echo `~- should work like /bin/echo '~' and /bin/echo "~", i.e. should suppress expansion, but currently doesn't; the inverse is true for /bin/echo ~/'foo bar', which should expand -d due to the ~ itself being unquoted, but doesn't (if you remove the space, it works): Unix: Emulation of ~ (tilde) expansion for native utilities is syntactically incomplete #20754
    • Lack of support for other users' home directories: ~user1 works in POSIX-compatible shells to refer to the home directory of user1 (verify from PowerShell with sh -c "echo ~$env:USER"), but not in PowerShell: Implement ~username expansion on Windows and Linux #12387

• On Windows, where the native shell (cmd.exe) has no such expansion features, PowerShell does not perform them.

  • Individual cross-platform utilities, especially those with a Unix heritage, may compensate for this by implementing these expansions themselves, though possibly only globbing.

---

Given the above, I propose the following variation of @MartinGC94's proposal 1:

• Revert the change on Windows only, i.e. go back to making ~ expand to the value of $HOME only there - conceivably, it could even expand to verbatim $HOME, so as to preserve the intent to express the path abstractly.

While making PowerShell emulate literal ~ expansion on argument-passing to external programs on Windows also may seem appealing, there's a greater risk of breaking existing Windows-only code that never anticipated ~ as having special meaning and therefore requiring quoting.
Also, emulating globbing too is definitely not an option, as a program expecting, say, file*.txt verbatim, then receiving multiple arguments (file1.txt file2.txt ...) could break.

[mklement0]

Taking a step back, re proposal 3 (unquoted ~ expansion on external-program argument-passing also on Windows):
It may be an option IF:

• We're not concerned about the resulting asymmetry (tilde expansion then works everywhere, globbing (filename expansion) only on Unix).
• More importantly, that the technically breaking change resulting from expanding a token-initial, unquoted ~ (either in isolation or if followed by \ or /) to the current user's home directory falls into bucket 3, i.e. is unlikely to break existing code.

[Jaykul]

For what it's worth, the problem I have is that I don't think you went far enough. I really don't want TabCompletion to replace generic values like ~ with the specific value on my computer. The same goes for or $home and $pwd and any other variable that I might have a partial path in.

How about instead of reverting a good feature, we replace the literal ~ at the front of the path with $HOME and then ... leave all the variables as variables in the path?

Since PowerShell expands variables when passing arguments to native apps, this gets us the best of all worlds:

1. Tab-completed paths work with native apps, like they used to
2. The shortest syntax like ~/Doc{Tab} still tab completes
3. Tab-completion will not make my carefully generic "$HOME/Docu{Tab}" into a script that only works on my computer.
4. Does not require potentially breaking changes to argument passing

NOTE: the catch to this is that it doesn't work if they're single-quoting the path they are tab-completing, in which case we might want to resort to the old behavior...

[MartinGC94]

I am planning on creating a PR to stop it from replacing variables with their resolved values but that's a separate issue from this.
I don't like the idea of replacing ~ with $home when tab completing because it would feel weird and confusing for anyone outside of this discussion. It also wouldn't be accurate because the home location that ~ refers to is set in the provider, while $home just points to the same static location always. See:

PS C:\Users\Martin> $Provider=Get-PSProvider FileSystem
PS C:\Users\Martin> $Provider.Home
C:\Users\Martin
PS C:\Users\Martin> $Provider.Home = 'C:\Windows'
PS C:\Users\Martin> TabExpansion2 'ls ~\' | select -ExpandProperty CompletionMatches | select -First 1

CompletionText ListItemText        ResultType ToolTip
-------------- ------------        ---------- -------
~\appcompat    appcompat    ProviderContainer C:\Windows\appcompat

PS C:\Users\Martin> $HOME
C:\Users\Martin

[rhubarb-geek-nz]

On Linux, all native applications interpret the tilde as a synonym for the user's home directory

Not exactly true. The tilde is expanded by the shell (bash, sh, zsh etc). The applications don't need to map the tilde in command line arguments. Just like on UNIX the shell expands file wildcards, so the application does not need to enumerate directories, the shell did it for them.

$ cat test.c
#include <unistd.h>
#include <string.h>

int main(int argc,char **argv)
{
        write(1,argv[1],strlen(argv[1]));
        return 0;
}
$ cc test.c
$ ./a.out ~
/home/bythesea

No interpretation by the native app.

The shell does not expand if quoted

$ ./a.out '~'
~

and

$ ./a.out "~"
~

Now that is a gotcha, because shell does expand environment variables within double quotes but not within single quotes. So shell is doing special treatment for tilde, it is not treating it simply as $HOME.

Bash Manual - Tilde-Expansion

[mklement0]

Thanks, @rhubarb-geek-nz - this has all been covered by my previous comment.

@MartinGC94: good point about the provider-specific nature of ~.

However, tab-completion was previously already provider-aware and would not expand ~ while the current location was, say, the Env: drive (for which a home location isn't defined) - that shouldn't change (or, rather: categorically leave ~ alone for all other providers).

(On a side note: On Unix-like system, when tilde expansion happens in the context of argument-passing to external programs, the current location's provider does not matter; it is always the value of $HOME that is used - which makes sense, given that the outside world only knows the file-system, and nothing about PowerShell's other providers.)

Given that among the built-in providers only the FileSystem one has a home location predefined, the slight loss of level of abstraction that comes from translating ~ to $HOME - if the FileSystem provider underlies the current location (which, however, is almost always the case, if I were to guess) - is still preferable to expanding to the full, literal home directory path.

To me, translating ~ to verbatim $HOME would be no more confusing than the old behavior of expanding to, say, C:\Users\jdoe.

That said, we could avoid this problem if we went with proposal 3, which is the cleanest solution.
Personally, that is my preference, but the question is whether the concerns raised previously prevent it.

[bradwilson]

I'm surprised by the number of people who are suggesting that I'm asking for a new feature rather than lamenting of the removal of an old feature. The conversations about "confusions for users" is exactly why we're here: a "breaking" change was made and me (a user) is confused about why it was done and how I can undo it. This was clearly a feature I counted on and would like to have back, even if it is no longer the default behavior.

I would be fine with tab completion of ~ into $HOME (under the assumption that it would be evaluated before being sent to executables). It's also worth noting that in both 7.3.9 and 7.4.0 if I type dir $HOME/Down and press Tab it gets expanded to C:\Users\bradwilson\Downloads\ or /home/bradwilson/Downloads/ (depending on OS).

(I just deleted a bunch of stuff because I realized that echo in my pwsh examples was using the echo alias and not /usr/bin/echo, so my examples were incorrect.)

[mklement0]

I'm surprised by the number of people who are suggesting that I'm asking for a new feature

I don't see anyone suggesting that.

The - intentional - change that was introduced in 7.4.0 discussed here has a real downside on Windows (as you've discovered) - lack of ~ resolution when calling external programs - and solving that is what the discussion is about.

And it sounds like you'd be happy with the new behavior as long as the latter problem is solved.

As for variable references in paths: as @MartinGC94 has stated, the plan is to also change the behavior in order to preserve variable references during tab-completion in a future PR.

However, if we go with the replace-~-with-verbatim-$HOME approach, that change would already need to include the preservation of variables, so as to prevent the scenario where iterative tab-completion then results in expansion of $HOME to its value.

[jhoneill]

@MartinGC94 I think this really needs to be rolled back to previous behaviour. But thanks for sharing the modified tabexpansion2

I've created a gist https://gist.github.com/jhoneill/322a77199350c76a5785f5406ea97bac with what I think is a more effective version although I'm not sure about modifying $inputScript and then changing the Replacementlength after calling CompleteInput()

However it does some things which I had in an argument completer previously and had to be bound to whatever cmdlet/function arguments I thought would benefit - a bit tedious

• ~ [tab] expands ~ to $userProfile and tab expands as if I had typed c:\users\james\ or whatever
• ~~ [tab] cycles through AdminTools, ApplicationData, CDBurning, CommonAdminTools, CommonApplicationData, CommonDesktopDirectory, CommonDocuments, CommonMusic, CommonOemLinks, CommonPictures, CommonProgramFiles, CommonProgramFilesX86, CommonPrograms, CommonStartMenu, CommonStartup, CommonTemplates, CommonVideos, Cookies, Desktop, DesktopDirectory, Favorites, Fonts, History, InternetCache, LocalApplicationData, LocalizedResources, MyComputer, MyDocuments, MyMusic, MyPictures, MyVideos, NetworkShortcuts, Personal, PrinterShortcuts, ProgramFiles, ProgramFilesX86, Programs, Recent, Resources, SendTo, StartMenu, Startup, System, SystemX86, Templates, UserProfile, Windows
• ~~My [tab] cycles through MyDocuments, MyMusic, MyPictures, MyVideos
• ~~MyDocuments\ [tab] with the trailing \ expands ~~MyDocuments to C:\users\james\documents
• ~~MyDocuments\p [tab] with the trailing \ expands ~~MyDocuments to C:\users\james\documents\p and cycles through things beginning with P
• .... [tab] expands every . after 2 to ..\ so cd ... [tab] cycles through directories 2 levels up.
• . [tab] and .. [tab] no longer need the trailing \
• ^ [tab] expands ^ to the PowerShell profile directory

I saw a way to fix #20765 at the same time so I've put that in at the end

Gist

tabExpansion2.Ps1

GitHub Gist: instantly share code, notes, and snippets.

[mklement0]

To provide what I think is the proper framing for this issue:

• Preserving abstractions in the user input - i.e. an initial ~, as well as variable references such as $HOME or $env:SystemRoot - is definitely the way forward, both for concision and portability and, secondarily and debatably, to minimize visual disruption.

  • If there are associated challenges, let's try to address those - the ~-related one is the only one I'm aware of, and concrete solutions have been proposed - let's try to come to a shared understanding of what the best way forward is.

• Separately - if there's a need - provide the old resolve-everything-to-literals behavior as an opt-in.

  • A secondary challenge is that user will tend to look for such configurability to PSReadLine, even though it is technically related to the PowerShell engine itself - the same goes for Add an option to disable automatic parenthesis insertion #20765

[237dmitry]

this really needs to be rolled back to previous behaviour

On Windows

[kilasuit]

Can the change that caused this issue to become present please get linked to for traceability and also so that we can then also look to update changelogs, docs and any other supporting material as needed.

[jhoneill]

this really needs to be rolled back to previous behaviour

On Windows

I prefixed that with "I think", I'm a very infrequent user of Linux and and non Windows users may have a different view to users of Windows Given there is another issue about the behaviour of ~/path with native Linux tools I can see possible advantages to rolling back there too but that's not where I do my work so others are better places to say.

I will try frame something as "O'Neill's nth law" along the lines of "things which get into a product because they seemed like a good idea at the time to a developer are a disproportionate cause of problems". 7.4 seems to have a few of those, and I'd put colourization in the same group.

[rhubarb-geek-nz]

I will try frame something as "O'Neill's nth law" along the lines of …

Also known as The road to hell is paved with good intentions

[237dmitry]

non Windows users may have a different view to users of Windows Given there is another issue about the behaviour of ~/path with native Linux tools I can see possible advantages to rolling back there too

As a Linux and Windows user, I believe that using shortcuts like ~/path on Linux makes sense, as any utility or application will interpret it correctly as a system-wide designation for the user's home directory. The same cannot be said for Windows, so here we definitely need to return the previous behavior.

This is my personal opinion, like everything else I write here, because I'm just an user who cares about the future of PowerShell. Sorry that sometimes my statements seem unclear or even rude - poor knowledge of the language and often incorrect translation are the reason for this. I respect you all and value your opinion.

[mklement0]

@kilasuit:

• The PR is already linked in the initial post (Improve path completion #19489)
• The original issue by @lzybkr that inspired the ~ part of the PR (with the variable-preservation part yet to come) is: Tab completion should not replace ~ or variables #5350
• The release notes and changelog only contain the following abstract description: "Improve path completion (#19489)"
• It looks like about_Tab_Expansion wasn't updated to mention the change.

---

@237dmitry, thank you for your clarification that there may be a language barrier and for your expression of respect.

Just to recap the previous clarification: it isn't utilities (external programs) that interpret ~, it is the (POSIX-compatible) shell that up front resolves ~ to the value of $HOME and passes the result to utilities.

PowerShell (sensibly) chose to emulate this behavior - selectively, for calls to utilities (external programs) only - but currently only on Unix-like platforms.
It could equally choose to do that on Windows too, which would solve the issue at hand.
Again, it comes down to whether we think this would break anything.

---

To resume the framing debate:

• It is clear that a change must be made.

  • Concrete solutions have been proposed that preserve the spirit of the new behavior, namely here and here.

• Reverting to the old behavior is one option - possibly selectively on Windows.

  • It's important not to mistake a personal preference for the old behavior for a compelling reason that reverting is the only solution.
  • If there are reasons (other than habit) to oppose the new behavior separately from the fixable problem it introduced, please state them as such.
  • If the new behavior is kept and fixed, offering the old behavior as an opt-in is then an option.

[237dmitry]

Again, it comes down to whether we think this would break anything

I think this dilemma will be successfully resolved without affecting the already running version on the Unix platform. As you noted in another thread, there are problems with quotation marks, but quoting only part of the path is not that common in everyday interactive practice.

[tats-u]

then you have inconsistent behaviour.

That makes sense.
It is not as good as I had thought only to revert the behavior of PSReadLine to 7.3.

[AGDownie]

Aren't we losing sight of the original issue?

The issue was that Powershell 7.4.0 broke the long-established tab completion of the tilde character in interactive sessions.

My understanding is that the OP is specifically concerned about what happens when the tab key is pressed in an interactive terminal session, not how it's interpreted in pre-existing scripts, nor on the nature of whether Powershell is Posix compliant or if it should parrot the behaviour of miscellaneous UNIX-like shells.

To put it simply, users like me want the tilde to expand to the full $HOME path in front of our eyes when we press the tab key after entering a path with the tilde in it. We're not interested in the behaviour of the tilde in scripts, nor how the tilde is interpreted in an argument to a cmdlet or native executable. We just want our tilde tab completion back, even as a non-default option.

Surely that can't be too difficult, given that we've already been provided a workaround tabexpansion2 function from MartinGC94 in the post earlier: #20750 (comment)

[bradwilson]

@AGDownie With zero interaction from the PowerShell team thus far, I'm tempted to just close this issue (given the vitriol some people insisted on spewing into it) and just re-open it again.

[AGDownie]

In fact I believe @MartinGC94 is involved in the development, having added some commits on the relevant PR (#19489), and posted perhaps the most useful contribution on this issue. So perhaps we may see progress some time soon. I wouldn't recommend closing the issue and re-opening a new one, as that will probably count against getting anything done.

It would be nice to see some further response from the PowerShell team, but in the meantime I'm just using my own variation of MartinGC94's "quick and dirty" workaround tabexpansion2 function to restore the required functionality. It works fine, but it would be preferable if it was at least available as a Set-PSReadlineOption customisation, or even more preferable if it was restored as the default option!

[MartinGC94]

In fact I believe @MartinGC94 is involved in the development

Sort of. I'm a regular contributor, but I'm not a member of any WG or the actual PS team so my level of influence is the same as you: I can submit my thoughts/ideas through comments and PRs but that's it. If someone with actual power makes a decision on this I would be happy to create a PR for it though.

[AGDownie]

Thanks, @MartinGC94. Point taken. But I expect that as a contributor your thoughts/ideas carry more weight than mine as a simple user.
Anyway, thanks for your tabexpansion2 script: it has helped to restore my equilibrium after finding PowerShell was broken.

[mklement0]

This will be small consolation, given the time frame:

Runtime expansion of unquoted ~ at the start of arguments passed to external programs is now also coming to Windows, thanks to @domsleee's PR, as experimental feature PSNativeWindowsTildeExpansion, presumably first available in the next preview, which would be v7.5.0-preview.2

This means that - if it even ever becomes a stable feature (which is to be hoped for) - the first stable version it would land in is v7.5, which is months away.

While that won't bring the old behavior back, at least calls to external programs using tab-completed ~-prefixed paths would work again.

[bradwilson]

@mklement0 Actually that PR is bad (as-is) because it doesn't resolve ~ when it's quoted, and tab expansion with paths with spaces in them will automatically quote (at least it currently does in 7.4.1, even on Linux where such behavior is outright broken, and will soon be broken on Windows with 7.5.0-preview.2).

Maybe there's a parallel feature for 7.5.0 that stops quoting paths during tab expansion and just escapes them instead...?

[bradwilson]

Actually it looks like just trying to hand-escape paths in Linux is also broken in PowerShell.

It does appears at the moment that ~ support is very random and mostly broken everywhere.

[mklement0]

That ~ isn't expanded when quoted is by design, which is how it already works on Unix-like platforms (notably also in POSIX-compatible shells, whose tilde expansion feature is being emulated).

However, there are indeed two separate bugs (as previously mentioned) with respect to quoting:

• 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

While unfortunate, they only affect paths that contain spaces.

[Gonkers]

This has totally broken my workflow.... microsoft/vscode#146116
code ~\repos\my-repo

[pfmoore]

This change has been unexpected and frustrating to me - I didn't spot any information about it happening, and spent some time assuming that I was doing something wrong when my various tools started breaking. I on;y found this issue when I searched for "how do I force Powershell to expand tilde when completing", thinking it was something I'd forgotten to configure.

I like the idea of retaining ~ and variables, but expanding them when running an external program. It would still be a slight problem for occasional cases (where I type part of a filename, tab-complete it, and then copy the resulting expanded name into something like an email, or a program that doesn't parse tilde or variables the same way as Powershell does), but I could live with that.

However, I think the problems with the current approach are sufficiently annoying (on Windows, at least) that something needs to be done short term - if the long-term solution can't be delivered quickly, IMO there's a good case for reverting the change in behaviour for ~.

As a partial stopgap, I've hacked together the following key binding:

Set-PSReadLineKeyHandler -Chord Ctrl+m -ScriptBlock {
    [Microsoft.PowerShell.PSConsoleReadLine]::SelectShellBackwardWord();
    [Microsoft.PowerShell.PSConsoleReadLine]::Cut();
    [Microsoft.PowerShell.PSConsoleReadLine]::Insert((Resolve-Path (Get-Clipboard)).Path)
}

It's a mess at the moment - I've never tried to create a custom key handler before - but if anyone can suggest how to make it more robust, it would be useful as a workaround. Problems with this version are that it overwrites the clipboard, and it leaves part of the command line selected. If there were "Get selected text" and "Move cursor to end of current selection" functions, this would fix the issues, but I couldn't find anything like that in the documentation 🙁

[mklement0]

@pfmoore: @MartinGC94 has posted a temporary fix in the form of a modified TabExpansion2 function, which you can add to your $PROFILE: expand the Details section in the following comment: #20750 (comment)

[bradwilson]

Sorry, everybody, but I'm closing this issue. I've been nearly half a year with tons of discussion (and way too many heated words), and never once has anybody from the PowerShell team come to say anything about this.

It's done and over, and we're not getting it back.

[microsoft-github-policy-service]

📣 Hey @bradwilson, how did we do? We would love to hear your feedback with the link below! 🗣️

🔗 https://aka.ms/PSRepoFeedback

Microsoft Forms

[mklement0]

@bradwilson, as much as I can relate to the I'm-gonna-take-my-ball-and-go-home sentiment, the community is better served by keeping this issue open.

The fact that the issue is labeled WG-NeedsReview presumably:

• (a) would keep this issue open indefinitely (unless closed explicity)
• and (b) at least implies that at some point there'll be an official adjudication.

In short: I encourage you to reopen this issue, if only to - for now - increase its visibility to future users.

[bradwilson]

You're welcome to open a new issue and even link back here for "history". I have zero confidence that this one will yield any attention. 5 months is long enough to wait for even a simple acknowledgement.

[Gonkers]

You're welcome to open a new issue and even link back here for "history". I have zero confidence that this one will yield any attention. 5 months is long enough to wait for even a simple acknowledgement.

Thanks for sticking with it as long as you did. I've been affected by other hot-button issues that the pwsh team have refused to acknowledge. This is nothing new for this team.

fwiw, I just downgraded to https://github.com/PowerShell/PowerShell/releases/tag/v7.3.12

[jhoneill]

Sorry, everybody, but I'm closing this issue. I've been nearly half a year with tons of discussion (and way too many heated words), and never once has anybody from the PowerShell team come to say anything about this.

Sadly that's the way the PowerShell team has gone. Not engaging, and indulging in "Developer Driven Development".

[microsoft-github-policy-service]

📣 Hey @bradwilson, how did we do? We would love to hear your feedback with the link below! 🗣️

🔗 https://aka.ms/PSRepoFeedback

Microsoft Forms

[bradwilson]

Thank you, thank you, thank you @SteveL-MSFT for the fix! And thanks to @jaredpar for getting it attention.

[jaredpar]

That gif is amazing.

[jhoneill]

And just when you give up, someone engages and does the right thing :-) Tip-of-the-hat to you Steve.