After sourcing ble.sh, term not responding for any input. WSL. Arch.

[NightWindGames]

MY FIRST ISSUE ON GITHUB

ありがとうございます。For such a great tool :)

Unfortunately i have problems with installation, i used Yay in Arch(I use Arch & Neovim btw) linux inside WSL :<

I think it installed normally, but when i added this lines or using source /usr/share/blesh/ble.sh Output says that blesh updating cache for TMUX 256 colors, and then stops listen input

#
# ~/.config/bash/.bashrc
#

[[ $- == *i* ]] && source /usr/share/blesh/ble.sh --noattach

# .bashrc code...

clear

fastfetch

[[ ! ${BLE_VERSION-} ]] || ble-attach

I tried clearing cache, this did not helped :( As always windows creating me problems(my Linux machine broken, and i can't use it now)

[akinomyoga]

Thanks for the report, but I cannot reproduce the problem with Ubuntu/WSL. Currently, I don't have an idea about what is happening in your environment. I need more information.

• Q1: What is your terminal?
• Q2: Which version of ble.sh do you use? Did you use yay -S blesh or yay -S blesh-git? If you use the former (blesh), could you overwrite it with the latter one (blesh-git)? blesh is old, so some compatibility issues may happen.

You seem to have other settings inside your ~/.config/bash/.bashrc.

• Q3: To narrow down the cause of the issue, could you check if the problem persists with only ble.sh settings in your ~/.bashrc (but not ~/.config/bash/.bashrc)?

# bashrc
HISTFILE=/dev/null # protect your .bash_history from the empty Bash setting
[[ $- == *i* ]] && source /usr/share/blesh/ble.sh --noattach
[[ ! ${BLE_VERSION-} ]] || ble-attach

• Q4: Does the situation change if you use the following ~/.bashrc?

# ~/.bashrc
HISTFILE=/dev/null # protect your .bash_history from the empty Bash setting
[[ $- == *i* ]] && source /usr/share/blesh/ble.sh

• Q5: How about this?

# ~/.bashrc
HISTFILE=/dev/null # protect your .bash_history from the empty Bash setting
[[ $- == *i* ]] && source /usr/share/blesh/ble.sh --inputrc=none

[NightWindGames]

Im so sorry for late reply, GitHub not sent me notification

• Q1 Windows Terminal(from ms store) version: 1.22.11141.0 with TMUX 3.5a
• Q2 blesh-git version 0.4.0-devel4+14f98dd8
• Q3 Problem persist even with only this lines
• Q4 Yeah unfortunetly freezing
• Q5 Sorry, same

It just freezing, only tmux prefix works(im closing window with tmux)

[NightWindGames]

Oh im so sorry, but today and tomorrow i will be away from keyboard Sorry :( Can we continue monday?

[akinomyoga]

Thank you for the results.

• Q1 Windows Terminal(from ms store) version: 1.22.11141.0 with TMUX 3.5a

Does this mean the problem only happens inside Tmux?

• Q2 blesh-git version 0.4.0-devel4+14f98dd8
• Q3 Problem persist even with only this lines
• Q4 Yeah unfortunetly freezing
• Q5 Sorry, same

Thank you.

Can we continue monday?

OK.

[NightWindGames]

すみません, I was busy in day off helping my grandpa

• Q1 Windows Terminal(from ms store) version: 1.22.11141.0 with TMUX 3.5a

Does this mean the problem only happens inside Tmux?

No. But without tmux, cursor blinking, and stops when i do something

[akinomyoga]

I'm not sure if it is related, but in commit 622cb2475ff1fe6ac04d5e71d6a8614723e953c0, I fixed an input problem that affected Windows Terminal when it is used to connect to Git Bash for Windows, MSYS2, or Cygwin.

[NightWindGames]

Sorry for late reply.

My computer not with me now But I will try ble.sh again tomorrow :)

Thank you for helping me!

[NightWindGames]

Unfortunately, nothing helps. :(

I used bash /usr/share/blesh/ble.sh --update to update blesh(Yay AUR with cleanbuild).

First i tried bash /usr/share/blesh/ble.sh. After that i tried all methods that you described above. But unfortunately nothing helps. :( Maybe it works on real Arch machine but not on WSL.

[akinomyoga]

Thanks for checking!

Hmm, since it is impossible to input anything in the session, we need to find a way to investigate the situation other than inputting commands.

• Q6: Could you clone the git repository and try commit 2cac11ad?

$ git clone [email protected]:akinomyoga/ble.sh.git blesh.debug
$ cd blesh.debug
$ git checkout -b debug 2cac11ad
$ make all

The above command will create out/ble.sh. Then, you can try loading this file in your ~/.bashrc:

# bashrc
HISTFILE=/dev/null
[[ $- == *i* ]] && source /path/to/blesh.debug/out/ble.sh --norc

Does this commit work for you?

• Q7: If the setup of Q6 works, could you also try the same for commit f940696f?

Maybe it works on real Arch machine but not on WSL.

I use three real Arch Linux machines and log in to them using ssh, but never had problems. I now tried again after sudo pacman -Syu and yay -Sy blesh-git, but the problem doesn't reproduce.

[akinomyoga]

I'm not sure if it is related, but the following issue reports a similar issue. The environment is WSL, and nothing can be input inside Atuin although one can input something outside of it. Atuin uses kitty's keyboard protocol. The situation seems similar. ble.sh also turns on XTerm's modifyOtherKeys or kitty's keyboard protocol depending on the terminal. The Atuin issue doesn't seem to be caused inside tmux, but ble.sh also attempts to turn on the advanced keyboard protocol using tmux's passthrough sequence (though recent versions of tmux require an explicit option to turn it on).

• https://github.com/atuinsh/atuin/issues/2598

You may try setting the following settings to turn off any advanced keyboard protocols.

# bleopt
bleopt term_modifyOtherKeys_@=

[NightWindGames]

Sorry for late reply.

Thank you for helping me！ I will try everything now🙂

[NightWindGames]

Does this commit work for you?

Yes! It works! It have kind of broken colors but it works! I pressed 'j' and it showed autocompletion.

[NightWindGames]

Unfortunately, now i can't try another commit, I'm going to Japanese language lessons. After i return home, i will try it :)

[NightWindGames]

https://github.com/akinomyoga/ble.sh/commit/f940696fde28cfd3952445fe6c3f9d853af7f7b8 Commit works too :)

Thank you!

I tried basic setup and it worked too!

[[ $- == *i* ]] && source -- /path/to/blesh/ble.sh --attach=none # At the begining

[[ ! ${BLE_VERSION-} ]] || ble-attach # At the end

I have question, do you updated AUR version, so i can just update it with yay? Thanks in advance :)

[akinomyoga]

f940696 Commit works too :)

Thank you!

Thank you for checking! Hmm, so commit f940696 isn't the culprit. I actually suspected ble.sh is broken by commit f940696. However, you confirmed that it's not the case. There are 230 commits between commit f940696 and the current master, and ble.sh was broken by some of them.

I tried basic setup and it worked too!

[[ $- == *i* ]] && source -- /path/to/blesh/ble.sh --attach=none # At the begining

[[ ! ${BLE_VERSION-} ]] || ble-attach # At the end

When you say it worked, which version of ble.sh did you use? Did you mean commit f940696? Or did you mean the master version to which you reported (i.e., commit 14f98dd8)? Or did you mean the latest master branch?

I have question, do you updated AUR version, so i can just update it with yay?

I haven't updated the AUR packages recently. Which AUR package do you use? In your reply https://github.com/akinomyoga/ble.sh/issues/600#issuecomment-3038813326, I saw you used 14f98dd8, which means that you used blesh-git. The AUR package blesh-git always checks out the latest master branch regardless of the time when the package file is updated. Then, when you rerun yay -Sy blesh-git and select to overwrite the existing one, it will replace ble.sh with the latest master version.

[cmm]

I just tried upgrading to latest ble.sh (52c38977d945b4fe4ba59f6ed0b14007ea395a26) and I get unresponsive terminal. No idea how to debug things when merely sourcing ble.sh disables all input (or not? Ctrl-D works, so maybe it's the output that's messed up and not input?), but willing to help chasing this down if guided.

EDIT so this was a pilot error, but it would really have helped if failures to invoke ./make_command.sh from awk were fatal and loud...

[akinomyoga]

Thanks for the information, but I cannot reproduce the problem.

EDIT so this was a pilot error, but it would really have helped if failures to invoke ./make_command.sh from awk were fatal and loud...

Could you describe this in more detail? What have you done, and what has been the problem? Do you think ./make_command.sh should not be invoked from awk? Could you explain the reason?

[akinomyoga]

@NightWindGames Have you solved the problem? If your problem is the same one as @cmm has experienced, it might be caused by commit e63f6f6743bbfbf87cc791168b9bd27395ceaab9 (where the cache version detection was introduced by a strong request by @giggio in #484). Could you check if the problem reproduces in commit e63f6f6743bbfbf87cc791168b9bd27395ceaab9 and commit 262baf0e5674b1e65093ccbda45bd13e87738441? If the problem reproduces in the former but does not reproduce in the latter, the detection introduced in e63f6f6743bbfbf87cc791168b9bd27395ceaab9 could be broken in the build process in some environments.

[akinomyoga]

@cmm What is your environment? Do you also use Arch linux on WSL?

[cmm]

I've written in this thread because I initially thought it could be the same problem based on symptoms, but now I very much doubt it. But anyway, my case went like this:

• I wanted to see what it would take to update the ble.sh package in Nixpkgs -- so I bumped the revision and got the package to build
• But the built artifact didn't work, the symptom being seemingly-total lack of response to input (except Ctrl-D). This is when I commented here, but then got bored and decided to dig further :)
• I built and installed ble.sh normally (not as Nix package) and saw that the result, in fact, works fine
• I then played around with nix-built-vs-normally-built ble.sh and narrowed the differrence down to slightly-divergent content of ~/.cache/blesh
• Specifically, nix-built version produced empty values for _decode_cmap_cache_hash and some other hash
• Those empty values were due to failure to execute ./make_command.sh hash ... during build-time preprocessing
• That failure in turn was due to Nix build sandbox being what it is, and easily fixed once identified, thus pilot error
• The whole dive would not have been needed in the first place if the awk script propagated ./make_command.sh failures (I have no idea if that's even possible/realistic because I don't know any awk, alas)

I guess one possibly-useful bit of information here is that it might be a good idea to snapshot and examine ~/.cache/blesh when sourcing ble.sh results in unresponsive terminal

[akinomyoga]

Thank you so much for the details!

• Those empty values were due to failure to execute ./make_command.sh hash ... during build-time preprocessing
• That failure in turn was due to Nix build sandbox being what it is, and easily fixed once identified, thus pilot error

Could you describe this in a bit more detail? If you could tell me in what situation ./make_command.sh hash ... would fail, it might be possible to add some workarounds. However, I'm still unsure about a possible situation where ./make_command.sh hash ... fails. Does Nix require some special configuration to run a script file from an awk script? Or does starting ./make_command.sh actually succeed but fail with another factor? However, I'm not sure how ./make_command.sh hash ... could fail. Even if related commands are unavailable, ./make_command.sh hash would still fall back to using wc. Or do you mean wc, which is a part of the POSIX environment, is unavailable in the NixOS sandbox?

• The whole dive would not have been needed in the first place if the awk script propagated ./make_command.sh failures (I have no idea if that's even possible/realistic because I don't know any awk, alas)

With gawk >= 4.2, it seems possible to check the exit status with the return value of close(), but it adds an additional requirement for the environment. Also, I'm not sure if the mentioned problem is what we should anticipate in general (in particular when it was a pilot error in an unusual environment).

[cmm]

(/usr/bin/env is unavailable in Nix build sandboxes (because it would be an impurity), so unpatched make_command.sh fails there before even starting, if you will :) for some reason it works when run from make, maybe because make runs everything with $SHELL -c and shell has some special historically-motivated logic that makes the shebang moot? no idea!

but never mind those specifics -- this is a known feature of packaging for Nix and there are common solutions for it, such is life, it's totally unreasonable to expect any upstream changes to accomodate it, ble.sh is totally fine here.)

what I was wondering, however, is whether it would be possible to cause the caller of make_command.sh to fail if make_command.sh fails for whatever reason.

EDIT ah, I see you've addressed this in your comment and I missed it. yeah, if it's not commonly possible across all awk versions that you have to target, then it's probably too much work, got it, thanks!

[akinomyoga]

(/usr/bin/env is unavailable in Nix build sandboxes

Ah, OK. I didn't think the shebang #!/usr/bin/env would fail (as #!/usr/bin/env bash is known as the most portable shebang for Bash). I'm surprised that Nix doesn't care about it. This means that #!/usr/bin/env bash is no longer portable because of Nix, and there is no portable shebang for Bash anymore.

for some reason it works when run from make, maybe because make runs everything with $SHELL -c and shell has some special historically-motivated logic that makes the shebang moot? no idea!

Yeah, this is because, when exec fails, the shell tries to run the file as a shell script using the same version of the shell as the caller.

EDIT ah, I see you've addressed this in your comment and I missed it. yeah, if it's not commonly possible across all awk versions that you have to target, then it's probably too much work, got it, thanks!

It is technically possible to detect the error when the current implementation is gawk >= 4.2.0. However, the problem is the interface of the feature to fail on the command execution error.

ble.sh uses akinomyoga/mwg_pp.awk to generate out/ble.sh, and ./make_command.sh hash ... is called from e.g. this line using the mwg_pp directive $. However, I don't want to change the default behavior of mwg_pp for backward compatibility because it is used by other projects. Another solution could be to add a new mwg_pp directive or setting for command execution that cancels the entire processing on a non-zero exit status, but I'm reluctant to add a new incomplete [^1] language feature just to handle a failure that doesn't seem to be common (when the entire build procedure assumes the existence of /usr/bin/env).

[^1]: which anyway fails to detect the error in gawk < 4.2.

[cmm]

(/usr/bin/env is unavailable in Nix build sandboxes

Ah, OK. I didn't think the shebang #!/usr/bin/env would fail (as #!/usr/bin/env bash is known as the most portable shebang for Bash). I'm surprised that Nix doesn't care about it. This means that #!/usr/bin/env bash is no longer portable because of Nix, and there is no portable shebang for Bash anymore.

It's not so dramatic, actually. NixOS (the Linux distribution built with Nix the builder) does provide /usr/bin/env. Nix build sandbox (a different thing, and not something normal users interact with) does not, for nebulous (and now entrenched forever, probably, because there's nobody who has enough authority or motivation to change this) purity reasons. And it has been this way for like 2 decades.

Your shebangs are exactly as safe as they've ever been.

for some reason it works when run from make, maybe because make runs everything with $SHELL -c and shell has some special historically-motivated logic that makes the shebang moot? no idea!

Yeah, this is because, when exec fails, the shell tries to run the file as a shell script using the same version of the shell as the caller.

TIL!

It is technically possible to detect the error when the current implementation is gawk >= 4.2.0. However, the problem is the interface of the feature to fail on the command execution error.

ble.sh uses akinomyoga/mwg_pp.awk to generate out/ble.sh, and ./make_command.sh hash ... is called from e.g. this line using the mwg_pp directive $. However, I don't want to change the default behavior of mwg_pp for backward compatibility because it is used by other projects. Another solution could be to add a new mwg_pp directive or setting for command execution that cancels the entire processing on a non-zero exit status, but I'm reluctant to add a new incomplete 1 language feature just to handle a failure that doesn't seem to be common (when the entire build procedure assumes the existence of /usr/bin/env).

Footnotes

1. which anyway fails to detect the error in gawk < 4.2. ↩

Thank you for taking the time and effort to explain, much appreciated!

[NightWindGames]

Sorry for too late reply :( I was too busy, and somehow github, never sends me messages ( - _ - )

When you say it worked, which version of ble.sh did you use? Did you mean commit f940696? Or did you mean the master version to which you reported (i.e., commit 14f98dd)? Or did you mean the latest master branch?

I meant both https://github.com/akinomyoga/ble.sh/commit/2cac11adc4eb39d66213c66e9faeac055d8e3df4 and https://github.com/akinomyoga/ble.sh/commit/f940696fde28cfd3952445fe6c3f9d853af7f7b8 commits :)

@NightWindGames Have you solved the problem? If your problem is the same one as @cmm has experienced, it might be caused by commit e63f6f6 (where the cache version detection was introduced by a strong request by @giggio in #484). Could you check if the problem reproduces in commit e63f6f6 and commit 262baf0? If the problem reproduces in the former but does not reproduce in the latter, the detection introduced in e63f6f6 could be broken in the build process in some environments.

Yes, you helped me :)

I tried commit https://github.com/akinomyoga/ble.sh/commit/e63f6f6743bbfbf87cc791168b9bd27395ceaab9 and it works :) https://github.com/akinomyoga/ble.sh/commit/262baf0e5674b1e65093ccbda45bd13e87738441 Works too!

I checked everything with steps provided in README and here https://github.com/akinomyoga/ble.sh/issues/600#issuecomment-3038732420

I haven't updated the AUR packages recently. Which AUR package do you use? In your reply #600 (comment), I saw you used 14f98dd, which means that you used blesh-git. The AUR package blesh-git always checks out the latest master branch regardless of the time when the package file is updated. Then, when you rerun yay -Sy blesh-git and select to overwrite the existing one, it will replace ble.sh with the latest master version.

Thank you very much for helping. But when i run yay -Sy blesh-git and trying use it, its not works ( . _ . ) For example all commits works, now i thinking problem comes when user, installs blesh with Yay or with another AUR/Package manger. Ooorr i messed up with something when i tested commits or installed with Yay.