Re: Serious tab completion bug

[Linda Walsh]

Chet Ramey wrote:

> Thanks for the report.  This isn't a bug; it's intentional behavior.  You
> have presented bash with an ambiguous situation: it doesn't know whether
> or not you want to look for a filename in the current directory or perform
> variable expansion.
>
> Bash assumes you want filename completion if there's an existing pathname
> matching the string you typed, so it treats your scenario as filename
> completion rather than variable expansion.
====
        But that's not what it does.

        If that was what it did, it would be great, but I agree with the
original poster.

if I am in "/tmp", and I try echo $HOME/<complete>, and the pathname
'$HOME' doesn't exist in /tmp, it will still quote it.

If I had a filename '$HOME' in my current directory, then what you
are saying makes sense -- it would try to match an existing path ('$HOME')
in /tmp before attempting to use it as a variable. 

But if there is no file named '$HOME' in /tmp, and $HOME has a pathname
*in it*, then bash should assume that I want the pathname *in* the
variable (since the path doesn't exist in /tmp) to be used in its 
expanded form.

In this situation, it is rare that file names begin with '$' (seen many
on Windows, but few on linux).  Defaulting to quoting, even when the file
name doesn't exist, is flawed.  As you say, bash doesn't know what  you
want, so it should do what you are telling it to do:  If I want the 
'$' quoted, I would use '$HOME' or \$HOME.  But unquoted, bash should
assume the most common case: that the user didn't want it quoted.

That *IS* what they typed in.  It would make as much since as
if I  typed in '$HOME' or \$HOME, and bash assumed the opposite of
what I typed there, as well.  Rather than assuming that the user
doesn't mean what they typed, bash's first choice should be to
to pick what they *did* type -- if not, then why not remove
backslashes that a user inserts (\$HOME) on the grounds that it
doesn't really know that the user might not be on a system with '\'
as a path separator, so better remove it so it doesn't inadvertently 
quote '$'.  

I do note that if '$foo' DOESN'T point to a path, then bash doesn't
quote it when doing path-expansion -- the opposite of what one might
expect (i.e. if they are doing pathname expansion, and '$foo' contains
a valid path component, then leave it (or put it in DQ's: "$foo" to keep
it 'integrous' wrt/spaces).

Can you explain why, in a possibly ambiguous situation, bash does
the opposite of what the user actually typed?