Hide Forgot
We've been debugging an issue in bash-completion at https://github.com/scop/bash-completion/issues/15 . Not sure if this is a bash or deeper issue, but let's start here. Here's a reduced test case: $ [[ A =~ [A?-=] ]] && echo hello In my rawhide mock x86_64 chroot running on F-23 x86_64, the regex does NOT match. In the F-23, CentOS 7, Ubuntu 14, and FreeBSD 11 boxes I've tested, it matches. The OP of the GitHub issue is running Slackware current, and it apparently does NOT match there. A somewhat troubling finding is that in the GitHub discussion, praiskup reported that the regexp DOES match in his mock setup which as far as I can tell is practically identical with mine. Now, the regex might be kind of faulty, as changing it to this produces consistent, matching results in all setups I've tried: $ [[ A =~ [A?=-] ]] && echo hello So inside the character class, the order of = and - was swapped. The intent of the regex (both original and this modified one) is to match ?, = and - as individual characters, not the character range from ? to =. If the expression ?-= gets treated as a character range, in my opinion the original regex should have matched everywhere. If not, maybe it causes the regex to be invalid? If so, shouldn't there be an error message about it? And any ideas what causes the inconsistency between setups?
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'.
bash uses regexec() function to match regular expressions. Did you notice if the result was dependent on version of glibc that was running on the system ?
Because the systems listed in the initial comment vary so much, I'm fairly certain that the version of glibc between them varies as well, and I'm not sure if FreeBSD uses glibc in the first place. But I don't have any more specific information about the differences than this.
I have not been able to reproduce this bug on either Fedora Rawhide or F25 systems. As per comment 3 and comment 4, I assume this bug was caused by different versions of glibc.
Redirected here by googling for 'slow bash completion for tar' with detour through the source github issue. Could this please be re-opened? I'm using a fully updated F25, and in summation this is fast: My working dir: $ ls -1 *xz file1.tar.xz file2.tar.xz $ tar xf file<tab><tab><tab> never completes $ tar -xf file<tab><tab><tab> completes immediately $ rpm -q glibc bash-completion glibc-2.24-4.fc25.x86_64 bash-completion-2.5-1.fc25.noarch It appears F25 already has the correct regex according to https://github.com/scop/bash-completion/commit/0b7189d4eee4597e11cab02e6b4dcae488db5ca8 $ grep -n blank /usr/share/bash-completion/completions/tar | grep space 108: ^[[:blank:]]{1,10}(((,[[:blank:]])?(--?([\]\[a-zA-Z0-9?=-]+))(,[[:space:]])?)+).*$ ]]; then
Not reproduced on F25: $ rpm -q bash-completion bash tar bash-completion-2.5-1.fc25.noarch bash-4.3.43-4.fc25.x86_64 tar-1.29-3.fc25.x86_64
And glibc: $ rpm -q glibc glibc-2.24-4.fc25.x86_64 glibc-2.24-4.fc25.i686
Any suggestions on debugging further? Otherwise I'll just fix up my muscle memory to use tar -xf
I don't have anything else besides the generic bash-completion troubleshooting instructions, see Troubleshooting in its README.md.
When the Troubleshooting produces "too verbose" output, I usually edit the completion file /usr/share/bash-completion/completions/tar manually: - add my_debug() { echo "$*" >> /tmp/debug_info ; } - put "my_debug info messages" on proper places Then: - in one terminal test the completion - in another terminal put `tail -F /tmp/debug_info` and read the debugging info
I am closing this bug as there has been no updates on it. Feel free to reopen if required.