xspec is ignored when Bash option force_fignore is unset

[Maelan]

Describe the bug

For instance with vim completion; vim completion uses _comp_compgen_filedir_xspec, and ${_comp_xspecs[vim]} is equal to '*.@([ao]|so|...)' (meaning that vim completion should not suggest files matching *.a, *.o, *.so).

The xspec is seemingly ignored when Bash option force_fignore is unset. In other words, files matching *.a, *.o, *.so are suggested.

Perhaps _comp_compgen_filedir is affected too.

To reproduce

$ env -i bash --noprofile --norc
bash-5.2$ source ~/bash-completion/bash_completion
bash-5.2$ touch foo.{a,c,h}

bash-5.2$ vim foo.<tab><tab>
foo.c  foo.h                      <- GOOD BEHAVIOR

bash-5.2$ shopt -u force_fignore
bash-5.2$ vim foo.<tab><tab>
foo.a  foo.c  foo.h               <- BAD BEHAVIOR: foo.a should not be suggested

bash-5.2$ complete -f -X '*.@([ao]|so)' vim
bash-5.2$ vim foo.<tab><tab>
foo.c  foo.h                      <- GOOD BEHAVIOR (for comparison)

Expected behavior

Suggestions returned by bash-completion should not depend on the state of Bash option force_fignore.

As far as I understand, the FIGNORE feature of Bash is a post-filtering applied by Bash after the custom completion command (that is, bash-completion) has run, so both should be totally independent.

What’s even stranger is that the state of force_fignore is only relevant when there is only one suggestion, but in the repro case, several suggestions are returned after filtering (foo.c and foo.h).

Versions (please complete the following information)

• Operating system: Linux 6.9.5-arch1-1 (Archlinux)
• bash version: 5.2.26(1)-release
• bash-completion version: 2.14.0 (latest dev version, commit e209afb)

Debug trace

debug.txt

[akinomyoga]

This seems to be caused by compgen's behavior.

$ compgen -d
$ shopt -u force_fignore
$ compgen -d
foo.a
foo.c
foo.h

[Maelan]

Well spotted! However I believe your finding with compgen -d is due to a (possibly related, but) different bug of Bash with force_fignore: it only happens when the current directory contains no directory (hence there is no match returned for -d). Do mkdir some_dir and try again to see the difference. This bug seems specific to -d, I could not translate it to -f, at least the following matches expectations:

$ env -i bash --noprofile --norc
bash-5.2$ ls
foo.a  foo.c  foo.h

bash-5.2$ compgen -f -X '*.[aoc]' foo
foo.h
bash-5.2$ compgen -f -X '*.[aoch]' foo
(no completion, as expected)

bash-5.2$ shopt -u force_fignore
bash-5.2$ compgen -f -X '*.[aoc]' foo 
foo.h
bash-5.2$ compgen -f -X '*.[aoch]' foo
(no completion, as expected)

Which shows this is a different bug than the one I originally reported above (and which also happens when the current directory contains a directory).

On the other hand, your finding might be a hint that the FIGNORE / force_fignore feature of Bash might be broken in possibly several ways, and that bash-completion would not be to blame. I would believe it, because there are no occurrences of fignore in the whole bash-completion code base, and no reason I can imagine for force_fignore to make a difference in my original repro case. Even so, we should manage to reduce that repro case in order to pinpoint the exact bug in Bash, and to file a proper bug report upstream.

[akinomyoga]

Which shows this is a different bug than the one I originally reported above

My previous example is obtained by reducing the reported behavior in bash-completion. The generators filedir and filedir_xspec of bash-completion call compgen -d to generate directory names.

(and which also happens when the current directory contains a directory).

Please check the behavior of compgen -d -- foo for the case where the current directory contains subdirectories (not matching foo).

[akinomyoga]

https://lists.gnu.org/archive/html/bug-bash/2024-07/msg00054.html

[akinomyoga]

The fix was already merged in the upstream Bash. It will be released in Bash 5.3. Although the problem isn't fixed in Bash <= 5.2, the problem is rather minor and only happens with a custom setting shopt -u force_fignore. Let me close the issue.