Powershell: Shift+Spacebar does not add a space in console

[reaching-for-libra]

Steps to reproduce

At the powershell prompt, hold the shift key and type the spacebar

Expected behavior

Add space, advance cursor

Actual behavior

No action taken

Environment data

Running on Windows 7. pwsh.exe started with -noprofile switch

Name                           Value
----                           -----
PSVersion                      6.1.0-preview.3
PSEdition                      Core
GitCommitId                    v6.1.0-preview.3
OS                             Microsoft Windows 6.1.7601 S
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0, 5.0, 5.1.10032.0, 6.1.0-preview.3}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[iSazonov]

I can not repo.

[lzybkr]

I believe this is a PSReadLine issue and the proposed fix is here.

[webash]

This didn't used to be an issue; why has it been introduced as one? How did this regression pass testing? Surely nobody releases shift to type a space when they've just (and will again) use it!

[lzybkr]

This is fixed in 2.0.0-beta3.

@webash - if you're interested in improving the existing regression tests (which do have excellent branch coverage already, but can't really be exhaustive), feel free to contribute.

[JamesHarrisonBaggs]

Thanks all! I can confirm that the following resolved the issue for me:

1. Open PowerShell as admin
2. Run install-module -name powershellget -force
3. Restart PowerShell (as admin)
4. Run install-module -name psreadline -allowprerelease -force
5. Restart PowerShell again

[mcdonamw]

It's near the end of 2019. I just had to perform the same steps above on my 1903 build. Is this ever going to make its way into the base Windows/Powershell image or are users supposed to run this -prerelease fix?

[iSazonov]

@mcdonamw In the days MSFT team hard works on PSReadline (see PSReadline repo). I hope we get new release soon with high quality. Please feedback in PSReadline repo if you see any issues.

[SteveL-MSFT]

We have ported targeted fixes in PSRL to Windows PowerShell. Plan is to check in PSRL 2.0.0 final to Windows PowerShell but we're only at beta5 right now.

[webash]

What does that mean for getting into standard Windows builds? Will it eventually be included in a Windows build or a Windows Update?

[iSazonov]

Current version in Windows is Beta2. Latest version is Beta6. I think we will get a new version with CU sometime later.

[SteveL-MSFT]

We don't plan to ship via Windows Update. You can always install latest from PSGallery. Once PSRL2 reaches GA (targeting Nov), then we'll check that into the next version of Windows.

[iSazonov]

@SteveL-MSFT No updates for Enterprise versions too? Current PRRL is broken and doesn't work with Russian chars.

[benallred]

Adding the following to my profile fixes this problem for me.

Set-PSReadLineKeyHandler Shift+Spacebar -ScriptBlock { [Microsoft.PowerShell.PSConsoleReadLine]::Insert(" ") }

[vexx32]

@benallred if I recall correctly this issue was resolved in PSReadLine itself as well; if you update to the latest prerelease of that module, the additional key handler shouldn't be necessary. 🙂

Good to have the interim fix for folx who can't update the module yet though, so thanks!

[benallred]

Yes, I saw that. In this case I felt more comfortable with a key handler than a prerelease version. This was the first thread on this subject I found that helped me know I wasn't crazy when my spacebar stopped working so I thought I'd share what I discovered.

[vrtsds]

ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Script 2.0.0 PSReadline {Get-PSReadLineKeyHandler, Get-PSReadLineOption, Remove-PSReadLineKeyHandler, Set-PSReadLineKeyHandler...}

Shift+Space still doesn't do anything.

[vexx32]

You still need to update PSReadline as I mentioned, and it's possible whatever terminal you're using is also intercepting it, which PowerShell can't do anything about if that's the case.

[thw0rted]

Hi, it's the middle of 2020 and this is still happening on the built-in Powershell in a fully updated Windows Home box. That's bananas. Do I need a separate ticket to get this fixed in, y'know, the Powershell that every user already has?

[vexx32]

The builtin version of PowerShell on Windows 10 is locked to 5.1.

There are no further fixes being pushed via that route, with the sole exception of absolutely critical security-related issues. You can file UserVoice / Windows Feedback items to ask after that kind of thing, but it's not managed from this repository at all, and from what I've heard small items like this aren't really on the table for being backported to windows 10.

As I mentioned, you can try upgrading the PSReadLine module on affected boxes as that has seemed to be the main source of the problem, but as far as I'm aware there's no intention to change the preinstalled versions of modules - both PSReadLine and Pester have been version 2 and 3.x respectively for years now on the in-box install, and both modules have a _lot_ of changes (Pester is up to version 5.x in public release) that are not being propagated back to the in-box installations; you need to upgrade those modules explicitly.

[bbseal]

Windows 10 is the current (and supposedly last) version of Windows, so it seems odd to say that a known issue will never be fixed and that a component that it uses will never be updated.

[vexx32]

Have you tried updating the PSReadLine version at all?

[iSazonov]

I unload PSReadline module because even the latest version does not work well with Russian characters :-)
And I'd prefer to get new version from WU. :-)

[thw0rted]

I just want to make sure it's clear that "update this component manually" is not actually a fix for a lot of users. I spend a lot of my time on boxes where a) I don't have admin permissions and b) the network does not reach out to the real internet. There should be a path to fixing this in some release of Powershell, eventually, and if there are "no plans" to pack in new versions of Powershell with new Windows releases / updates, ever, that needs to be advertised loudly anywhere that users are being advised to use it. Why would I bother learning Powershell if it's stagnant?

[vexx32]

PowerShell isn't stagnant. The _default_ installation of PowerShell on Windows is, though.

[vrtsds]

That's an interesting philosophical approach. Allow me to offer another one: for most purposes, the only real version of PowerShell is the version people _have_. If _that_ isn't being updated, then PowerShell is stagnant.

Anyway, I'm a little puzzled why I'm supposed to upgrade past version 2.0.0 of the module for a bug that was reportedly fixed in a beta release over a year prior to that? I don't want to make a configuration change like this to my system unless I understand _exactly_ why I'm doing it.

[vexx32]

The version preinstalled on Windows 10 systems _is_ a beta version. Couldn't tell you which exactly (you'll need to inspect the module's PrivateData field for that information, Windows PowerShell won't tell you it's a pre-release version).

You can be philosophical all you want. That's the present reality, whether or not it's one we like.

[vrtsds]

I'm not sure if I can describe how stunned I am right now.

So, Windows 10 having a stagnant PowerShell library by default, okay. That's not _great,_ but it's, y'know, a _normal_ amount of not great. I can at least understand why they might decide to do that.

But to find out some of these modules they aren't updating are _beta_ versions? Combined with the equally stunning news that PowerShell's UI doesn't _tell_ you when you've got a beta module?

I mean, at that point, the fact that one of these preserved-in-amber betas has a known and fixed bug that gaslights users into thinking they're bad at typing, well, that's just icing.

Anyway, updating the module fixed it. The -prerelease parameter isn't needed anymore, of course.

[thw0rted]

Oh Lord, I just realized that we're now having the Python 2.7 / 3.0 conversation. Welp, I wasn't expecting this when I woke up today.

[bbseal]

Hang on, according to Steve Lee, they do want to replace 5.1: https://devblogs.microsoft.com/powershell/the-next-release-of-powershell-powershell-7/

And then they're planning on merging .NET Core and .NET into .NET 5: https://visualstudiomagazine.com/articles/2019/05/06/net-5.aspx

So it sounds like once they get all this stuff on the same footing, we should be on a path to sanity.