Description of problem: Having a directory ~/xyz with a subdir called vb-2015-10-15_07:51:53-win10 This subdir has some entries: drwxrwxr-x 3 backes backes 4096 Oct 12 18:01 Machines drwx------ 4 backes backes 4096 Oct 15 06:59 VirtualBox VMs -rw------- 1 backes backes 20409483264 Oct 15 07:35 win10.vdi 1.cd ~/xyz. 2.ls -l vb-2015-10-15_07:51:53-win10/M<TAB> will not complete to vb-2015-10-15_07:51:53-win10/Machines No problem, if renaming vb-2015-10-15_07:51:53-win10 to vb-2015-10-15_07-51-53-win10 So it seems that the ":" in the filename "vb-2015-10-15_07:51:53-win10" is the culprit. The bash command "complete" gives no help! Version-Release number of selected component (if applicable): having a directory xyz with a subdir called vb-2015-10-15_07:51:53-win10 This subdir has some entries: drwxrwxr-x 3 backes backes 4096 Oct 12 18:01 Machines drwx------ 4 backes backes 4096 Oct 15 06:59 VirtualBox VMs -rw------- 1 backes backes 20409483264 Oct 15 07:35 win10.vdi 1.cd to xyz. 2.ls -l vb-2015-10-15_07:51:53-win10/M<TAB> will not complete to vb-2015-10-15_07:51:53-win10/Machines, and I don't understand, why. Is this a bug in the filename completetion? No problem, if renaming vb-2015-10-15_07:51:53-win10 to vb-2015-10-15_07-51-53-win10 So it seems that the ":" in the filename "vb-2015-10-15_07:51:53-win10" is the culprit. The bash command "complete" gives no help! How reproducible: always Steps to Reproduce: 1.See description 2. 3. Actual results: Expected results: Completion of M to Machines Additional info:
Same effect in F24!
I have not been able to reproduce this bug on F23 system with below packages : bash-4.3.42-3.fc23.x86_64 bash-completion-2.1-8.20150513git1950590.fc23.noarch On my system $IFS is not set. What is the value of $IFS on your system ?
(In reply to Siteshwar Vashisht from comment #3) > I have not been able to reproduce this bug on F23 system with below packages > : > > bash-4.3.42-3.fc23.x86_64 > bash-completion-2.1-8.20150513git1950590.fc23.noarch > > On my system $IFS is not set. What is the value of $IFS on your system ? On my system too, IFS is not set. Additionally, the f24 behaviour is exactly the same as in f23.
regrettably, it does not work for me!
(In reply to Joachim Backes from comment #6) > regrettably, it does not work for me! Hello Joachim, does it still not work for you with the rawhide version? Secondly, have you tried to reproduce the problem in VM with fresh Fedora Rawhide installation? Because this might be caused by some configuration you might have on your machine. We will need more info to determine if this is bug or not. Please, try reproducing the issue in the Virtual Machine first, and if the problem still persist, feel free to reopen this BZ. Thank you! Dee'Kej
(In reply to David Kaspar [Dee'Kej] from comment #7) > (In reply to Joachim Backes from comment #6) > > regrettably, it does not work for me! > > Hello Joachim, > > does it still not work for you with the rawhide version? > > Secondly, have you tried to reproduce the problem in VM with fresh Fedora > Rawhide installation? Because this might be caused by some configuration you > might have on your machine. > > We will need more info to determine if this is bug or not. Please, try > reproducing the issue in the Virtual Machine first, and if the problem still > persist, feel free to reopen this BZ. > > Thank you! > > Dee'Kej Hello David, I installed bash-4.4 from gnu.org (via the source in bash-4.4.tar.gz) to /usr/local/bin, and this bash runs flawlessly in a unchanged environment. So I guess some change has been made in the Fedora bash src against the original bash version, preventing the correct ':' interpretation.
Joachim, bash was rebased to version 4.4 in Fedora rawhide. I would suggest you to try bash-4.4 available from Fedora repositories.
(In reply to Siteshwar Vashisht from comment #9) > Joachim, > > bash was rebased to version 4.4 in Fedora rawhide. I would suggest you to > try bash-4.4 available from Fedora repositories. Same problem with bash-4.4.11-1.fc26.x86_64 !!
Ok, I will take a look at it again.
Do you see this problem only with completion for 'ls' command ? Is this reproducible while completing other commands ?
bash-4.3.43-4.fc25.x86_64 shows not the describes effects, so I think bash-4.3.43-4.fc25.x86_64 solves the issues.
I can't find any patches related to this bug that were shipped with bash-4.3.43-4.fc25.x86_64. So it's possible that changing some bash configuration may have fixed this issue. In any case, I am closing this bug.