[SUSE /etc/inputrc] issues sourcing ble.sh

[Anyborr]

GNU bash, version 4.4.23(1)-release (x86_64-suse-linux) [SUSE Linux Enterprise Server 15]
ble.sh, version 0.4.0-devel4+b6344b3b (noarch) [git 2.35.3, GNU Make 4.2.1, GNU Awk 4.2.1, API: 2.0]
bash-completion, version 2.7 (hash:a379b3f832e4e804323eb4c21c12f799cc5a1987, 73857 bytes) (noarch)
locale: LANG=en_US.UTF-8
terminal: TERM=xterm-256color wcwidth=auto-auto/15.1-2+ri

After having SSH'd to a machine with ble.sh installed, sourcing the ble.sh script, either straight from the git directory or after installing the program, results in repeated messages of -bash: syntax error near unexpected token from most keypresses that are not letters A-Z or numbers. This also produces the blesh message at the top left of the terminal recieved a misencoded char U+0000 and writes weird letters to the write-line in the terminal. Blesh works fine when sourcing from a native terminal on the target machine, but does not work properly when SSH'd into the machine.

I've tried checking keymap variables are available via localectl and variables from locale look good.

For now i have to turn ble.sh off as my workflow requires me to routinely ssh into my work station.
Appreciate all help, thanks!

[akinomyoga]

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?

[Anyborr]

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.

[akinomyoga]

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.

[akinomyoga]

• 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.

[Anyborr]

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,

[akinomyoga]

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.

[Anyborr]

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

[akinomyoga]

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

[akinomyoga]

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.

[Anyborr]

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,

[akinomyoga]

Thanks for checking!

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

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

[akinomyoga]

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)?

[Anyborr]

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.

[akinomyoga]

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

[akinomyoga]

• 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

[akinomyoga]

• 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?

[swahpy]

hi I have the same issue here about -bash: ble/util/idle.clock: No such file or directory on SUSE. what information do you need?

[akinomyoga]

@swahpy Thanks. Maybe I should check the trace log.

Could you make a file test.bashrc with the following content?

# test.bashrc

HISTFILE=~/blesh-github424.history
bleopt_debug_xtrace=~/blesh-github424.txt
source out/ble.sh --norc

Then, could you start a Bash session with this bashrc and see if the error message reproduce?

$ bash --rcfile test.bashrc
    # <-- please see if the error message reproduces
$ exit     # <-- please exit immediately

If the error message is reproduced, could you provide the file created at ~/blesh-github424.txt? To attach the .txt file to the reply, you can drag and drop the file into the textarea in the GitHub issue.

After testing, you can remove the files ~/blesh-github424.txt and ~/blesh-github424.history.

[swahpy]

hi akinomyoga, apologize for late reply. I tested according to your suggestions and attached blesh-github424.txt, please take a look. Thank you.

blesh-github424.txt

[akinomyoga]

Thank you for the log. I checked it, but I couldn't find a suspicious command. I think the error is caused outside the section that is not logged. I'll later ask you to try another test2.bashrc.

[mcepl]

BTW, just to let myself be known: I am openSUSE user myself (actually MicroOS, but those are the same Tumbleweed packages), and I don’t observe anything weird like that. I use ble.sh on my main system directly, without SSH.

[akinomyoga]

Multiple issues are discussed in this issue. I'm not sure which one you are talking about, but the original problem seemed to have been specific to SUSE but not present in openSUSE. I tested the behavior in openSUSE Tumbleweed then, but I couldn't reproduce the problem. There seem to be many ble.sh users who use openSUSE, but they don't seem to report this problem. This issue is somehow only reported by the users of SUSE Linux Enterprise.

[akinomyoga]

@swahpy @Anyborr Sorry for the late reply, but if you are still available and seeing the same issue of ble/util/idle.clock, could you try #424 (comment) to see if the problem arises in that setup?

@swahpy Also, could you provide the result of the following command?

$ ble/widget/display-shell-version

@swahpy @Anyborr Also, what are the results of the following commands?

$ echo "$SHELLOPTS"
$ echo "$BASHOPTS"

[mcepl]

Multiple issues are discussed in this issue. I'm not sure which one you are talking about, but the original problem seemed to have been specific to SUSE but not present in openSUSE. I tested the behavior in openSUSE Tumbleweed then, but I couldn't reproduce the problem. There seem to be many ble.sh users who use openSUSE, but they don't seem to report this problem. This issue is somehow only reported by the users of SUSE Linux Enterprise.

Interesting, I am actually an employee of SUSE, so if there is a bug in our enterprise server, there are some of my colleagues whom I may let know.