scop
commented
5 years ago No ideas yet, but we have a history of issues with completions involving variables. In this case I don't think it's a matter of definedness; in your above case it's seemingly related to whether the path including the variable expands to a valid dir. If it does, then the backslashes appear; if it doesn't, they don't. For example:
$ unset foo
$ less /var/log/$foo/
Display all 103 possibilities? (y or n)
$ less /var/log/\$foo/$foo was unset, so /var/log/$foo/ expanded to /var/log// and offers the 103 files I have there. $foo got escaped. This is consistent with your test case.
$ foo=bar
$ less /var/log/$foo/No completions offered, /var/log/bar/ does not exist, $foo was not backslashed. Also consistent with your test case.
$ foo=apt
$ less /var/log/$foo/
eipp.log.xz history.log.3.gz term.log term.log.4.gz
history.log history.log.4.gz term.log.10.gz term.log.5.gz
history.log.10.gz history.log.5.gz term.log.11.gz term.log.6.gz
history.log.11.gz history.log.6.gz term.log.12.gz term.log.7.gz
history.log.12.gz history.log.7.gz term.log.1.gz term.log.8.gz
history.log.1.gz history.log.8.gz term.log.2.gz term.log.9.gz
history.log.2.gz history.log.9.gz term.log.3.gz $ less /var/log/\$foo/Contents of /var/log/apt/ offered as completions, $foo did get escaped, unlike in your test case.
Astara
Mark-Joy
SamB
In _quote_readline_by_ref, unset variables get escaped, whereas set variables don't, for instance:
Originally reported at https://bugs.debian.org/922657