Ble.sh: [Kitty] ble.sh not working with the kitty terminal

[NoahGorny]

ble version: 0.4.0-devel3+750ca38
Bash version: 5.0.17(1)-release

Hello there!
I tried to use ble.sh with the kitty terminal, but when ble.sh was loaded, the terminal got messed up. Ran commands, yet I could not see any output, or any line executed..

If you want, I can try to add screenshots. In any case, I think it is easily reproducible by running kitty and loading ble.sh

In any case, this seems like a very cool project. I think about adding it as a plugin for bash-it :smile:

[akinomyoga]

Hello! Thank you for the report! It seems there is no problem in my Kitty on Ubuntu 20 LTS in VirtualBox. I have questions:

• Q1: Have you tried other terminals? Is the problem only reproduced in Kitty?
• Q2: What is your TERM environment variable? Edit Do you have a corresponding entry in terminfo/termcap?

$ echo "$TERM"
$ tput cols; echo $?

• Q3: What is your operating system? What is the output of echo $MACHTYPE? If it is Linux, which distribution do you use?

$ echo "$MACHTYPE"
$ uname -a
$ cat /etc/*-release # if you are in Linux

• Q4: Does it reproduce with a plain Bash?

$ INPUTRC=/dev/null bash --norc --noprofile
$ source /path/to/ble.sh

[NoahGorny]

Hello! Thank you for the report! It seems there is no problem in my Kitty on Ubuntu 20 LTS in VirtualBox. I have questions:

• Q1: Have you tried other terminals? Is the problem only reproduced in Kitty?
• Q2: What is your TERM environment variable? Edit Do you have a corresponding entry in terminfo/termcap?

$ echo "$TERM"
$ tput cols; echo $?

• Q3: What is your operating system? What is the output of echo $MACHTYPE? If it is Linux, which distribution do you use?

$ echo "$MACHTYPE"
$ uname -a
$ cat /etc/*-release # if you are in Linux

• Q4: Does it reproduce with a plain Bash?

$ INPUTRC=/dev/null bash --norc --noprofile
$ source /path/to/ble.sh

Hi @akinomyoga
It seems like I can not reproduce the problem, after opening a new instance of kitty, everything works as expected :smile:
Thank you for your detailed answer, and I look forward to use ble.sh on a regular basis :smiley:

[NoahGorny]

Hmm, after another look, it looks like the problem persists..
It works well with gnome-terminal however.

TERM=xterm-kitty
tput cols=134
Linux version 5.8.0-050800, Ubuntu 20.04.2 LTS
It is reproducible with plain bash.

[akinomyoga]

Hmm, thank you. Maybe it is related to the prompt.

• Q5: What happens if yous set PS1='\$ ' when the problem is occurring?
• Q6: Edit: What is your PS1?

[NoahGorny]

PS1=\[\e[0;32m\]\u\[\e[0m\]@\[\e[34;1m\]\h\[\e[0m\]:\[\e[0;33m\]\w\[\e[0m\]\[\e[0;32m\] $ \[\e[0m\]

The problem is still there when I set PS1 to this sadly :cry:

[akinomyoga]

Thank you! Hmm... ble.sh actually doesn't use the [ builtin command but always uses the [[ construct. So it must be injected by something external.

• Q7: What if you cleared all the environments?

$ env -i INPUTRC=/dev/null bash --norc --noprofile
$ source /path/to/ble.sh --norc --noinputrc

Edit: Maybe you have already set up something in ~/.blerc? In that case, please also try --norc and --noinputrc options on sourcing ble.sh (as above).

[NoahGorny]

Still does not work. It seems to happen when I reach the end of the screen with the prompt, or with the first two lines.

[akinomyoga]

Thanks. It still doesn't reproduce in my environment with a long prompt (though I found an unrelated problem) and also at the top and bottom lines of Kitty.

• Q8: What if you change TERM such as TERM=xterm-256color in Kitty when the problem is happening?

[akinomyoga]

• Q9: What is your Kitty version? Have you tried the latest version of Kitty?
• Q10: What is your kitty.conf? Does the problem reproduce by an empty kitty.conf? This is mine:

$ kitty --version
kitty 0.20.3 created by Kovid Goyal
$ cat ~/.config/kitty/kitty.conf
font_family Ubuntu Mono
bold_font auto
italic_font auto
bold_italic_font auto

[akinomyoga]

I have created a commit 2e14354 for testing and pushed it to debug110 branch.

• Q11: Could you checkout the branch debug110 and see how the output looks like when the error message bash: [: =: unary operator expected is present? Screen capture is OK. I would like to identify where the error message bash: [: =: unary operator expected is produced.

[NoahGorny]

I have created a commit 2e14354 for testing and pushed it to debug110 branch.

• Q11: Could you checkout the branch debug110 and see how the output looks like when the error message bash: [: =: unary operator expected is present? Screen capture is OK. I would like to identify where the error message bash: [: =: unary operator expected is produced.

My kitty terminal was outdated- and after updating to kitty 0.20.3, the problem was fixed :smile:

However, there is still this output from the unary operator after I echo. Here is the output from the branch:

noah@noahs-ubunto[±|debug110 → noah ✓]:~/open-source/ble.sh $ echo bababa
bababa
[U1][U2][U2a][U2b]bash: [: =: unary operator expected
[U2c][U2d][U3][U4][I1][I2][I3][I3a][I3b][I4][I4d][U5]
[U6]
[R.W1][R.W2][R.W3][R.W4a][R.W5]
noah@noahs-ubunto[±|debug110 → noah ✓]:~/open-source/ble.sh $ [U1][U2][U2a][U2b]bash: [: =: unary operator expected
[U2c][U2d][U3][U4][I1][I2][I3][I3a][I3b][I4][I4d][U5]
[U6]
[R.W1][R.W2][R.W3][R.W4a][R.W5]

noah@noahs-ubunto[±|debug110 → noah ✓]:~/open-source/ble.sh $ echo bobo
bobo
[U1][U2][U2a][U2b]bash: [: =: unary operator expected
[U2c][U2d][U3][U4][I1][I2][I3][I3a][I3b][I4][I4d][U5]
[U6]
[R.W1][R.W2][R.W3][R.W4a][R.W5]
noah@noahs-ubunto[±|debug110 → noah ✓]:~/open-source/ble.sh $ 

[akinomyoga]

My kitty terminal was outdated- and after updating to kitty 0.20.3, the problem was fixed 😄

Oh, OK! Great.

However, there is still this output from the unary operator after I echo. Here is the output from the branch:

OK. It means that it was actually a combined problem of two problems. It's confusing!

[U2b]bash: [: =: unary operator expected
[U2c]

This indicates that PROMPT_COMMAND has some problems.

• Q12: Do the unary operator error messages disappear after PROMPT_COMMAND=?

$ PROMPT_COMMAND=

• Q13: What is your PROMPT_COMMAND (and its attributes)?

$ declare -p PROMPT_COMMAND

• Q14: Do the error messages reproduce when ble.sh is loaded but not attached?

$ bash # start new session
$ source /path/to/ble.sh --noattach

[NoahGorny]

So, after debugging the problem a bit:
I use pre-exec vendored from bash-it, so my prompt command:

declare -- PROMPT_COMMAND="__bp_precmd_invoke_cmd
preexec_set_exit;preexec_invoke_cmd
__bp_interactive_mode"

I saw that running __bp_precmd_invoke_cmd caused the wierd unary ... message to appear. After looking at the code, it called pure_prompt which is the theme I use in my bash shell. Inside, there was a call to scm_prompt:

scm_prompt() {
    CHAR=$(scm_char)
    if [ $CHAR = $SCM_NONE_CHAR ]
        then
            return
        else
            echo "[$(scm_char)$(scm_prompt_info)]"
    fi
}

It seemed like the echo call was the problematic one.. After adding -e it was fixed :smile:
Thanks for all the help @akinomyoga!

There is another problem that I encountered. When you call exec bash from the terminal after loading ble.sh, all key events are just printed to the terminal, and not processed :cry:
I can open this on another issue if you wish

[akinomyoga]

OK!

scm_prompt() {
    CHAR=$(scm_char)
    if [ $CHAR = $SCM_NONE_CHAR ]
        then
            return
        else
            echo "[$(scm_char)$(scm_prompt_info)]"
    fi
}

It seemed like the echo call was the problematic one.. After adding -e it was fixed 😄

Hmm... is it really -e that solved the issue? I don't see the reason. Naively thinking, I guess it was caused by [ $CHAR = $SCM_NONE_CHAR ] when $CHAR becomes an empty string. [ = xxx ] causes the error message bash: [: =: unary operator expected.

I'm also wondering why it didn't reproduced with the plain Bash but only reproduced in ble.sh.

Thanks for all the help @akinomyoga!

You're welcome!

There is another problem that I encountered. When you call exec bash from the terminal after loading ble.sh, all key events are just printed to the terminal, and not processed 😢
I can open this on another issue if you wish

Oh, thank you for the information! Hmm... again it doesn't reproduce in my environment. Do you use romkatv/gitstatus? If so, could you try to update it to the latest git version as I have recently reported an issue of exec replaced by gitstatus?

[NoahGorny]

I indeed use gitstatus, but even after updating it, or even when disabling it.
I also tried to use a clean environment with plain bash, and it also happened there. I tried to use gnome-terminal, and the bug did not happen there at all!

Seems like another kitty problem, yet this time it is with the latest version :cry:

[akinomyoga]

Hmm, interesting. There is no problem with exec bash in my Kitty. I'm not sure if it is again the KItty issue. Does the problem still reproduce with the following combination of commands?

$ stty sane; exec bash

Also,

$ ble-detach
[ble: detached]
Please run `stty sane' to recover the correct TTY state.
$ stty sane;
$ exec bash

[NoahGorny]

It happens after ble-detach, so I can not run stty sane; exec bash afterwards. Even without detaching, stty sane; exec bash doesnt work either. It seems like most of the keyboard events are not interpreted, and just printed as special characters (pressing enter, pressing ctrl+C, etc..). Restarting the terminal using ctrl+shift+del removes the misbehaviour

[akinomyoga]

OK, I could partially reproduce the issue. This is a bug of Kitty or a quirk of Kitty. I added a work around f599525.

It seems like most of the keyboard events are not interpreted, and just printed as special characters

So, this doesn't mean something trivial like ^C for C-c but more non-trivial ones? Also, normal characters are not affected.

[NoahGorny]

OK, I could partially reproduce the issue. This is a bug of Kitty or a quirk of Kitty. I added a work around f599525.

It seems like most of the keyboard events are not interpreted, and just printed as special characters

So, this doesn't mean something trivial like ^C for C-c but more non-trivial ones? Also, normal characters are not affected.

This commit indeed fixed the problem. Maybe this is something we should report to kitty?

Thanks for all of your help @akinomyoga! your dedication is truly amazing :smile:

[NoahGorny]

By the way, by adding ble.sh to Bash-it, I mean adding a plugin that locates and loads ble.sh. This is purely for comfort of Bash-it users, and I hope it will encourage more people to use ble.sh :smile:

Closing this issue now, expect a PR with a new plugin in Bash-it soon :smiley:

[akinomyoga]

This commit indeed fixed the problem.

OK! Thank you for your confirmation!

Maybe this is something we should report to kitty?

Maybe, but I'm not sure if Kovid will change the behavior of Kitty. The problem is the behavior of the terminal feature called modifyOtherKeys. In particular the interpretation of the escape sequence \e[4;1m. This escape sequence was first introduced by Xterm, and other terminals followed its behavior. But actually, the behavior is not well documented in the manual of Xterm. Nevertheless, the implementations by Mintty, RLogin, etc. treat \e[4;1m pretty much the same as Xterm (Roughly speaking, \e[4;1m turns off modifyOtherKeys mode). Kitty fails to reproduce the behavior of Xterm (It seems \e[4;1m turns on modifyOtherKeys mode in Kitty). But I'm not sure Kovid will follow others. In my impression, he doesn't like to follow others unless there is clearly established standard. Here are also the related discussions and materials by terminal people:

• Raw keyboard input (#1) · Issues · terminal-wg / specifications · GitLab
• Fix Terminals - Please

By the way, by adding ble.sh to Bash-it, I mean adding a plugin that locates and loads ble.sh. This is purely for comfort of Bash-it users, and I hope it will encourage more people to use ble.sh 😄

Oh! Thank you very much! When you add ble.sh configuration to bash-it, please let me know that. Actually, basically ble.sh wants to be loaded directly from ~/.bashrc. If one wants to load ble.sh from other places, there are several points that the user needs to be careful.