[gawk 5.4.0] Bug in ambiguous completion with GNU Awk 5.4.0

[0xhtml]

GNU bash, version 5.3.9(1)-release (x86_64-pc-linux-gnu) [Arch Linux]
ble.sh, version 0.4.0-devel4+32bb63da (noarch) [git 2.52.0, GNU Make 4.4.1, GNU Awk 5.4.0, API 4.0, PMA Avon 8-g1, (GNU MPFR 4.2.2, GNU MP 6.3.0)]
bash-completion, version 2.17.0 (hash:480ffcc6a751e55621ec526eb5dea7a0d86d9e72, 17877 bytes) (noarch)
locale: LANG=de_DE.UTF-8
terminal: TERM=foot wcwidth=16.0-west/16.0-2+ri, foot:12500 (1;012500;0)
options: +extglob -hostcomplete +inherit_errexit

An update to GNU Awk from 5.2.3 to 5.4.0 breaks the completion of file names. Pressing tab on ambiguous completion no longer shows the file list (if configured through bleopt complete_ambigous=) but picks the first completion option instantly. Downgrading awk fixes the problem. Not sure if the bug is in awk or blesh uses some functionality of GNU awk that changed in the release.

[akinomyoga]

Thanks for the report, but I cannot reproduce the problem in my Arch Linux with gawk 5.4.0 (and other updates coming with sudo pacman -Syu). This is my setup:

GNU bash, version 5.3.9(1)-release (x86_64-pc-linux-gnu) [Arch Linux]
ble.sh, version 0.4.0-devel4+2f564e63 (noarch) [git 2.53.0, GNU Make 4.4.1, GNU Awk 5.4.0, API 4.1, PMA Avon 8-g1, (GNU MPFR 4.2.2, GNU MP 6.3.0)]
bash-completion, version 2.17.0 (hash:480ffcc6a751e55621ec526eb5dea7a0d86d9e72, 17877 bytes) (noarch)
locale: LANG=ja_JP.UTF-8
terminal: TERM=xterm-256color wcwidth=16.0-emacs, contra:0 (99;0)
options: -emacs +vi +extglob +failglob +histappend +histreedit -hostcomplete +inherit_errexit +progcomp_alias

# edit: The above was ble.sh 2f564e63. I also confirmed that the problem doesn't arise with 32bb63da.

I tried both bleopt complete_ambiguous=1 (turn on the ambiguous completion, default) and bleopt complete_ambiguous= (turn off the ambiguous completion), but both show the file list when there are multiple candidates. I also rebuilt ble.sh using the new gawk, but the behavior doesn't change. I took the diff of the ble.sh build result between the one built with Gawk 5.3.2 and the one built with Gawk 5.4.0, but there is no difference except for the Gawk version number embedded in the main file ble.sh.

Maybe I do not correctly understand what you mean by "Pressing tab on ambiguous completion". Could you describe the concrete situation of "Pressing tab on ambiguous completion"? What is the file list of the current directory, and what are the command-line contents where you attempted the completion?

$ ls
<what is the result?>
$ <what is the command line to reproduce the behavior?>[tab]

[0xhtml]

With the following setup. (| to indicate cursor position)

/tmp/dir$ ls -lA | tail -n+2 | awk '{print $1, $9}'
drwxr-xr-x a
drwxr-xr-x b
drwxr-xr-x c
-rw-r--r-- x
-rw-r--r-- y
-rw-r--r-- z
/tmp/dir$ ls |

Pressing TAB with GNU Awk 5.4.0 I get

/tmp/dir$ ls z |

With the GNU Awk 5.2.0 I got

/tmp/dir$ ls |
a   b   c   x   y   z

The bug is present when switching out GNU Awk at runtime. I use the following build: https://builds.garudalinux.org/repos/chaotic-aur/x86_64/blesh-git-0.4.0_devel4.r2307.32bb63da-1-any.pkg.tar.zst

My .blerc

bleopt highlight_syntax=
bleopt highlight_filename=
bleopt highlight_variable=
bleopt complete_auto_delay=100
bleopt complete_ambiguous=
bleopt complete_menu_complete=
bleopt complete_menu_filter=
bleopt exec_elapsed_mark=
bleopt exec_exit_mark=
bleopt edit_marker=
bleopt edit_marker_error=
bleopt history_share=1
ble-face auto_complete=fg=61

Some lines from my .bashrc:

HISTSIZE=-1
HISTFILESIZE=-1
HISTCONTROL=erasedups

bind 'set mark-symlinked-directories on'
bind 'set match-hidden-files off'

[akinomyoga]

Thank you. I could reproduce the phenomenon. I believe this is a Gawk bug. I also confirmed the bug with gawk I built from the tarball gawk-5.4.0.tar.xz myself in Fedora. See the following reduced cases (without ble.sh):

$ gawk-3.0.6 '{ print gensub(/"([^[:blank:]]*)"/, "[\\1]", "g", $0) }' <<< '"a" "b" "c"'
[a] [b] [c]
$ gawk-3.1.8 '{ print gensub(/"([^[:blank:]]*)"/, "[\\1]", "g", $0) }' <<< '"a" "b" "c"'
[a] [b] [c]
$ gawk-4.0.2 '{ print gensub(/"([^[:blank:]]*)"/, "[\\1]", "g", $0) }' <<< '"a" "b" "c"'
[a] [b] [c]
$ gawk-4.1.4 '{ print gensub(/"([^[:blank:]]*)"/, "[\\1]", "g", $0) }' <<< '"a" "b" "c"'
[a] [b] [c]
$ gawk-4.2.0 '{ print gensub(/"([^[:blank:]]*)"/, "[\\1]", "g", $0) }' <<< '"a" "b" "c"'
[a] [b] [c]
$ gawk-5.0.1 '{ print gensub(/"([^[:blank:]]*)"/, "[\\1]", "g", $0) }' <<< '"a" "b" "c"'
[a] [b] [c]
$ gawk-5.3.0 '{ print gensub(/"([^[:blank:]]*)"/, "[\\1]", "g", $0) }' <<< '"a" "b" "c"'
[a] [b] [c]
$ gawk-5.3.1 '{ print gensub(/"([^[:blank:]]*)"/, "[\\1]", "g", $0) }' <<< '"a" "b" "c"'
[a] [b] [c]
$ gawk-5.3.2 '{ print gensub(/"([^[:blank:]]*)"/, "[\\1]", "g", $0) }' <<< '"a" "b" "c"'
[a] [b] [c]
$ gawk-5.4.0 '{ print gensub(/"([^[:blank:]]*)"/, "[\\1]", "g", $0) }' <<< '"a" "b" "c"'
[a] [] []

[0xhtml]

Ok, doing a git bisect of GNU Awk right now.

[0xhtml]

The git history unfortunately squashed a huge amount of commits, so I can't really pin down the issue more than this commit: 7e4f53ae2790f8138a3804c509605e4e8c3aea7f. But it's definitely related to the new regex engine introduced.
Setting the environment variable GAWK_GNU_MATCHERS as described in README_d/README.matchers fixes the problem.

[akinomyoga]

Thank you. I reported it to the upstream Gawk, and the developer created a patch:

https://lists.gnu.org/archive/html/bug-gawk/2026-02/msg00038.html

Setting the environment variable GAWK_GNU_MATCHERS as described in README_d/README.matchers fixes the problem.

Thank you for the information. That seems very useful to work around the problem.

[raeraex2]

I experienced this bug and just found this issue about it. Thanks for the work around!

[akinomyoga]

I added a workaround in commit 40cc576.

[akinomyoga]

The confirmation for the workaround has been provided in #677 (comment). Let me close the issue.