Bug 702329

Summary: bash completion for ordinary filenames has changed significantly - and dangerously
Product: [Fedora] Fedora Reporter: David Howells <dhowells>
Component: bash-completionAssignee: Ville Skyttä <ville.skytta>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 14CC: elad, martin.gieseking, rdieter, sheltren, ville.skytta
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-05-06 17:47:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
set -x trace of broken completion none

Description David Howells 2011-05-05 10:58:01 UTC
Description of problem:

The bash completion of ordinary filenames changes significantly with the installation of bash-completion-1.3-3 in Fedora 14.  When I type the partial name of a directory and press TAB, I expect it to expand the directory name and append a slash character, leaving the cursor ready to follow the next part of the path.

This has changed.  It now appends a space, which means the following character is now a separate argument.

Consider trying to remove the contents of a subdirectory.  I've got so used to doing:

    rm dir<TAB>*

in the expectation that this will expand to:

    rm directory/*

that I don't pause before pressing ENTER.  However, this now expands to:

    rm directory *

and so I lost a bunch of files (fortunately the current dir's contents were mostly under version control).

Version-Release number of selected component (if applicable):

yum.log:Apr 28 23:53:43 Updated: 1:bash-completion-1.3-3.fc14.noarch
yum.log-20110101:Oct 23 00:41:04 Updated: 1:bash-completion-1.2-4.fc13.noarch

Removing the bash-completion rpm and exec'ing bash cures the problem.

How reproducible:

100%

Steps to Reproduce:
1. Type "ls" followed by a partial subdir name and press TAB.
  
Actual results:

ls subdirectory<SPACE>

Expected results:

ls subdirectory/

Comment 1 David Howells 2011-05-05 11:05:56 UTC
Created attachment 497037 [details]
set -x trace of broken completion

Here's a "set -x" trace of me doing "ls pa<TAB>" expecting pa to expand to "patchset/", but instead getting "patchset ".

Comment 2 Elad Alfassa 2011-05-05 12:26:03 UTC
Works fine here (Fedora 15)



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 3 Martin Gieseking 2011-05-06 09:31:21 UTC
This issue is probably caused by /etc/bash_completion.d/acroread.sh
See here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616018

Comment 4 David Howells 2011-05-06 16:47:05 UTC
(In reply to comment #3)
> This issue is probably caused by /etc/bash_completion.d/acroread.sh
> See here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616018

Removing that file makes it work for me.  

That file belongs to the AdobeReader_enu-9.4.2-1.i486 package on my system.

That, however, was updated on the 15th of Feb, so there must be some interaction with bash-completion that changed when I upgraded that.

Comment 5 Jeff Sheltren 2011-05-06 17:47:30 UTC
Closing this as a duplicate since it seems like Acroread has struck again!

*** This bug has been marked as a duplicate of bug 677446 ***