akinomyoga
commented
4 years ago ご報告ありがとうございます! 実は正に 5f0d49f がこの問題に対する修正のつもりでした。現在こちらでは再現しないようです。お手数をおかけしてすみません。
（問題の切り分けが甘く，正確な再現方法が分かりません。申し訳ないです）
こちらで分かっている再現の条件についてご説明しますね。問題は、 4da6103 ～ 4760409 のバージョンを unload する時に発生します。
- 例えば commit A から commit B に
ble-updateをする時 A を unload してから B を load するのですが、この時 A 側が問題のあるバージョンの時にこのエラーメッセージが発生します。 - 或いは、commit A で
ble-reloadをする時、A を unload して再び A を load します。この時 A あ問題のあるバージョンの時にこのエラーメッセージが発生します。
この状況は 350bb15 から 5f0d49f に更新している最中
こちらの把握している範囲ですと、これは 350bb15 の側の問題で発生していると考えられます。
5f0d49f でも問題が持続しているかどうかを確かめる為には、 5f0d49f をロードしている状態で ble-reload を試していただけるとようございます。お手数をおかけしてすみませんが、この点だけ確認していただければ幸いです。
追記: 手許にあった 3 commits を push しました。 5f0d49f から ble-update して最新版 6e3b3b5 にする時にも問題が発生しなければもう大丈夫のはず…だと思います。
/run/user/1000/blesh/<PID?>.bind.save
因みに、このファイルは ble-attach する直前の Bash のキーバインディングの状態を記録しているファイルです。ble-detach (ble-attach 状態から抜ける関数) を実行して元の状態を復元する時に source します。このファイルは Bash の bind コマンドの出力を awk で加工して生成するのですが、Bash がバイナリデータを出力するので LC_CTYPE=C として置かないと awk がエラーメッセージを出力してしまうというのが問題です。4da6103 の修正で LC_ALL に環境変数属性が付かなくなったのが今回問題が発生するようになった経緯です。
cmplstofB
ble version: 0.4.0-devel2+5f0d49f Bash version: 5.0.3(1)-release
（問題の切り分けが甘く，正確な再現方法が分かりません。申し訳ないです）
ble.shは，
ble-update実行時などに，/run/user/1000/blesh/<PID?>.bind.saveというようなファイルを読み取っているようですが，その際に，という内容の警告が発生します（これは端末に表示されません）。 そして，恐らく転送の関係で，先程のファイル/run/user/1000/blesh/<PID?>.bind.saveにawkからの警告が書込まれてしまい，これを
ble-reload等が再び読み取ることで更に警告が生じています（この警告は端末に表示されます）。この状況は 350bb15 から 5f0d49f に更新している最中に気が付いたのですが， 350bb15 に戻しても，警告が端末に表示されないだけで，やはり同じ状況が生じているようです[※1]。
また，AWKの警告が書込まれている件のファイルの全体は次の2行です[※2]。
私が個人的に
C-@を何かに束縛した覚えはないですし，念の為bash --norcなどとして，Bashやble.shに関する個人設定を排除した状態でも，同じ様なヌル文字を含む行が当該ファイルに書込まれていました（また，AWKからの警告も同様に書込まれていました）。[※1]: 要は，AWKの警告がファイルに転送されていたので気が付かなかったが， 5f0d49f 周辺の更新で，AWKの（二回目の？）警告が端末に残るようになったので気が付いた，という訳です。
[※2]: この状況が生じる前の段階のファイルが残っていたので｟というかまだble.shの更新が効いていない別セッションのble.shがあったので｠，同じ「*.bind.save」という名前のファイルを閲覧してみたところ，「builtin bind ...」というキー束縛の定義が2行のみでなく大量に書込まれていました。勝手な憶測ですが，本来の挙動をしていると思います。