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.
*** This bug has been marked as a duplicate of bug 679696 ***
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 ??
(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 ***