No "up" key in Komsole after upgrade to Leap 15.4

English Applications
#1

Hi all,

upgrade from 15.3 to 15.4 ran super smooth, both on my desktop OpenSUSE box @home and my VPS. With all repos active during upgrade as even recommended nowadays, bloody stable, cool.

One small and somewhat funny bug left: After upgrading, I’ve no “up” key in Konsole anymore. Made it somewhat difficult to scroll in / lopp through bash history, but found that ctrl-up works, so existing workaround. Opened already a bug for it: https://bugzilla.opensuse.org/show_bug.cgi?id=1200942

My question here is: Where are these keystroke bindings defined? Seems to be not bash itself, as “up” in xterm works fine, only KDE/Plasma’s Konsole hat this issue.

Thanks for any hints,
Michael

#2

I am running 15.4 (after upgrading from 15.3 a week ago), use KDE. When I use Konsole, the “Arrow-Up” key shows me the bash history.

If that is what you mean, then it seems not to be a general problem.

#3

It may well be that, this is an issue with “Readline” –

  1. Check that, the differences between ‘~/.inputrc
    ’ and ‘/etc/skel/.inputrc’ are, only those things which you really, really, had to customise … 1. Check that, ‘/etc/inputrc
    ’ is really the version supplied by the package “aaa_base” … 1. Ditto ‘/etc/inputrc.keys
    ’ …

Further information is available here – <https://wiki.archlinux.org/title/Readline#History> – and, here – <https://wiki.archlinux.org/title/Bash#History>.

  • The Bash man page has a section named “READLINE” – there’s also some information related to command line History and Readline there but, the ArchWiki articles are more concise and readable …
#4

Thanks for answering !!!

I’ve never said that this might be a general problem, as I’ve tested before with a newly created Linux user on my 15.4 box, which does not have this issue. I only said that it was working without any change by me since 13.1. At least not any change I’m aware of between last boot with 15.3 and first boot with 15.4.
That’s why I’m asking for hints where these keystrokes are defined, to compare with the well working profile. Too much init files for me, esp. if there are still folders from kde4 existing…

Found in Konsole the option (all labels translated from German) “Settings”/“Edit current profile”, and below this “Keyboard”. Set to “Standard (XFree 4)” per default. AFAI remember never changed by me. If you click on “Edit”, there’s a “test area”.
Which shows me “Up-Shift+Ansi-AppCursorKeys-AnyModifier” as Input when pressing “up” (or as you called it "Arrow-Up). And “\E[A” as Output.
“Down-Shift+Ansi-AppCursorKeys-AnyModifier” as Input for fine working “down”/“Arrow-Down” with “\E[B” as Output.

Trying with “cat -” in Konsole I’m getting

^[[B

as output for “down”/“Arrow-Down” and absolutely nothing for up/Arrow-up.

Strange as it is: When typing up/Arrow-Up, this keystroke “blocks” any next keystroke, e.g. typing ‘"up"aaa’ results in ‘aa’. first “a” lost in space.

reg. 1: Both ~/.inputrc and /etc/skel/.inputrc are of SAME content, ~/.inputrc created/last modified in 2014, /etc/skel/.inputrc in 2018. For sure not manually by me, and both files don’t have a single, not commented/active line.

reg. 2 and 3: Both files are from March 14th this year

**#** ls -l inputrc* 
-rw-r--r-- 1 root root  2402 Mar 14 10:48 inputrc 
-rw-r--r-- 1 root root 20265 Mar 14 10:48 inputrc.keys

and there are now .rpmnew or similar files for them in /etc

No idea how to find out if these are “really, really” the files provided by pkg aaa_base, any hints?

Regarding your general READLINE hint: If I use “workaround” key ctrl-up/Ctrl-Arrow-Up, resulting in

^1;5A

, Bash History works absolutely fine.

#5

You could use rpm --verify to check if files of a package have been modified


>rpm -qf /etc/inputrc 
aaa_base-84.87+git20180409.04c9dae-3.57.1.x86_64 
> rpm -qf /etc/inputrc.keys  
aaa_base-84.87+git20180409.04c9dae-3.57.1.x86_64 
> rpm --verify aaa_base-84.87+git20180409.04c9dae-3.57.1.x86_64 
.......T.  c /etc/mime.types 
.M....G..  g /var/log/lastlog

If the content of a file is modified the md5 checksum is different and rpm will display a …5… for that file.

#6

Strange – also a German language system here –

  • Konsole → Keyboard → Standard (XFree 4) → Test area:
    Up Arrow: “Up-Shift+Ansi-AppCursorKeys-AnyModifier” → «\E[A»
    Down Arrow: “Down-Shift+Ansi-AppCursorKeys-AnyModifier” → «\E[B» [li]Konsole → Keyboard → Linux-Konsole (my standard keyboard selection) → Test area:
    Up Arrow: “Up-Shift+Ansi-AppCursorKeys” → «\E[A»
    Down Arrow: “Down-Shift+Ansi-AppCursorKeys” → «\E[B» [/ul]
 > cat -A -
^A^B^C
 >

Where “^A” is the Up Arrow – “^B” is the Down Arrow and “^C” is …

The “inputrc” files in /etc should contain the following:


 > grep -iE '\A|\B' /etc/inputrc /etc/inputrc.keys 
/etc/inputrc:"\e\eA":  previous-history
/etc/inputrc:"\e\eB":  next-history
/etc/inputrc:"\eA":    previous-history
/etc/inputrc:"\eB":    next-history
/etc/inputrc.keys:"\eA":       previous-history
/etc/inputrc.keys:"\eB":       next-history
/etc/inputrc.keys:"\eA":      "\e"
/etc/inputrc.keys:"\eB":      undo
/etc/inputrc.keys:"\ea":               history-search-backward
/etc/inputrc.keys:"\eb":               history-search-forward
/etc/inputrc.keys:"\e\ea":     history-search-backward
/etc/inputrc.keys:"\e\eb":     history-search-forward
/etc/inputrc.keys:"\e\eA":     history-search-backward
/etc/inputrc.keys:"\e\eB":     history-search-forward
 >

Do you have something defined in the KDE Plasma Shortcuts which is conflicting with the “Up/Down Arrow” in Konsole?

#7

Thanks for the “rpm” hints!

I’m getting the same rpm --verify output line for /var/log/lastlog. Which is to probably be expected on a working system :slight_smile:
So no changes in any inputrc files.

#8
  • Tried with “Linux Konsole” already also, no change
  • Tried your cat -A
 > cat -A - 
^**The “inputrc” files in /etc should contain the following:

grep -iE ‘[A|[B’ /etc/inputrc /etc/inputrc.keys
/etc/inputrc:"\e\e[A": previous-history
/etc/inputrc:"\e\e[B": next-history
/etc/inputrc:"\e[A": previous-history
/etc/inputrc:"\e[B": next-history
/etc/inputrc.keys:"\e[A": previous-history
/etc/inputrc.keys:"\e[B": next-history
/etc/inputrc.keys:"\e[[A": “\e”
/etc/inputrc.keys:"\e[[B": undo
/etc/inputrc.keys:"\e[a": history-search-backward
/etc/inputrc.keys:"\e[b": history-search-forward
/etc/inputrc.keys:"\e\e[a": history-search-backward
/etc/inputrc.keys:"\e\e[b": history-search-forward
/etc/inputrc.keys:"\e\e[A": history-search-backward
/etc/inputrc.keys:"\e\e[B": history-search-forward


[/QUOTE]


- same output here, as these files are unchanged by me:

grep -iE ‘[A|[B’ /etc/inputrc /etc/inputrc.keys
/etc/inputrc:"\e\e[A": previous-history
/etc/inputrc:"\e\e****": next-history
/etc/inputrc:"\e**[A[/b]": previous-history
/etc/inputrc:"\e****": next-history
/etc/inputrc.keys:"\e**[A[/b]": previous-history
/etc/inputrc.keys:"\e****": next-history
/etc/inputrc.keys:"\e**[A[/b]": “\e”
/etc/inputrc.keys:"\e****": undo
/etc/inputrc.keys:"\e**[a[/b]": history-search-backward
/etc/inputrc.keys:"\e****": history-search-forward
/etc/inputrc.keys:"\e\e**[a[/b]": history-search-backward
/etc/inputrc.keys:"\e\e****": history-search-forward
/etc/inputrc.keys:"\e\e**[A[/b]": history-search-backward
/etc/inputrc.keys:"\e\e****": history-search-forward





[quote="dcurtisfra,post:6,topic:152373"]

Do you have something defined in the KDE Plasma Shortcuts which is conflicting with the “Up/Down Arrow” in Konsole?
[/quote]


[/QUOTE]

Checked all Shortcuts. I've had next/previous shortcuts for Amaraok, default, deleted themnow  as not needed, no change. 
Also there are shortcuts for "Navigation", "next/previous list element". No idea what "navigation" refers to. 
No custom / own shortcuts for up or down. I've only defined meta-e for Dolphin as I'm working too much on Windows :D

Just to clarify: up/Arrow-Up Key works in all other (KDE/Plasma) Apps, like Kwrite, LibreOffice, Firefox (while writing this reply :)) Only Konsole has this issue now in 15.4.******************************************
#9

I thought you could create profiles with custom keyboard settings in konsole, but I never did that. Just a guess is there maybe a *.keytab file in .local/share/konsole/ ?

#10

@michael_of:

Then, let’s take a look at what the keyboard is actually sending with “xev -event keyboard” –

  • What we need is, only this – and not the rest of what may be logged:

KeyPress event, serial 28, synthetic NO, window 0x9600001,
    root 0x6ca, subw 0x0, time 9922735, (2949,1909), root:(2949,2007),
    state 0x10, **keycode 111** (keysym 0xff52, **Up**), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x9600001,
    root 0x6ca, subw 0x0, time 9922831, (2949,1909), root:(2949,2007),
    state 0x10, keycode 111 (keysym 0xff52, Up), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 28, synthetic NO, window 0x9600001,
    root 0x6ca, subw 0x0, time 9923919, (2949,1909), root:(2949,2007),
    state 0x10, **keycode 116** (keysym 0xff54, **Down**), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x9600001,
    root 0x6ca, subw 0x0, time 9924039, (2949,1909), root:(2949,2007),
    state 0x10, keycode 116 (keysym 0xff54, Down), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

The output of “localectl” could possibly also be of value.

Is the box a Laptop?

If a Desktop with a USB Keyboard, does unplugging and then reinserting the USB connector change the behaviour?

Does forcibly re-installing the “konsole”, “konsole-part” and “konsole-part-lang” packages change the behaviour?

Do you have any changes in “~/.xbindkeysrc”?

  • Does “xbindkeys_show” indicate anything strange?
#11

No.

find ~ -name "*.keyt*" -print 2>/dev/null[FONT=monospace]

didn’t return anything.

[/FONT]

#12

Seems to be the same/totally similar:


KeyPress event, serial 28, synthetic NO, window 0x1400001, 
    root 0xeb, subw 0x0, time 26983726, (158,0), root:(158,29), 
    state 0x10, keycode 111 (keysym 0xff52, Up), same_screen YES, 
    XLookupString gives 0 bytes:  
    XmbLookupString gives 0 bytes:  
    XFilterEvent returns: False 

KeyRelease event, serial 28, synthetic NO, window 0x1400001, 
    root 0xeb, subw 0x0, time 26983834, (158,0), root:(158,29), 
    state 0x10, keycode 111 (keysym 0xff52, Up), same_screen YES, 
    XLookupString gives 0 bytes:  
    XFilterEvent returns: False 

KeyPress event, serial 28, synthetic NO, window 0x1400001, 
    root 0xeb, subw 0x0, time 26984861, (158,0), root:(158,29), 
    state 0x10, keycode 116 (keysym 0xff54, Down), same_screen YES, 
    XLookupString gives 0 bytes:  
    XmbLookupString gives 0 bytes:  
    XFilterEvent returns: False 

KeyRelease event, serial 28, synthetic NO, window 0x1400001, 
    root 0xeb, subw 0x0, time 26984942, (158,0), root:(158,29), 
    state 0x10, keycode 116 (keysym 0xff54, Down), same_screen YES, 
    XLookupString gives 0 bytes:  
    XFilterEvent returns: False 


> localectl                 
   System Locale: LC_CTYPE=de_DE.UTF-8 
       VC Keymap: de-latin1-nodeadkeys 
      X11 Layout: de 
       X11 Model: pc105 
     X11 Variant: nodeadkeys 
     X11 Options: terminate:ctrl_alt_bksp

[FONT=monospace]

[/FONT]

No, Barebone.
Cherry (mechanical) keyboard, did try the unplug but no change. BTW “Reboot-stable” error.

No :frowning:

Pkg xbindkeys not installed, don’t have both, no file ~/.xbindkeysrc nor xbindkeys_show executable

#13

Do you have any bind commands added to your in .profile or .bash* ?
What do you get if this command is executed from konsole ?


> bind -p |grep -iE '\[A|\[B' 
"\e\e[b]**": next-history 
"\e****": next-history 
"\e\e**[A[/b]": previous-history 
"\e**[A[/b]": previous-history
#14

[SOLVED]-[SOLVED]-[SOLVED]-[SOLVED]-[SOLVED]-[SOLVED]-[SOLVED]-[SOLVED]-[SOLVED]-[SOLVED]

Found it finally, unbelievable!

TL;DR: “Culprit” was an entry in ~/.config/konsolerc.

As only konsole has the “lost UP key”, not xterm, not the <F4> bash in Dolphin (!!), all $TERM etc. and all settings by your lots of hints are equal, I’ve focused today on the difference between “pure” konsole and the “bash window” inside Dolphin. Which looks the same for me, but “ps” doesn’t show a running konsole for Dolphin.
konsole --help gave some hints for “konsole profiles”.

konsole --list-profiles

lists “Shell” and “Root Shell”
Searching the net for “Konsole profiles” I finally was lead to Settings/Manage Profiles. There’s also a third readonly profile listed, “Standard”.
Tried at first a “Root Shell” konsole, same issue.

Then, drum roll, I’ve recognized that these Konsole profiles ALSO have their own shortcut, aside to the myriads of shortcuts we’ve alreaday checked.

And the shortcut for “Shell” as set to “Up, Down, Left, Left”… and this is absolutely strange:
→ After having cleared the shortcuts I’ve checked with a “find ~ -0.25 -print” for recently changed files, found the mentioned ~/.config/konsolerc
→ Checked in my (BackInTime) backups when appr. I must have set this, although completely no idea for what reason I might have set this, as no idea what these shortcuts are doing: Have been “empty” for Leap 42.1, 42.2 and the first backup for 42.3. Was set whenever during the period of 42.3.
→ Once erased now I have my “up”/“Arrow-Up” key back, HEUREKA!
→ But: these shortcuts didn’t have had this “missing UP” effect in 42.3, 15.1-3, as said first with now 15.4.

And, final remark, I have NO CLUE how to set to “Up, Down, Left, Left”: Can e.g. double click in “shortcut” field and set to “ctrl-up”, or “ctrl-e” or whatever I want, but the basic Up, Down, Left, Left key all have NO EFFECT when pressed, can’t be used…

MYSTIC but good luck finally solved :slight_smile:

THANKS TO ALL WHO HELPED !!!