Bug 709907

Summary:	bash 4.2 completion mishandles variables
Product:	[Fedora] Fedora	Reporter:	Don Lindsay <redhatbugzilla>
Component:	bash	Assignee:	Roman Rakus <rrakus>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	15	CC:	maxamillion, rrakus, tsmetana
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-06-07 11:06:26 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:

Description Don Lindsay 2011-06-01 22:51:49 UTC

Description of problem:

If I have an environment variable "foo" pointing at a directory, and type eg

   ls $foo/RE

and then hit TAB, I would expect it to look in $foo and find the name README. Which it does (even if the CWD does not contain such a name). So it looks as if bash really is searching in directory $foo. But then it transforms the line to:

   ls \$foo/README

and since the backslash makes the "$" literal, 'ls' says there is no such file.
This is wrong. Either the $ is literal or it isn't, but it's wrong to treat it both ways. The former (and desired) behavior was non-literal, ie expand $foo to its contents.




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

I upgraded Fedora from f14 to f15 and got bash-4.2.10-2.fc15.x86_64. This is from inside a gnome-terminal. My bashrc is unchanged, so if some controlling variable has been altered, it wasn't my doing.

Comment 1 Roman Rakus 2011-06-02 12:13:16 UTC


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

Comment 2 Don Lindsay 2011-06-02 19:06:19 UTC

No, it is not a duplicate of 679696. 

That bug questioned whether <tab> after $PWD should echo eg "/home/user". I have no such concern. I don't care what's echoed. 

Here is an example of the issue. I have variable $sk containing a directory name. In that directory is a file "susan.blackmore". I wish to list it. I type:

   ls $sk/susan<tab>

and I get

   ls: cannot access $sk/susan.blackmore: No such file or directory

I do not care about whether you echo expansions. I put the long, complicated directory name in a variable precisely because I didn't want to see it. I'm not interested in the directory. The focus is that I want to tell a filename to some tool, and you're generating an invalid representation.

What I care about is that "ls", "emacs", "rm" and so on are now giving me error messages when they didn't with previous bash releases. Unless you think that "ls", "emacs", and "rm" are the things that should be fixed, thus getting you off the hook ??

Comment 3 Roman Rakus 2011-06-07 11:06:26 UTC

(In reply to comment #2)
> No, it is not a duplicate of 679696. 
Yes it is
> 
> That bug questioned whether <tab> after $PWD should echo eg "/home/user". I
> have no such concern. I don't care what's echoed. 
> 
The bug is about tab completion. As well as this bug.
> Here is an example of the issue. I have variable $sk containing a directory
> name. In that directory is a file "susan.blackmore". I wish to list it. I type:
> 
>    ls $sk/susan<tab>
You see? Tab -> tab completion.
> 
> and I get
> 
>    ls: cannot access $sk/susan.blackmore: No such file or directory
Really? After hitting tab? I don't think so.
> 
> I do not care about whether you echo expansions. I put the long, complicated
> directory name in a variable precisely because I didn't want to see it. I'm not
> interested in the directory. The focus is that I want to tell a filename to
> some tool, and you're generating an invalid representation.
> 
> What I care about is that "ls", "emacs", "rm" and so on are now giving me error
> messages when they didn't with previous bash releases. Unless you think that
> "ls", "emacs", and "rm" are the things that should be fixed, thus getting you
> off the hook ??

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