SHIFT+ENTER set to AddLine - line gets executed instead of a new line being added 2.0.0-beta1

Environment data

I think the template might need to be updated:

PS version: 6.0.1
PSReadline version: 2.0.0-beta1
dir : Cannot find path '/System32/cmd.exe' because it does not exist.
At line:12 char:17
+         "os: $((dir $env:SystemRoot\System32\cmd.exe).VersionInfo.Fil ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : ObjectNotFound: (/System32/cmd.exe:String) [Get-ChildItem], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand

os:
PS file version:

That said, here are the answers:

PS version: 6.0.1
PSReadline version: 2.0.0-beta1
OS: macOS High Sierra
PS file version: `(dir $pshome\pwsh).VersionInfo.FileVersion` yielded nothing

Steps to reproduce or exception report

on macOS with the PSRL 2.0.0-beta1:

> gci #then hit SHIFT+ENTER

gci is executed, rather than a new line being generated.

If there’s an unclosed brace, however, AddLine works. Ex:

> & { #now hit SHIFT+ENTER or just ENTER

a new line appears - it doesn’t execute the code.

> & {
>>

[mklement0]

Here’s the list of usable chords with Set-PSReadlineHandler on Unix-like platforms; compiled as of PowerShell Core 7.0.0-rc.1:

• Any others are likely not supported.
• The limitations stem in part from how terminals work in the Unix world, with additional limitations imposed by the CoreFx [Console] API - see bottom section; @lzybkr has started the conversation about fixing the latter in this CoreFX issue.

<kbd>Control</kbd>-based chords:

Chord	Comment
Control-a
Control-b
Control-c	Caveat: handler not effective while a command is running
Control-d	Caveat: users may expect this to end interactive input
Control-e
Control-f
Control-g
Control-k
Control-l
Control-n
Control-o
Control-p
Control-q
Control-r
Control-s
Control-t
Control-u
Control-v
Control-w
Control-x
Control-y
Control-z	Caveat: if running via bash, preempted by the latter’s send-to-background feature

Note:

• You can add Alt to these cords.
• You cannot add Shift - using <kbd>Shift</kbd> is effectively ignored (behaves as if it hadn’t been pressed).
• Note the absence of punctuation-based chords.

---

<kbd>Alt</kbd>-based chords:

Chord	Comment
Alt-a … Alt-z	English letters only
Alt-A … Alt-Z	<kbd>Shift</kbd> variations - do not use Alt-Shift-a (Alt-Shift-A would be redundant)
Alt-1 … Alt-9	Caveat: <kbd>Shift</kbd> variations not supported; they trigger even if you don’t press Shift, and don’t trigger when you do.
Alt-/	Curiously, this particular symbol seems to work, unlike others; no <kbd>Shift support</kbd>

Note:

• Adding Control limits you to the chords available for <kbd>Control</kbd>-based chords.
• Note the absence of punctuation-based chords (except for /).

---

<kbd>Shift</kbd>-only-based chords:

Except for:

• redefining uppercase letters
• and the combinations with modifiers Alt and Control listed above

you cannot define Shift-based key handlers on Unix.

Notably, handlers such as Shift-Enter or Shift-Backspace are not supported.

---

Background Information

The fundamental restrictions - which come from most Unix-like OSs running xterm-emulation terminal programs are:

• <kbd>Control</kbd>-based chords are in effect limited to a subset of the 33 well-defined chords of caret notation - plus a few effective (but presumable accidental) aliases (see bottom); the ^ symbol is known as the caret and represents the <kbd>Control</kbd> key; for instance, ^A represents the chord <kbd>Control+A</kbd> (strictly speaking, it is the uppercase A, but at least for letters it doesn’t matter whether <kbd>Shift</kbd> is held down or not):

  • In short, these well-defined chords map onto the 32 C0 ASCII-range control characters starting with (0x0) NUL / ^A through (0x1f) US / ^_, plus (0x7F) DEL / ^?) and programs running inside that terminal see only the resulting control character.

• From a terminal’s perspective, there are no <kbd>Alt</kbd>-based chords at all, but most modern terminal programs translate <kbd>Alt+{char}</kbd>-based chords (with some terminals on an opt-in basis, as on macOS) into <kbd>Esc</kbd>, <kbd>{char}</kbd> sequences, and programs running inside that terminal see only the resulting sequence.
  That’s why, in the bash world, for instance, readline definitions are expressed in terms of the latter.

• Generally, only characters are reported, not key states, so that there’s no separate information about whether a given modifier key was (also) held down, notably not <kbd>Shift</kbd>.

• Additionally, a given terminal program itself may have key bindings for <kbd>Control</kbd>-based and/or <kbd>Alt</kbd>-based chords, which may preempt attempts by programs running inside these terminals to bind them.

---

On top of that there are the shortcomings in CoreFX’s [Console]::ReadKey() implementation on Unix-like platforms, which affect PSReadLine too:

^{Note: I’m using lowercase letters in the chord representations below to indicate chords not involving the <kbd>Shift</kbd> key.}

On Unix-like platforms, instead of letting programs see the translation of key chords the same way as described above - which may be a single ASCII control character or an <kbd>Esc</kbd>, <kbd>{char}</kbd> sequence - CoreFX retranslates that into a chord, as you would see it on Windows, but only for some chords:

<kbd>Control</kbd>-based chords

• <kbd>Control</kbd>-based chords that translate into control characters that have dedicated keys are reflected as such in the .Key property (but the .KeyChar property also contains the corresponding control character):

  • Note:

    • These mappings do not work on Windows - there, the chord as pressed is reported.
    • However, _even on Unix you must define PSReadLine key handlers for these chords in terms of the resulting .Key property value, not the actual chord keys (e.g., Set-PSReadLineHandler 'Escape' ..., not Set-PSReadLineHandler 'Control-[' ...)

  • <kbd>Control+i</kbd> a.k.a ^I, which is control char. HT, corresponds to the <kbd>Tab</kbd> key

  • <kbd>Control+h</kbd> a.k.a ^H, which is control char. BS, corresponds to the <kbd>Backspace</kbd> key.

  • <kbd>Control+[</kbd> a.k.a ^[, which is control char. ESC, corresponds to the <kbd>Escape</kbd> key.

  • <kbd>Control+j</kbd> a.k.a ^J, which is control char. LF (0xA) is mistakenly conflated with <kbd>Control+m</kbd> a.k.a ^M, which is control char. CR: both result in the .KeyChar property containing `r (i.e., CR) and .Key containing Enter:

    • ^J should have .KeyChar value (`n), its .Key property should be J, and its .Modifier property should be Control.

  * Somewhat ironically, the behavior is correct on _Windows_.
  

• <kbd>Control</kbd>-based chords that do not work:

  • <kbd>Control+z</kbd> works in principle, but may be preempted by bash, if pwsh happened to have been launched from it; note that <kbd>Control+z</kbd> has special meaning in traditional shells (not the terminal emulators themselves): in cmd.exe, it signals EOF during interactive input (copy con ...); in bash, it suspends the currently executing program and sends it to the background. * Curiously, if not preempted, direct use of [Console]::ReadKey() ignores the chord, but PSReadLine does see it.

  • The remaining punctuation-based chords do not work, either:

    • <kbd>Control+@</kbd> … seen as just @
    • <kbd>Control+\ </kbd> … seen as just \
    • <kbd>Control+]</kbd> … seen as just ]
    • <kbd>Control+^</kbd> … seen as control char. 0x1e, which prints as ^^; you can’t define a PSReadLine key handler for that.
    • <kbd>Control+_</kbd> … seen as just _
    • <kbd>Control+?</kbd> … seen as <kbd>Backspace</kbd>(!)
    • Curiously, direct use of [Console]::ReadKey() passes the control character correctly in the .KeyChar property (except for ^@, where it is 0), but fails to populate the .Key and .Modifier properties (both 0, except for ^?, where it is Backspace)

  • Redefining <kbd>Control+c</kbd> (probably not a good idea) isn’t effective while a command is running; you get the default cancel-the-running-operation functionality then (if run [console]::TreatControlCAsInput = $true first, you lose the cancel-the-running-operation functionality altogether). In other words: you can only redefine <kbd>Control+c</kbd> for command-line editing.

<kbd>Alt</kbd>-based chords

CoreFX tries to translate <kbd>Esc</kbd>, <kbd>{char}</kbd> sequences , as reported by the terminal emulator, back into <kbd>Alt+{char}</kbd>-based chords, but not consistently:

• (English) letter and digit-based <kbd>Alt</kbd>-based chords, including uppercase variants, are correctly translated, and behave as on Windows.

• By contrast, symbol-/punctuation-based <kbd>Alt</kbd> chords (e.g., <kbd>Alt+'</kbd>) do appear to arrive as their raw <kbd>Esc</kbd>, <kbd>{char}</kbd> sequences, which [Console]::ReadKey() and therefore PSReadLine cannot handle: [Console]::ReadKey() only reports the <kbd>Esc</kbd> keypress, not the following {char}.

  • Curiously, <kbd>Alt-/</kbd> is an exception.

<kbd>Shift</kbd>-only-based chords:

As stated, Unix terminals report characters, not key states, so there is no separate information about the state of the <kbd>Shift</kbd> key.

CoreFx infers that <kbd>Shift</kbd> was pressed for uppercase letters, and puts the value Shift in the .Modifiers property of the Sytem.ConsoleInfo instance returned, but in no other cases.

Therefore, defining handlers for chords such as Shift-Enter is fundamentally unsupported - they never trigger on Unix.

---

To test if chords work on Unix-like platforms, run something like the following from PowerShell:

# Alt-
'a'..'z' + '1'..'9' | % {
  Set-PSReadLineKeyHandler "alt-$_" ([scriptblock]::Create("Write-Host -NoNewline 'alt-$_!'"))
}

# Ctrl- (not all of them will work)
'a'..'z' | % {
  Set-PSReadLineKeyHandler "ctrl-$_" ([scriptblock]::Create("Write-Host -NoNewline 'ctrl-$_!'"))
}

[lzybkr]

I’ll need help on stuff like that - it looks like it differs from Linux and I don’t have access to a Mac.