Question: confusing behavior of built-in command completions like `cd`
Hello,
I and a few colleagues are currently working on adding Unicode (i.e., non-ASCII) natural language file/directory completion support for Bash and other shells.
Our method involves "hacking" (redefining and overriding) functions such as _comp_compgen_filedir or _comp_compgen__call_builtin. You can view a few existing solutions here:
- https://github.com/calsys456/bash-pinyin-completion-cpp/blob/main/scripts/bash_pinyin_completion
- https://github.com/muxueqz/bash-completion-pinyin.nim/blob/master/pinyin.completion
- https://github.com/AOSC-Dev/bash-pinyin-completion-rs/blob/main/scripts/bash_pinyin_completion
This approach currently works in environments using only bash-completion (without ble.sh), functioning correctly for both external commands and built-in commands being completed.
However, when using ble.sh, only external commands like ls and rmdir are completed correctly (while basic auto-completion functions as expected, see attached image). Built-in commands such as cd and pushd (which are highlighted as red by default in ble.sh), do not utilise our custom completion method. I also noted that other built-in commands (highlighted as purple by default in ble.sh) do not have this issue and work correctly with our custom completion.
above: only read named cd not works here
I am unsure what is special about the completion mechanism for built-in commands highlighted in red in ble.sh. Does it employ an implementation method different from standard bash-completion? I attempted to locate the relevant points by searching the source code but, unfortunately, was unsuccessful. I would greatly appreciate any explanation or assistance you can offer.
Thank you.
P.S. I know your native language is Japanese. I have heard that some people in Japan also desire similar completion functionality. I am personally re-implementing another Unicode completion scheme (see https://github.com/CicadaSeventeen/polLingua_Completion), which, unlike other implementations, focuses more on the possibility of supporting multiple natural languages instead of a single language. Although Japanese support is temporarily unavailable due to some difficulties, it should be supported in the future. However, this is another off-topic discussion.
Does it employ an implementation method different from standard
bash-completion?
Yes, they are implemented in the following part using the pure ble.sh API for completion (instead of the complete builtin of Bash).
https://github.com/akinomyoga/ble.sh/blob/2f564e636f7b5dd99c4d9793277a93db29e81adf/lib/core-complete.sh#L10531-L10742
P.S. I know your native language is Japanese. I have heard that some people in Japan also desire similar completion functionality.
Yeah, I also thought about a similar functionality and am still interested in it.
Although Japanese support is temporarily unavailable due to some difficulties, it should be supported in the future.
To get the romanized reading of a Japanese text, one may consider using a library of a category called 日本語形態素解析器, (though there seem to be many similar tools recently, and I'm not sure which one is better). A tricky part is that a single Japanese text may have multiple readings depending on the context, so one needs to find an analyzer that supports outputting multiple candidates.
A tricky part is that a single Japanese text may have multiple readings depending on the context,
I installed the most standard one, MeCab (mecab-git and mecab-ipadic-git), though I needed to edit Makefile for mecab-ipadic-git as described in the comment. With the following command, one may generate five possible analysis results in katakana (片仮名). Although the reading on the second line is wrong, it shouldn't affect the use case for generating possible candidates in shell completion. Then, the mapping from katakana to romaji (the alphabetical representation, like 拼音 in Chinese) is simple.
$ mecab -N 5 -O yomi <<< '関西学院大学' | uniq
カンセイガクインダイガク
カンセイガクインダイマナブ
Thanks a lot. I will make a update later
Hello. I have been working on it and now pinyin completion of commands like cd or pushd works. However, if I type in bash, for example
./tp
The pinyin completion does not work.
If this case is somehow different?
It's obvious that it's different. bash-completion doesn't provide completion for the command name, and the code that I pointed in the previous reply is clearly unrelated to the completion of command names. Please check the shell function ble/complete/source:command/.print-command in lib/core-compolete.sh.
Ops, I may have not explained clearly. ./tp here is not a command name. It is a file/dir name. That is like, when you type ./ and then type some string about files under current path ( PWD ), tab completion will provide completion for files.
I was talking about things like that.
The answer is essentially the same. Even if it is the directory name, the completion of the directory name at that position is not provided by bash-completion, so patching bash-completion doesn't affect it. It is obvious that you should look for another place. Within the ble.sh codebase, the completion of the directory name at the command position is handled in the shell function ble/complete/source:command/.print in lib/core-complete.sh.