Re: Unexpected foo==bar errors

[Bart Schaefer <schaefer@brasslantern.com>]

On Feb 8,  4:52am, Mikael Magnusson wrote:
}
} On Sun, Feb 7, 2016 at 8:16 PM, Bart Schaefer <schaefer@brasslantern.com> wrote:
} [...]
} > } _tar:70 is
} > } tf=${~words[3]}
} >
} > Ooh, that's a fun one: (foo) is being taken as glob qualifiers, which is
} > a larger problem in this case than the expansion of "=".  Then because
} > globassign is off, the equals expansion (on the empty string) is done,
} > but the qualifiers are never applied to the result.

One potentially open question here is whether the value should be parsed
as a glob (qualifiers recognized) when no globbing is possible.

} > The only use of $tf as far as I can see is to do lookups in the cache.
} 
} Presumably at some point the given filename has to be interpreted so
} that it can give any completions at all, even if it's not cached?

On closer inspection yes, I'm wrong about this, $tf is passed to "tar -tf"
to list the contents of the tar file even if not found in the cache.

} I wonder if there's anywhere in the completion system that depends on
} EQUALS being set... But maybe we should just 2> /dev/null the
} assignment since tilde expansion also prints errors. (_zattr and _zip
} also have this issue, presumably there are other places as well).

Redirecting error would still leave $tf empty.  But there's no way to
cause process substitution [that is, <(...) >(...) and =(...) syntax]
to be applied to the result of parameter expansion, except by using
"eval" -- and of course globbing won't happen without GLOB_ASSIGN, so
the only reason for tf=${~words[3]} (and the other assignments in _tar
from lines 66-82) is to do tilde and equals expansion.