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

[GlitterHorn]

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

PowerShell/src/Microsoft.PowerShell.ConsoleHost/host/msh/ConsoleHostUserInterface.cs

Line 1517 in 70a74fb

private string ReadLineFromConsole(bool endOnTab, string initialContent, bool calledFromPipeline, ref string restOfLine, ref ReadLineResult result)

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]

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.

PowerShell/src/Microsoft.PowerShell.ConsoleHost/host/msh/ConsoleHostUserInterface.cs

Lines 1742 to 1749 in 70a74fb

	if (keyInfo.Key == ConsoleKey.UpArrow
	|| keyInfo.Key == ConsoleKey.DownArrow
	|| keyInfo.Key == ConsoleKey.PageUp
	|| keyInfo.Key == ConsoleKey.PageDown)
	{
	// Arrow/Page Up/down is unimplemented, so fail gracefully
	continue;
	}

[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]

dotnet/runtime#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

[AgSync-Aaron]

Bare with me, this has a point.

I use windows 10 as my daily driver and have used windows as my desktop OS of choice since windows 95. I am a Microsoft fanboy through and through. I've been a developer using Microsoft technologies since the late 90s but have avoided Powershell because it's way too verbose for my liking. A coworker of mine turned me on to it again recently an I have fell in love with the power of the object oriented-ness (is that a word?). I am now a new fan of PowerShell and once you have a hammer everything looks like a nail, am-I-right? I knew Powershell has been cross-platform for a while now so I thought I'd try it out on some of our linux machines to automate some backup processes and it seemed to be working swell.

Hot damn! I thought to myself this is great, one shell many OSes. Let's checkout the command line shell on Linux and maybe I can go with PS 100%. My glee turned to horror as I discovered that almost nothing works the same from the command-line as what it does in windows. An example is that auto-completion is very buggy with character casing and it doesn't cycle though the entries like it does on windows. PS continues to show all 148 (or whatever) entries as a giant block of text just like bash. "YUCK!" I say to myself upon this discovery, but it's easy to live with. Okay let's try something else.

it@server:~$ sudo pwsh
PowerShell 7.1.0
Copyright (c) Microsoft Corporation.

https://aka.ms/powershell
Type 'help' to get help.

PS /home/it>

Um... what user am I again? The default prompt doesn't include the username on linux where the user means everything. This is a windows-ism that shouldn't have been the default in linux. But I think that is changeable, let's move on. As I was exploring I discovered many of the keyboard shortcuts that I use in bash on linux and in powershell on windows DO NOT work for powershell in linux. This is a show stopper for me and it completely decimates my productivity. This has to be a config issue on my machine right?

Wrong.

When I discover a trail of issues going back about 2.5 years (at this point) that were closed for technicalities or because of the "it's not my problem" syndrome, I was crushed. How could a company that says it's product is cross-platform let something like this slip for over 2 years? The responses from the Microsoft team members among this trail of issues has left me dejected.

It's issues like this one that really show me how (un)dedicated Microsoft is to cross platform technologies. This ongoing behavior I see from the Powershell team has really made me question whether a future issue that affects my powershell scripts on linux may go unfixed for over 2 years. I cannot justify this with my management. It's my decision to make, but if it breaks, it's my problem to fix and I cannot trust you Microsoft.

[iSazonov]

@AgSync-Aaron You could learn how to customize PowerShell prompt and PSReadline - I guess you have no idea what the latest version of PSReadline can do.

[AgSync-Aaron]

You completely missed my point. Typical. Thank you for your snarky elitist comment.

I was telling a story of my journey of how PS command line for linux isn't perfect and I'm willing to overlook almost all of those issues. But as a product that claims to be cross-platform, it misses the boat on basic core usability. This is a show-stopper for me and clearly many other people who have commented on these series of issues that keep getting closed.

I love MS products and have made a career out of using them. I have invested a lot of my time the past couple months in learning powershell for nothing. This issue is STILL an issue 2.5 years later. The point is that I cannot trust Microsoft to be good stewards of cross-platform technology when they let something this basic go unfixed for so long.

If you'd like to have a serious conversation about Microsoft's choices here I'm game, but leave the condescending comments at the door.

[iSazonov]

Thank you for your snarky elitist comment.

Sorry, I didn't try to offend you. My efforts here are to make PowerShell better.
I just pointed out to you that you can easily customize the prompt and you will be pleasantly surprised by the capabilities of the new PSReadline 2.1. If you haven't tried it yet, I highly recommend it (see experimental features too and feedback).

This issue is STILL an issue 2.5 years later.

PowerShell capabilities are based on .Net capabilities. There are fundamental contradictions in how different OSes work. It is not easy to get over it. Net team is actively planning next 6.0 milestone and you can discuss this and vote in .Net Runtime repository so as to help them prioritize.

[AgSync-Aaron]

I accept your apology, thanks.

I had always figured there was a way to customize the prompt, I wasn't concerned about that. That was one of those imperfections that all software has and that I wasn't concerned about it. It was just a data point in my journey of Powershell discovery that I was trying to share. I was trying to share my experience and how excited I was about the prospect of having one shell and one scripting language across OSes. And how that excitement turned to disappointment over missing basic functionality. As as customer, frankly, I don't care who's team is responsible. Microsoft is my software vendor and my company pays them a lot of money.

If a member of our support team told our customer "sorry, that's not my problem" and hung up on them. We would probably lose that customer. I am trying to let Microsoft know that is how I was made to feel here by reading these issues and seeing them dismissed out of hand.

I am trying to standardize the languages that my company uses to manage our infrastructure. Microsoft says their "command-line shell" product is "cross-platform" but fails to pass some minimum requirements due to a bug. In all due respect, I cannot recommend ANY product, no matter the vendor, if what we consider basic functionality to be non-existent or buggy. I truly have honest concerns about using cross-platform powershell. This issue is over 2 years old and has been passed off to another team at Microsoft and that issue that is over FOUR years old! If I run into a bug in my critical infrastructure that is deemed to be "some other team's" fault. Am I going to have to wait two years for a fix?

[AndrewSav]

I was trying to share my experience and how excited I was about the prospect of having one shell and one scripting language across OSes. And how that excitement turned to disappointment over missing basic functionality. As as customer, frankly, I don't care who's team is responsible.

Yes, this has been an uphill battle with a lot of finger pointing, and the end result that interactive experience on Linux via SSH from Windows is in a shape, where it cannot be used as the default command prompt. This is very disappointing and frustrating. "It's PSReadline!", "No, it's PowerShell!", "No it's .NET!".

To be completely honest I'm still not convinced that it's .net because as far as I can see the .net bit works as long as it's not called from PowerShell. Yet the issue was closed. I supplied a lot of tests above but all I got in response is asking for more tests and no evidence that someone tested it and it worked differently, no steps to reproduce that were ever published.

In the end we have nothing else to do but to accept, that this is how PowerShell management chose to engage with the community. This is not satisfactory, but it is what it is.

[pencoe]

After some investigations i found that Powershell (.NET) uses ncurses, so i got Home and End working by editing Terminfo for the used $TERM (xterm for me) by

• infocmp $TERM > terminfo.src
• vi terminfo.src: look for the values of khome and kend. In my case they were \EOH and \EOF and had to be \E[H for khome and \E[F for kend. Be careful to search for this, there must be no second kxxxx entry with this code!
• tic terminfo.src

After relogin Home and End did work in pwsh as expected.

I did not look for Ctrl-Arrow, but maybe this can be fixed in a similar way... next one please ;-)

Peter

[steven-willard]

This seems to be an issue still, I am unable to get ctrl+rightArrow or ctrl+LeftArrow to work in tokenizing the advance of the cursor location.

Here is a quick pwsh function you can dump in your console to confirm the readkey value.

function Test-KeyInputOnLinux {
  $key = ""
  while ($key.Key -ne "Enter") {
    $key = [System.Console]::ReadKey()
    $key
  }
}

LeftArrow and RightArrow returned just fine. (Along with the Control Modifier)

Here is my version info, are we sure this is closed, or did I miss something?

Name Value

---

PSVersion 7.1.3
PSEdition Core
GitCommitId 7.1.3
OS Linux 4.4.0-19041-Microsoft #488-Microsoft Mon Sep 01 13:43:00 PST 20…
Platform Unix
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

[AndrewSav]

@steven-willard yep, it's still broken. If you read the issue history, it seems pretty impossible to get stuff fixed here, and this is not just this issue, it's general attitude towards the community, e.g read this or this. I personally abandoned any hope of this being fixed and moved on.

[npodbielski]

@AndrewSav @steven-willard
Yep. I've been watching this thread for 2 years, lately mainly for fun and kicks. There should be banner:

abandon hope all ye who enter here

PS on Linux is just broken and looks line maintainers want it to work this way. It would be nice to have the same CLI for both OSes but it looks line it won't be PS.
I think it would be easier to use bash via CygWin or something similar than PS on Linux.
They should be just honest and kill it instead of lie to people that is 'cross-platform'.

[pencoe]

@AndrewSav @steven-willard @npodbielski

Yep. I've been watching this thread for 2 years, lately mainly for fun and kicks. There should be banner:

abandon hope all ye who enter here

Yes, it's a pity... In this case (as far as i can tell) Powershell team and .NET team are playing "pass the buck" on each other.

PS on Linux is just broken and looks line maintainers want it to work this way. It would be nice to have the same CLI for both OSes but it looks line it won't be PS.

Which is very sad, because PS is more powerful than bash in many ways.

I think it would be easier to use bash via CygWin or something similar than PS on Linux.

No need to use CygWin since WSL and WSL2. In fact i found myself using bash on Windows more and more, because using PS on Linux isn't that easy as promised...

Peter

[yodasad]

There are too many comments in this thread... I cannot figure it out, why was the issue closed?
Home, Ctrl + Arrow are still not working in pwsh on linux.

[yodasad]

I've found a workaround: for Home and End you can use Ctrl+A and Ctrl+E respectively.

[artisticcheese]

https://twitter.com/artisticcheese/status/1485698470791028741 leave comments under tweet to tell Microsoft that we still care.

Twitter

Gregory Suvalian on Twitter

“@PowerShell_Team How come issue with broken Home, End keys not working on Linux is closed? (https://t.co/suSQ9qGTDw). Issue is still there and seems to be lying with Microsoft to fix and result of finger-pointing within MS who will do it”

[hepptho]

On Ubuntu, with PowerShell 7.2, I got the expected behavior by adding the following to my profile.ps1:

Set-PSReadLineKeyHandler -Chord Ctrl+LeftArrow -Function BackwardWord

Set-PSReadLineKeyHandler -Chord Ctrl+RightArrow -Function ForwardWord

Set-PSReadLineKeyHandler -Chord Home -Function BeginningOfLine

Set-PSReadLineKeyHandler -Chord End -Function EndOfLine

This requires the PSReadLine module to be installed, but I think it always should be by default. You can use Get-Module to check if you are unsure.

To find the profile.ps1 file, you can use the $PROFILE variable or check the docs here.

See also the docs on Set-PSReadLineKeyHandler and PSConsoleReadLine. The customization options seem extensive; it's pretty neat.

That PSReadLine doesn't offer this behavior by default appears to be intentional, see PowerShell/PSReadLine#668.
Instead (as @yodasad noted) there are Ctrl+a and Ctrl+e for beginning / end of line, as well as alt-b and alt-f for backward word / forward word. Those are Emacs conventions, apparently, but that's where I'm out of my depth.

[artisticcheese]

Set-PSReadLineKeyHandler -Chord End -Function EndOfLine

This did not work for me from command line, I'm on 7.2.1 and Ubuntu 20.04.3 LTS (Focal Fossa) and I just executed those from command line instead of $PROFILE to test

PS /home/cloudadmin> import-module PSReadLine
PS /home/cloudadmin> Set-PSReadLineKeyHandler -Chord Home -Function BeginningOfLine
PS /home/cloudadmin> Set-PSReadLineKeyHandler -Chord End -Function EndOfLine

[hepptho]

Hmm, I'm on 7.2.1 / 20.04 too, and it works directly on command line as well as in profile.ps1.

An alternative that works for me as well is:

Set-PSReadLineOption -EditMode Windows

The default EditMode on Linux appears to be Emacs, see also here for a (presumably) comprehensive list of things that should work in different edit modes. It's a nice reference.

If that also doesn't work, then the only idea I have left - and that's a wild guess - is that the keys are hijacked by something else. That sometimes happens to me with shortcuts on Linux, but it would be weird with Home and End.
You could try (if you haven't already) [Console]::ReadKey() followed by Home / End, and see what happens, and if it tells you anything.

[artisticcheese]

Issue was seen only when using Remote Desktop Manager, not present at Windows command line, otherwise solution by @hepptho works as expected

[rkeithhill]

@hepptho RE Set-PSReadLineOption -EditMode Windows - thanks for that!!! I can't believe what a dope I've been. I've been fighting the PSRL key bindings on Linux/macOS for a while now. But my main machine is Windows. For some reason, it never occurred to me to check/change the PSRL edit mode. 🤦‍♂️

[yodasad]

If that also doesn't work, then the only idea I have left - and that's a wild guess - is that the keys are hijacked by something else. That sometimes happens to me with shortcuts on Linux, but it would be weird with Home and End. You could try (if you haven't already) [Console]::ReadKey() followed by Home / End, and see what happens, and if it tells you anything.

That was already done at the beginning of this thread on Sep, 2, 2019:
#8869 (comment)

PS /home/user> [System.Console]::ReadKey()

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

PS /home/user> H

It seems like pressing the Home button results in Escape following "H" and pressing the End button results in Escape following F, so I tried to do this:

Set-PSReadLineKeyHandler -Chord Escape,H -Function BeginningOfLine
Set-PSReadLineKeyHandler -Chord Escape,F -Function EndOfLine

And it works, Home and End buttons started to work as expected, but unfortunately after that I cannot type capital "H" and "F" pressing Shift+H and Shift+F, they started to act as if I press Home and End buttons moving the cursor to the Beginning and the End of line.

[DTW-DanWard]

None of the above worked for me on Mac (PS 7.2.2) but this did - hope it helps someone else.

Create a new Terminal profile (or copy an existing) and add a Keyboard mapping for Home and End:
Home
Key: Home
Modifier: None
Send text: (using Mac keyboard, not external): CTRL+A
This should produce Send text of \001
End:
Key: End
Modifier: None
Send text: (again on Mac keyboard, assuming no other modifier key changes): CTRL+E
This should produce Send text of \005

[Clifra-Jones]

Set-PSReadLineOption -EditMode Windows

OMG! Thank you. This has been driving me nuts for months!