Bug 1272038 - Problem with bash filename completetion with <TAB> if the filename stub contains colon chars
Problem with bash filename completetion with <TAB> if the filename stub conta...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: bash (Show other bugs)
24
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Siteshwar Vashisht
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-15 06:38 EDT by Joachim Backes
Modified: 2017-05-11 06:55 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-05-11 06:55:53 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Joachim Backes 2015-10-15 06:38:18 EDT
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:
Comment 2 Joachim Backes 2016-04-05 06:13:43 EDT
Same effect in F24!
Comment 3 Siteshwar Vashisht 2016-05-08 10:12:52 EDT
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 ?
Comment 5 Joachim Backes 2016-05-08 13:25:10 EDT
(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.
Comment 6 Joachim Backes 2017-02-12 05:47:19 EST
regrettably, it does not work for me!
Comment 7 David Kaspar [Dee'Kej] 2017-02-12 19:50:49 EST
(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
Comment 8 Joachim Backes 2017-02-13 01:28:45 EST
(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.
Comment 9 Siteshwar Vashisht 2017-02-13 01:37:22 EST
Joachim,

bash was rebased to version 4.4 in Fedora rawhide. I would suggest you to try bash-4.4 available from Fedora repositories.
Comment 10 Joachim Backes 2017-02-13 01:49:16 EST
(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 !!
Comment 11 Siteshwar Vashisht 2017-02-13 01:51:37 EST
Ok, I will take a look at it again.
Comment 12 Siteshwar Vashisht 2017-05-11 06:05:06 EDT
Do you see this problem only with completion for 'ls' command ? Is this reproducible while completing other commands ?
Comment 13 Joachim Backes 2017-05-11 06:42:31 EDT
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.
Comment 14 Siteshwar Vashisht 2017-05-11 06:55:53 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.