[SUSE /etc/inputrc] issues sourcing ble.sh about ble.sh HOT 16 OPEN

Thanks for the report. I'm always using ssh, but it doesn't reproduce in my environment, and I've never experienced the behavior.

• Q1: Could you try clearing the cache by the following command? After that, is the behavior change?

$ bash /path/to/ble.sh --clear-cache

• Q2: What is your terminal at your local machine?
• Q3: Was the above information from ble/widget/display-shell-version taken from the problematic session? Or was it taken from the working terminal (i.e., "the native terminal on the target machine")? What is the value of TERM in the terminal of the local machine where you attempt SSH?

from ble.sh.

Some additional info:
When I ssh to a new local computer with blesh it seems to work fine, so there must be something specific with the first machine that is causing the problem. The reason I thought it was related to SSH was because the same issue appeared when i installed blesh on a computer cluster i also ssh to.

Q1: Clearing the cache does not affect the behavior.

Q2: The machine i SSH from is using WSL2 with the default terminal app and $BASHVERSION 5.1.16(1)-release, but the issue appears also when I SSH from a terminal on a linux SUSE machine. The target machines are using linux SUSE, the computational cluster Im not sure which flavor of linux they run.

Q3: The display-shell-version was taken from the problematic machine while connected via SSH. because both of the machines I've seen the problems from are non-local I cannot log on locally to see if the same problem appears without SSH, but I suspect now that the issue is more connected to the environment and does not have to do with SSH. The TERM of my local machine is xterm-256color

When sourcing the ble.sh script on one of the problematic machines the write prompt gets filled with the character string [31;4R[31;4R[31;5R[31;5R[31;5R[31;4R[31;5R[31;5R[31;4R[31;5R[31;5R[31;5R[31;5R[31;5R[31;5R[31;5R[31;4R[2;1R[3;1R[>0;10;1c where the numbers are random for each time the script is sourced while the letters and brackets are the same. These characters dont appear when the script is reloaded, but the problematic behavior persists. These type of characters also appear on the prompt every time a non-numeric or non-A-Z key is pressed.

from ble.sh.

Sorry for the delay in the answer. I didn't have an idea what is happening, and also I was busy.

Today, a possibility of broken /etc/inputrc in SUSE came to my mind. In the past, there were problems with the default Readline settings shipped with openSUSE (#89, #105, #268, openSUSE/aaa_base#84, openSUSE/aaa_base#140). Even if the reported systems still distribute the old broken inputrcs, I had been assuming that the workarounds for openSUSE (which ignores the broken settings) would be applied to your systems. However, I realized that the workaround explicitly checks whether the system name contains the string openSUSE. The system name in the reported system seems to be just SUSE, so I guess SUSE in the reported systems shares the basic settings with openSUSE and distributes the broken inputrcs, and in addition the workaround by ble.sh wouldn't be enabled in your systems.

from ble.sh.

• Q4: Does the situation change when you pass the option --inputrc=none to source /path/to/ble.sh in your remote ~/.bashrc?

# bashrc

source /path/to/ble.sh [other options if any...] --inputrc=none

Please replace /path/to/ble.sh with the path to the file ble.sh in your installation. Also, please replace [other options if any ...] with the options you already specify, if any, or remove it.

from ble.sh.

Hi, no worries, I've also been quite busy with work.

testing your suggestion in Q4 unfortunately did not produce a different result.
Below I've attached an image of the terminal directly after sourcing the ble.sh script. the gray key combinations show up automatically as a result of running the script, and the red highlighted key combinations are a result of me pressing random arrow keys in sequence directly afterwards.

Best,

from ble.sh.

Thank you for your patience! Hmm, then, /etc/inputrc seems unrelated. I'd like to check what bytes ble.sh receives when you press the cursor keys.

• Q5: Could you check the results of the following commands?

$ ble-import core-debug
$ ble/debug/keylog#start
$ [A[C[B[D[...          # <-- Could you press cursor keys here to replicate the problem?
$ ble/debug/keylog#end
        # <-- what is the output here?

I'd like to check the state of bind in the problematic session.

• Q6: Could you attach the file produced by the following command?

$ builtin bind -spX > dump-bind.txt

You can copy the generated file dump-bind.txt to the local host using scp, and attach the text file by dragging and dropping the file into the textarea for the reply in this GitHub Issue page. After attaching the file, you can remove the file dump-bind.txt from both remote and local hosts.

from ble.sh.

Q5:

===== bytes =====
192 91 67 192 91 65 192 91 68 192 91 67
192 91 66 192 91 68 192 91 67 192 91 68
192 91 67 192 91 65 192 91 68 192 91 67
192 91 66 192 91 68 192 91 67 192 91 68
192 91 65 192 91 67 192 91 68 192 91 67
192 91 66 192 91 68 192 91 67 192 91 68
192 91 65 3 98 108 101 47 100 101 98 117
 103 47 107 101 121 108 111 103 35 101 1
10 100 13

===== chars =====
NUL [ C NUL [ A NUL [ D NUL [ C NUL [ B
NUL [ D NUL [ C NUL [ D NUL [ C NUL [ A
NUL [ D NUL [ C NUL [ B NUL [ D NUL [ C
NUL [ D NUL [ A NUL [ C NUL [ D NUL [ C
NUL [ B NUL [ D NUL [ C NUL [ D NUL [ A
ETX b l e / d e b u g / k e y l o g # e
n d RET

===== keys =====
C-@ [ C C-@ [ A C-@ [ D C-@ [ C C-@ [ B
C-@ [ D C-@ [ C C-@ [ D C-@ [ C C-@ [ A
C-@ [ D C-@ [ C C-@ [ B C-@ [ D C-@ [ C
C-@ [ D C-@ [ A C-@ [ C C-@ [ D C-@ [ C
C-@ [ B C-@ [ D C-@ [ C C-@ [ D C-@ [ A
C-c b auto_complete_enter l e / / auto_c
omplete_enter d e b u g / / auto_complet
e_enter k e y l o g # e e auto_complete_
enter n d C-m

Q6

dump-bind.txt

from ble.sh.

Thank you for those results! With a cursor key, ble.sh is supposed to receive a byte sequence in the form 192 155 91 {65..68}. However, the result of Q5 tells that the byte 155 is missing. However, as far as I examine the attached dump-bind.txt from Q6, there doesn't seem to be any problems. The result is exactly the same as that in my environment with Bash 4.4 in the emacs editing mode. Maybe the internal state of Readline is broken for some reason. Then, I again suspect /etc/inputrc.

• Q7: Is there any difference in the behavior between the child Bash sessions started in the following two ways?

$ bash    # <-- start a child session (#1)
$ source /path/to/ble.sh
$     # <-- check the behavior
$ exit    # <-- end the child session #1
$ INPUTRC=/dev/null bash    # <-- start another child session (#2) with INPUTRC=/dev/null
$ source /path/to/ble.sh
$     # <-- check the behavior
$ exit    # <-- end the child session #2

from ble.sh.

OK, I could reproduce the problem with an old /etc/inputrc.keys of openSUSE using Bash 4.4. I've been preventing ble.sh from reading /etc/inputrc of openSUSE as a workaround, but I think I'll have to add another workaround to prevent even Readline from reading /etc/inputrc of openSUSE and SUSE.

from ble.sh.

Q7: sourcing blesh within INPUTRC=/dev/null bash seems to solve the issue of keys not functioning properly. When sourcing ble.sh I still get the bash: ble/util/idle.clock: No such file or directory printout, but maybe it does not matter?

I'll test around a bit in the coming weeks and if I encounter any other problems that seems unique to the machines where i observed the issues ill add them to this thread (or if prudent, open a new issue).

Thanks for taking the time with this issue.

Best,

from ble.sh.

Thanks for checking!

bash: ble/util/idle.clock: No such file or directory

This is a separate issue. I'll fix it.

from ble.sh.

I think I'll have to add another workaround to prevent even Readline from reading /etc/inputrc of openSUSE and SUSE.

I tried to add a workaround, but I realized that the problem doesn't arise in my environment in the case where the workaround can be implemented.

• Q8: Does the problem of broken key processing arise when source ble.sh --inputrc=none is performed inside ~/.bashrc?

I seem to be able to reproduce the problem only when I source ble.sh in the prompt. In this case, the workaround cannot be implemented because the Readline state is already broken before source ble.sh is performed. For the workaround, I assumed the case where source ble.sh is performed inside ~/.bashrc (i.e., source ble.sh is performed before Readline is initialized). However, in the case where source ble.sh is performed inside ~/.bashrc, the problem doesn't seem to happen even without the workaround.

When sourcing ble.sh I still get the bash: ble/util/idle.clock: No such file or directory printout,

I took a look into this issue, and I found the issue happens when the internal API ble/util/idle.push --sleep=* (which was recently added in commit e0566bd) is used in the initialization stage. However, as far as I know, this internal feature is not supposed to be used in the initialization stage. The reported issue might be caused differently, but I currently have no idea.

• Q9: Do you have any custom settings for ble.sh (e.g. in ~/.blerc)?

from ble.sh.

Q8: Same as for your investigation the issues appear again when sourcing ble.sh within .bashrc, both with and without using --inputrc=none.

Q9: I don't have any additional settings for ble.sh. The configuration is "out of the box" so to say.

from ble.sh.

Thank you for your answers.

Q8: Same as for your investigation the issues appear again when sourcing ble.sh within .bashrc, both with and without using --inputrc=none.

Then, the situation seems slightly different in my environment.

Q9: I don't have any additional settings for ble.sh. The configuration is "out of the box" so to say.

Hmm,

• Q10: How about the other settings? Do those problems (key inputs and ble/util/idle.clock) reproduce with only ble.sh setting in ~/.bashrc?

# bashrc

source /path/to/ble.sh --norc --inputrc=none

from ble.sh.

• Q10: How about the other settings? Do those problems (key inputs and ble/util/idle.clock) reproduce with only ble.sh setting in ~/.bashrc?

# bashrc

source /path/to/ble.sh --norc --inputrc=none

Maybe I was a bit unclear about this. I would like to know the results when you have only the ble.sh settings in your ~/.bashrc. You can copy your original .bashrc to another file, and then put the above single line in ~/.bashrc.

# 1. back up your original .bashrc (".bashrc.original" is an example name)

[remote]$ mv ~/.bashrc ~/.bashrc.original

# 2. make sure that your original .bashrc is moved to ~/.bashrc.original

[remote]$ ls -l ~/.bashrc*

# 3. rewrite .bashrc (please replace /path/to/ble.sh with the path to ble.sh in your installation)

[remote]$ echo 'source /path/to/ble.sh --norc --inputrc=none' >> ~/.bashrc

# 4. check the behavior in a child session

[remote]$ bash

<-- see behavior here

[remote]$ exit

# 5. After finishing the test, you can recover the original settings by moving back the backed up file

[remote]$ mv ~/.bashrc.original ~/.bashrc

from ble.sh.

• Q10: How about the other settings? Do those problems (key inputs and ble/util/idle.clock) reproduce with only ble.sh setting in ~/.bashrc?

Do you have any updates on this issue about the error message related to ble/util/idle.clock? I added a commit in the latest push to fix a possible initialization problem of ble/util/idle.push. However, the problem only happens in a specific usage of ble/util/idle.push, which is not used in the current codebase in my understanding. So the problem you observe might be different. Could you check if the situation change for the problem of ble/util/idle.clock with the latest version of ble.sh?

Q8: Same as for your investigation the issues appear again when sourcing ble.sh within .bashrc, both with and without using --inputrc=none.

Then, the situation seems slightly different in my environment.

For the original issue of the key inputs, maybe you have some settings of bind before sourcing ble.sh.

I've checked the source code of Bash. It seems to be possible to suppress loading /etc/inputrc by putting the user configuration ~/.inputrc. I think the problem can be solved by putting an empty ~/.inputrc in your home directory of the SUSE systems. Could you try that?

from ble.sh.