starred directory completion

[mcepl]

I have a directory where a lot of subdirectories have the same long beginning of the name (names are generated by a program) like this:

home:mcepl:branches:OBS_Maintained:python
home:mcepl:branches:OBS_Maintained:python-aiosmtpd
home:mcepl:branches:OBS_Maintained:python-cryptography
home:mcepl:branches:OBS_Maintained:python-lxml
home:mcepl:branches:OBS_Maintained:python-nltk
home:mcepl:branches:OBS_Maintained:python-packaging
home:mcepl:branches:OBS_Maintained:python-pip
home:mcepl:branches:OBS_Maintained:python-python2-secrets
home:mcepl:branches:OBS_Maintained:python-recommonmark
home:mcepl:branches:OBS_Maintained:python-rpm-macros
home:mcepl:branches:OBS_Maintained:python-Sphinx
home:mcepl:branches:OBS_Maintained:python-sqlparse
home:mcepl:branches:OBS_Maintained:python27
home:mcepl:branches:OBS_Maintained:python3
home:mcepl:branches:OBS_Maintained:python3-lxml
home:mcepl:branches:OBS_Maintained:python3-setuptools
home:mcepl:branches:OBS_Maintained:python310
home:mcepl:branches:OBS_Maintained:python311
home:mcepl:branches:OBS_Maintained:python312
home:mcepl:branches:OBS_Maintained:python36
home:mcepl:branches:OBS_Maintained:python36-pip
home:mcepl:branches:OBS_Maintained:python39
home:mcepl:branches:OBS_Maintained:qrencode
home:mcepl:branches:OpenSSL3
home:mcepl:SLE-15-SP4
python.SUSE_SLE-15_Update

cd works perfectly well with *python3, but then I don’t know how to continue with completion. With fish I can just press TAB, it replaces that star-construct with home:mcepl:branches:OBS_Maintained:python3/ and I can continue with going through the hierarchy to the lower level, where I have similarly generated subdirectories like, so I would like to continue with auto-completion:

python3.SUSE_SLE-12_Update
python3.SUSE_SLE-15-SP3_Update
python3.SUSE_SLE-15_Update

ble.sh seems to be stuck there on that *python3, and I cannot complete any further. How can I configure ble.sh to work like fish? Or could it just continue with completion even on starred pattern like *python3?

[akinomyoga]

Can you set shopt -s failglob in your ~/.bashrc or ~/.blerc? With that setting, the TAB completion works as far as I test it in my environment.

As far as shopt -s failglob is not set, ble.sh doesn't know whether the star * input by the user is intended to be a wildcard (i.e., a special character for the pathname expansions) or a literal character '*'. Then, ble.sh assumes the conservative possibility of the literal-character interpretation to avoid aggressively rewriting the command line. When shopt -s failglob is set, ble.sh can safely assume that the star * input by the user would actually be a wildcard, so that it can attempt to perform the pathname expansions in the completion. The setting shopt -s failglob is actually consistent with Fish, where an unmatching glob pattern would cause an execution error.

However, somehow auto-complete doesn't seem to be working now in my environment even with shopt -s failglob. I'll later check the inside.

[mcepl]

Setting shopt -s failglob on the command line doesn’t change much, cd *python3 still works, and completion still doesn’t.

Setting it in ~/.bashrc has much more dire consequences. On the opening of terminal I get this error:

[sudo] heslo pro matej: 
tumbleweed-pkg:~ $ [ble: reload]
bash: no match: LS_COLORS='no=00;38;5;244:rs=0:di=00;38;5;33:ln=01;38;5;33:mh=00:pi=48;5;230;38;5;136;01:so=48;5;230;38;5;136;01:do=48;5;230;38;5;136;01:bd=48;5;230;38;5;244;01:cd=48;5;230;38;5;244;01:or=48;5;235;38;5;160:su=48;5;160;38;5;230:sg=48;5;136;38;5;230:ca=30;41:tw=48;5;64;38;5;230:ow=48;5;235;38;5;33:st=48;5;33;38;5;230:ex=01;38;5;64:*.tar=00;38;5;61:*.tgz=01;38;5;61:*.arj=01;38;5;61:*.taz=01;38;5;61:*.lzh=01;38;5;61:*.lzma=01;38;5;61:*.tlz=01;38;5;61:*.txz=01;38;5;61:*.zip=01;38;5;61:*.z=01;38;5;61:*.Z=01;38;5;61:*.dz=01;38;5;61:*.gz=01;38;5;61:*.lz=01;38;5;61:*.xz=01;38;5;61:*.bz2=01;38;5;61:*.bz=01;38;5;61:*.tbz=01;38;5;61:*.tbz2=01;38;5;61:*.tz=01;38;5;61:*.deb=01;38;5;61:*.rpm=01;38;5;61:*.jar=01;38;5;61:*.rar=01;38;5;61:*.ace=01;38;5;61:*.zoo=01;38;5;61:*.cpio=01;38;5;61:*.7z=01;38;5;61:*.rz=01;38;5;61:*.apk=01;38;5;61:*.jpg=00;38;5;136:*.JPG=00;38;5;136:*.jpeg=00;38;5;136:*.gif=00;38;5;136:*.bmp=00;38;5;136:*.pbm=00;38;5;136:*.pgm=00;38;5;136:*.ppm=00;38;5;136:*.tga=00;38;5;136:*.xbm=00;38;5;136:*.xpm=00;38;5;136:*.tif=00;38;5;136:*.tiff=00;38;5;136:*.png=00;38;5;136:*.svg=00;38;5;136:*.svgz=00;38;5;136:*.mng=00;38;5;136:*.pcx=00;38;5;136:*.dl=00;38;5;136:*.xcf=00;38;5;136:*.xwd=00;38;5;136:*.yuv=00;38;5;136:*.cgm=00;38;5;136:*.emf=00;38;5;136:*.eps=00;38;5;136:*.pdf=01;38;5;245:*.tex=01;38;5;245:*.rdf=01;38;5;245:*.owl=01;38;5;245:*.n3=01;38;5;245:*.tt=01;38;5;245:*.nt=01;38;5;245:*.log=00;38;5;240:*.bak=00;38;5;240:*.aux=00;38;5;240:*.bbl=00;38;5;240:*.blg=00;38;5;240:*.aac=00;38;5;166:*.au=00;38;5;166:*.flac=00;38;5;166:*.mid=00;38;5;166:*.midi=00;38;5;166:*.mka=00;38;5;166:*.mp3=00;38;5;166:*.mpc=00;38;5;166:*.ogg=00;38;5;166:*.ra=00;38;5;166:*.wav=00;38;5;166:*.axa=00;38;5;166:*.oga=00;38;5;166:*.spx=00;38;5;166:*.xspf=00;38;5;166:*.mov=01;38;5;166:*.mpg=01;38;5;166:*.mpeg=01;38;5;166:*.m2v=01;38;5;166:*.mkv=01;38;5;166:*.ogm=01;38;5;166:*.mp4=01;38;5;166:*.m4v=01;38;5;166:*.mp4v=01;38;5;166:*.vob=01;38;5;166:*.qt=01;38;5;166:*.nuv=01;38;5;166:*.wmv=01;38;5;166:*.asf=01;38;5;166:*.rm=01;38;5;166:*.rmvb=01;38;5;166:*.flc=01;38;5;166:*.avi=01;38;5;166:*.fli=01;38;5;166:*.flv=01;38;5;166:*.gl=01;38;5;166:*.axv=01;38;5;166:*.anx=01;38;5;166:*.ogv=01;38;5;166:*.ogx=01;38;5;166:';
tumbleweed-pkg:~ $ 

[akinomyoga]

Setting it in ~/.bashrc has much more dire consequences. On the opening of terminal I get this error:

That error is unrelated to ble.sh.

This happens when one writes the settings as eval $(dircolors ...) or eval `dircolor ...`, but this is not correct. They can be unexpectedly expanded by pathname expansions, or it can be transformed by a custom IFS. One should properly quote it as eval "$(dircolors ...)" (or eval "`dircolors ...`" but this form of the command substitution is deprecated by POSIX).

For this reason, I think you actually have the benefits of turning on failglob because you seem to find potential problems with your settings using failglob.

[mcepl]

Right, fixed. Thank you.

[mcepl]

Hmm, when I switch off dircolors (I don't actually need it, probably), I get completion working, somehow:

tumbleweed-pkg:~ $ ~/build/ihome/*python3/python3.SUSE_SLE-12_Update/
cd -- /home/matej/build/ihome/home:mcepl:branches:OBS_Maintained:python3/python3.SUSE_SLE-12_Update/
bash: no match: 1?1M
tumbleweed-pkg:python3.SUSE_SLE-12_Update $ 

What's that error about?

[akinomyoga]

Hmm, when I switch off dircolors (I don't actually need it, probably), I get completion working,

OK

bash: no match: 1?1M
tumbleweed-pkg:python3.SUSE_SLE-12_Update $ 

What's that error about?

I've been turning on failglob for about seven years with ble.sh, but I've never seen that error message with ble.sh. I suspect you have an unquoted word (1?1M or something like $(a command that outputs '1?1M')) somewhere in your setting or a framework that you use. Such unquoted words can be broken under some conditions, so these should be usually fixed.

[mcepl]

yeah, bug in openSUSE/osc#1379

[mcepl]

Hmm, still not working, https://asciinema.org/a/283uHlL0cbjtKeTwDCJrBdmsh

[akinomyoga]

So it is unclear what is the problem...

I initially thought that you are talking about the unexpected character "p" inserted by the completion, but it turned out that the p letter is actually what you've explicitly inserted. Then, I thought what you think is a problem might be that *python36 was not expanded, but it's actually the intended behavior of ble.sh; ble.sh keeps the original representation *python36 as far as the expanded result is consistent with the word suggested by the completion setting. Another possibility is that it is related to the last <TAB> you inserted by editing the reply. But it doesn't seem to be what can be demonstrated by the video because the video shows what happened but doesn't show what didn't happen.

[akinomyoga]

I'm not sure if it was your intent, but the last behavior is indeed strange. I'll check it.

[mcepl]

No, that p was meant as the beginning of the next level subdirectory (python3.SUSE_SLE-12_Update).

[akinomyoga]

I'm not sure if it was your intent, but the last behavior is indeed strange. I'll check it.

@mcepl I pushed commit 6a42695. Could you check the behavior?

[mcepl]

Yeah, seems to work. Thank you!