Powershell: Home, End, Ctr+Arrow don't work (Arch/Linux 4.20)

[ClairelyClaire]

Steps to reproduce

1. type something at the command prompt.
2. Try to use Home or End to navigate the text.
3. Try to use Ctrl+Arrow to navigate the text.
4. Repeat 1-3 with text editor, e.g. nano.
5. Observe.

Expected behavior

Home, End, and Ctrl+Arrow should behave as in bash - go to beginning of text, end of text, and skip words left and right.

Actual behavior

• Home prints ~
• End prints ~
• Ctrl+Arrow does nothing

Environment data

I used yaourt on Arch to install.

Name                           Value
----                           -----
PSVersion                      6.2.0-preview.2
PSEdition                      Core
GitCommitId                    6.2.0-preview.2
OS                             Linux 4.20.0-arch1-1-ARCH #1 SMP PREEMPT Mon Dec 24 03:00:40 UTC 2018
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[lzybkr]

This is most likely not a PowerShell problem.

Try [Console]::ReadKey() then type Home. Output should look like:

KeyChar  Key Modifiers
-------  --- ---------
        Home         0

I'm guessing it won't, in which case the problem could be with:

• The setting for $env:TERM
• .Net Core
• The terminfo database

[rkeithhill]

@lzybkr This is what I see on Ubuntu 18.04 (when I ssh in from Windows PS 7 and then start pwsh):

09-01 21:23:44 3> [Console]::ReadKey()

KeyChar    Key Modifiers
-------    --- ---------
       Escape         0

This is a real bummer as it makes moving around a command line painful. Here's the term info:

09-01 21:29:01 4> dir env:term*

Name                           Value
----                           -----
TERM                           xterm-256color

[rkeithhill]

I'm pretty sure this is a PowerShell problem and probably not a PSReadLine problem. FWIW, I only see this when I SSH into our RedHat or Ubuntu build machines. I don't see this issue in Bash but I do see it when I then start up pwsh. I also see it when I start pwsh with pwsh -noprofile -noni which, I think, doesn't load PSReadLine. I see this when using both conhost and WindowsTerminal. And it is somewhat maddening TBH.

This shows the issue on 6.2.2 but I just tried PS7-preview.3 and it behaves the exact same way.

[npodbielski]

Is there any chance to fix this. I would even try to do it myself since bash is maddeningly hard to do even easiest thing but I cannot swap pwsh because it lacks that little things like arrow keys support :)

[iSazonov]

/cc @daxian-dbw @SteveL-MSFT If the problem is in .Net Core we need to get a fix before .Net Core 3.1 LTS.

@rkeithhill Could you please make the test with simple C# app which only output Console.ReadKey()?

[SteveL-MSFT]

This seems most likely an issue in .NET Core. Agree with @iSazonov that a simple C# console app to repro would be ideal.

[AndrewSav]

I'm slightly preplexed by these comments. This is an issue that is stabely reproducible in powershell and it does not seem to be and obvious way to reporoduce it in a C# console app. Also it does not seem that there is any evidence is given that it is not a Powershell issue.

Could guys please clarify your line of thinking?

[SteveL-MSFT]

@AndrewSav when PSReadLine is not involved as shown in @rkeithhill's example, pwsh has a simple ReadLine that doesn't do any translation of keys. It is whatever the .NET API returns.

[AndrewSav]

@SteveL-MSFT thank you for this. Will I be too far off if I conjecture, that these services (Home, End, Ctr+Arrow ) are not provided by ReadLine itself, but by something else, for example on windows by console host?

[AndrewSav]

I tested the issue with pwsh 6.2.3 on Windows and Ubuntu Linux 18.04. I also tested it with a simple ReadLine console program. Here are the results.

pwsh 6.2.3

| | Home/End | Ctrl-Arrows |
| -------------- | ------------- | ------------- |
| Windows 10 | Works | Works |
| Ssh | Does not work | Does not work |
| gnome-terminal | Works | Does not work |
| xfce4-terminal | Works | Does not work |

.net core 3.0.100 program with Console.ReadLine

| | Home/End | Ctrl-Arrows |
| -------------- | ------------- | ------------- |
| Windows 10 | Works | Works |
| Ssh | Does not work | Does not work |
| gnome-terminal | Does not work | Does not work |
| xfce4-terminal | Does not work | Does not work |

Console program text

using System;

namespace readline
{
    class Program
    {
        static void Main(string[] args)
        {

            Console.WriteLine("Hello World!");
            string hello = Console.ReadLine();
            Console.WriteLine(hello);
        }
    }
}

In bash it works in any combination.

[iSazonov]

PowerShell uses ReadConsole P/Invoke on Windows that is power method.
On Unix it emulates a line editor.
Possible fix for local host could be in https://github.com/PowerShell/PowerShell/blob/70a74fbfc891b3b9e8657d314860622cc97b20b8/src/Microsoft.PowerShell.ConsoleHost/host/msh/ConsoleHostUserInterface.cs#L1517

Perhaps @PaulHigin could add more about ssh scenario.

I already opened API request in CoreFX repo https://github.com/dotnet/corefx/issues/36175 long ago.

[SteveL-MSFT]

I was able to repro this with ssh.exe we ship in Win10. However, after using just the ssh.exe from https://github.com/PowerShell/Win32-OpenSSH/releases/tag/v8.1.0.0p1-Beta, it works as expected. So the issue appears to be in our Win32 port of ssh.exe. Work is happening to update the ssh in Windows, but it'll take time to be released. For now, you can just replace the ssh.exe from our GitHub release.

GitHub

PowerShell/Win32-OpenSSH

Win32 port of OpenSSH. Contribute to PowerShell/Win32-OpenSSH development by creating an account on GitHub.

[AndrewSav]

@SteveL-MSFT did you see my matrix above? When I tested it with ssh on windows I tested with:

• ssh that comes with windows
• putty
• mobaxterm
• one from www.mls-software.com

It was exhibintg the problem on all of them, in addition Ctrl-Arrows did not work even without ssh.

I'll try and re-test with 7 but while I'm doing this, are you sure, we are not jumping the gun closing it?

It does not seem reasonable to request people use one certain flavour of SSH when so many are avialable.

[SteveL-MSFT]

@AndrewSav in the cases where your .NET Core 3 app doesn't work, it would have to be an issue in the .NET Runtime repo

[AndrewSav]

@SteveL-MSFT which version of powershell did you test this with?

[AndrewSav]

Okay, after some testing it does not seem to be fixed.

PowerShell 7.0.0-rc.1 running on ubuntu 18.04

| | Home/End | Ctrl-Arrows |
| -------------- | ------------- | ------------- |
| Win32-OpenSSH OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5 | Does not work | Does not work |
| Win32-OpenSSH OpenSSH_for_Windows_8.1p1, LibreSSL 2.9.2 | Works | Does not work |
| Putty 0.73 | Does not work | Does not work |
| MobaXterm 12.4 | Does not work | Does not work |
| git-bash 2.24.1.windows.2 | Works | Does not work |
| www.mls-software.com 8.0p1 | Works | Does not work |

The ctrl-arrows do not seem to work at all via ssh. Home/End work for some clients but not for other.
bash (unlike powershell) works everywhere

Do you think there is an issue with powershell not suporting these?

[AndrewSav]

@AndrewSav in the cases where your .NET Core 3 app doesn't work, it would have to be an issue in the .NET Runtime repo

How come that this would be an issue with .net runtime for some cases but would not be for others?

E.g. console app readline does NOT work for home/end over, say, with Win32-OpenSSH OpenSSH_for_Windows_8.1p1, LibreSSL 2.9.2 but powershell does. so how come that issues with .net runtime do not affect this case but affect others?

[SteveL-MSFT]

PowerShell (specifically PSReadLine) uses [console]::ReadKey(). That may differ from the ReadLine() api that you have as your test app. Try this instead:

using System;

namespace readline
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("ReadKey:");
            var key = Console.ReadKey();
            Console.WriteLine(key.Key.ToString());
        }
    }
}

[AndrewSav]

Thank you, but wether they are different or not, most of I said is still valid and the questions still stand...

[iSazonov]

I think we should reopen.

@AndrewSav Could you please share test matrix for (1) Windows and Linux, (2) Home/End, (3)Right and Left Arrows (Ctrl-B/Ctrl-F), (4) Different terms/apps, (5) for both [Console]::ReadKey() and [Console]::ReadLine() ?

[AndrewSav]

@iSazonov I'm not sure how to present 5 dimentional matrix in text, I'm happy for suggestions. I think for ReadLine you already have coverage above, I don't see what's missing. For the ReadKey, results are indeed interesting.

using System;

namespace readline
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello World!");
            while (true)
            {
                ConsoleKeyInfo k = Console.ReadKey();
                Console.WriteLine($"Key:{k.Key}, Modifiers: {k.Modifiers}");
            }
        }
    }
}

Here are the obesrvations:

https://docs.google.com/spreadsheets/d/1a5wzdwwOmjsEZxedX3xb6bKhaI7sR5g0Or8iiGxCo34/edit?usp=sharing

This is from Windows Client (as per first column of the table) to Ubuntu 18.04 server.
dotnet --version is 3.0.102

[iSazonov]

@AndrewSav Thanks for sharing your tests!

I see ReadKey() returns wrong sequences.
I guess it is .Net Core _feature_. .Net Core internally load term database and probably uses it in ReadKey() for input transformations. You could try to find that term is detected and used in every case and either add new line in term database or modify exist one.

Perhaps it is here https://github.com/dotnet/runtime/blob/4f9ae42d861fcb4be2fcd5d3d55d5f227d30e723/src/libraries/System.Console/src/System/ConsolePal.Unix.cs#L891

[AndrewSav]

@iSazonov ctrl-arrows do not work regardless ;(

[iSazonov]

You could debug the code
https://github.com/PowerShell/PowerShell/blob/70a74fbfc891b3b9e8657d314860622cc97b20b8/src/Microsoft.PowerShell.ConsoleHost/host/msh/ConsoleHostUserInterface.cs#L1718-L1739

[SteveL-MSFT]

@AndrewSav your results are showing that the dotnet app isn't reading some key combinations correct, right? Seems we should be discussing this in the dotnet/runtime repo unless I'm misunderstanding something.

[iSazonov]

@SteveL-MSFT I guess .Net Core can not find these terminals in term database and can not do right translation.

[AndrewSav]

@SteveL-MSFT Ctrl-Arrows do not work in powershell via SSH, it does not look like there is problems with Ctrl-Arrows in .net core. Could you please test independently and share your results?

Also: if powershell aims to be a comfortable replacement for bash on linux I feel that powershell needs to address the Home/End problem regardless of what .net core does. Find a way to make it work. Many people including me, voiced that they wish they could switch to powershell from bash if not for this problem.

[SteveL-MSFT]

@AndrewSav I did a test on Ubuntu 18.04 ssh to itself. Was able to use Ctrl+LeftArrow within PS7 (I tested it by binding that chord to MenuComplete function in PSReadLine).

[iSazonov]

@AndrewSav Since you have repo on C# please open consulting issue in .Net Core runtime repository and share link here.

[artisticcheese]

Why this issue is closed when it's obviously still an open problem.

[iSazonov]

@artisticcheese See https://github.com/PowerShell/PowerShell/issues/8869#issuecomment-575481777 above - it shows that it is .Net Core issue.

[artisticcheese]

Is there an open issue with .NET core we can follow for resolution? I did not find it mentioned.

[rkeithhill]

OpenSSH 8.1.0.0p1-Beta ssh run from a PS 7 GA console (not Windows Terminal) to Ubuntu 18.04 Bash - All key combos of Home/End, Arrows and Ctrl+Arrows works. As soon as I start pwsh (v7 GA) on Ubuntu, Home/End continues to work as do arrows but Ctrl+Arrows do not work. Also, and very infuriatingly, Esc does not work so clearing the input line requires pressing End and then Ctrl+u.

And this experience is even worse and frankly a bit embarrassing:
OpenSSH 8.1.0.0p1-Beta ssh run from a PS 7 GA console (not Windows Terminal) to Windows 10 running PS 7 GA and OpenSSH 8.1.0.0p1-Beta - Ctrl+Arrows and Esc work but Arrows do NOT and neither does Home/End. Arrow keys that don't work makes the Windows to Windows SSH line editing and history recall experience awful - almost unusable.

Update: this last scenario works WAY better with Windows Terminal - as in everything seems to work. Maybe there should be documentation on the many issues doing SSH (Windows to Windows) with the PowerShell console? RE the first scenario, the results are the same with Windows Terminal. Ctrl+Arrows don't work and neither does the Esc key.

[artisticcheese]

My attempt to replace bash with PSCore as default shell in Ubuntu come to screeching halt due to this bug, now not only I'm back to bash as default shell but don't use any powershell at all. For some it's minor issue and for some it's a dealbreaker.

[npodbielski]

Watching this issue for like a half a year and its funny and sad at the same time. I was watching in disbelief when maintainers were asking this one reporter to jump through hoops preparing matrices and the likes with keys behaviour when this is so easy to reproduce. And they blamed external library and marked closed.
There is a name for that kind of behaviour in my language. It is kinda hard to translate but the closest would be: pushologic adapdet - meaning when someone pushes problem away from himself most likely pointing someone else responsible. Very popular in government agencies and among bureaucrats. Culture changes, language changes, country and timezone but basics of human behaviours does not. not my problem summarizes this issue resolution.

[iSazonov]

@artisticcheese @npodbielski Do you ready to work on the issue? If yes, current conclusion is that the issue is not in PowerShell code but perhaps in .Net Core code. So please open new issue in .Net Core Runtime repo and work with .Net Core team. If no, please don't speculate - this do not add value in the discussion.

[npodbielski]

I certainly could. Probably it would be fun to work on such a big OS project given I would get few pointers, how to start and etc. But I want to picture you my perspective first.

I did not spend much time using PS and most of it is on Ubuntu lately, but still I observed few strange behaviors:

1. PS sometimes shows garbage instead of usual welcome string (current dir and '>'). I think it is connected to not clearing screen correctly after terminating some long running job. You can still work as usual, it do not brake anything, but it does looks strange.
2. Searching through history and reusing some command by clearing some of it often causes strange changes in colors of already printed characters - most notably removing some command entirely can cause to '>' char at the end of welcome string to i.e. became red. It also do not brake shell but also looks strange.
3. Pasting larger chunks of text looks funny because it pastes char by char instead of all of it at once so you paste it and wait till PS will be done with it thinking how and why it is implemented like this.
4. Keys issue, that you are surely already familiar with.

So PS is a shell and what shell does is basically printing text on screen and reading keyboard. And from my own experience PS is shitty with both for now. Having that in mind why would I invest my own spare time in this project? It is bad with it is most basic functionality.

Would you i.e. bought a car that does not start like a 10% percent of the time? Or does not turn right? If this would be some other linux shell I would probably, just uninstall it and forgot about it right away. But it is from Microsoft so you do expect something more right? Certainly it is not some OS project maintained by 1 guy in a basement? Such big company have money and resources to do it better, right? Well for now it do not looks like it.

You say that this discussion is counterproductive. For me it is not counterproductive but it was escalated to the topic how maintainers threats users and other people that want or might be able to help. Should not maintainers want project to succeed? I think they should. Does closing such obvious issue drives you toward such a goal? I do not think so. Then why you did it? Why I should fix it if looks like you (well not you specifically but all people involved in this project) does not care really?

In commercial projects I worked on, usually this works like this:
User or business reports an issue.

1. User or business reports an issue.
2. You check this out and it turns out that it is caused by some external library.
3. You look for help on their support page, bug reporting software etc for possible solutions workaround.
4. You inform your users that problem was escalated and you are waiting for third party.

Doing otherwise would looks like I am hard to work with and ultimately could cause me being fired if it would occur often or issue would be really major for the users and I would refuse to help them.

Sometimes when I am looking for some tool and it is open source I skim through source code and issues to see if it is maintained and how open, helpful and active is community. IMHO PS is maintained actively but it is not open nor helpful.
This do not inspire confidence.

In readme it states:

Welcome to the PowerShell GitHub Community! PowerShell Core is a cross-platform (Windows, Linux, and macOS).

For now it do not looks like it is cross-platform. If you are asking me for contribution I am asking what is real priority of this project. It do not looks like Linux support is most important. There was recently 7.0 release. Seventh version of PS and it still can't handle basic navigation keys.

I would certainly switch to PS as my default shell on Ubuntu since IMHO bash is bad for scripting, but PS is painful to use, so I am sticking to bash as shell and PS for some more advanced scripting (so I do not have to use it directly).

Having that in mind why would I contribute? After all from this issue users are left with impression 'if you have an issue with our project, well... you are alone with that. Good luck fixing it yourself'.

Do this post is counterproductive? I may certainly look like this for you, but in my opinion this is me contributing.

Please change your approach to users, change way how you support this project.
Please re prioritize.
Please be more helpful and supportive.

Then maybe people like me will be more likely to contribute to the project.
For now reason says: do not.

[artisticcheese]

I would create an issue if I understood fully what I need to write and where. I just lack that understanding. So choice for me was either spend unknown amount of time trying to figure out where to write and what to do to create issue or just don't use PS as daily driver. I just chose latter since it's easier since I have no pressing need to have PS as default shell (thought I would like it like I have it on Windows).

[iSazonov]

@artisticcheese Never mind. Please continue monitor the issue, try workarounds and share your experience from your scenarios.

@rkeithhill I found some docs for Windows-OpenSSH https://github.com/PowerShell/Win32-OpenSSH/wiki/TTY-PTY-support-in-Windows-OpenSSH
Could you please look the document and try the recommendations?

GitHub

PowerShell/Win32-OpenSSH

Win32 port of OpenSSH. Contribute to PowerShell/Win32-OpenSSH development by creating an account on GitHub.

[AndrewSav]

@artisticcheese See #8869 (comment) above - it shows that it is .Net Core issue.

I still beleive that Ctrl-Arrows is not a .Net Core issue, since I cannot reporoduce it with .Net Core. Yet, it's easily reproducible with powershell.

[iSazonov]

@AndrewSav Can you add more info about Ctrl-Arrows? Do you test with and without PSReadline? Did you try [Console]::ReadKey() and command line?

[AndrewSav]

@iSazonov [Console]::ReadKey() returns Control LeftArrow and Control RightArrow as expected, but Ctrl-Arrows do nothing on the command line.

I'm not sure about PSReadline, how do you test with or without it? I installed powershell following instructions here and tested with it.

[rkeithhill]

Load pwsh like so pwsh -noprofile -noninteractive to test without PSRL.

[AndrewSav]

It does not work either way, but differently. When runnning pwsh Ctrl-Arrows do nothing (do not move cursor), when running pwsh -noprofile -noninteractive they seem to act as Arrow keys without Ctrl.

[iSazonov]

Ctrl-UpArrow/DownArrow does not implemented in PowerShell on Unix. You could assign a handler for these keys in PSReadline.
https://github.com/PowerShell/PowerShell/blob/70a74fbfc891b3b9e8657d314860622cc97b20b8/src/Microsoft.PowerShell.ConsoleHost/host/msh/ConsoleHostUserInterface.cs#L1742-L1749

[artisticcheese]

Slightly offtopic.
What is Crtl-Up/Down arrow is supposed to do in Powershell?

[AndrewSav]

Ctrl-UpArrow/DownArrow does not implemented in PowerShell on Unix

Yep, this is what this issue is about. Why is this closed?

[lzybkr]

https://github.com/dotnet/runtime/issues/802 tracks issues with Console.ReadKey on Linux.

[AndrewSav]

It does not appear that this one is relevant. Firstly in never mentions ctrl-arrow keys, and secondly they seem to be reported as expected by Console.ReadKey on Linux.

[lzybkr]

@AndrewSav - got it - you should open an issue in https://github.com/PowerShell/PSReadLine for the lack of Ctrl+LeftArrow and Ctrl+RightArrow support in Emacs mode. Better yet, you could submit a PR - it's a trivial fix.

GitHub

PowerShell/PSReadLine

A bash inspired readline implementation for PowerShell - PowerShell/PSReadLine