Re: compset -q oddities

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sep 12, 11:06pm, Daniel Shahaf wrote:
} Subject: Re: compset -q oddities
}
} Thanks, but I don't understand how any of those examples constitutes
} a "pilot error" or an empty word.

Some clarification, then:

} In #1, "~~~" is a complete word; completion changed it to "~~~~~~" which
} is also a complete word but wasn't a candidate completion.

You didn't start from ~~~.  You started from an empty word and typed
TAB twice.  ~~~ was never on the line.  I concur that the result of
the second attempt is weird, I would have expected it just to fail.

On the first tab (empty word), the prefix is empty but "compset -q"
causes completion to believe there is quoting on the line (backslash
by default).  The compadd call makes ~~~ a valid completion, which
when added is quoted to \~\~\~.  The effect of compset is then undone,
meaning the backslash-quoting that was presumed removed is restored,
and you end up with \\\~\\\~\\\~.

On the second tab, one level of quoting is removed by compset to get
\~\~\~ as the prefix.  Again compadd inserts \~\~\~ which does match
the prefix, so it's a valid completion, but somewhere along the line
all the \~ go back to \\\~ and now \~ doesn't match any more and so
instead of being discarded because it's already present in the prefix,
it gets appended and you end up with \\\~\\\~\\\~\\\~\\\~\\\~.

This happens for any compadd containing a tilde, it doesn't have to
be the first character in the word.  So something wonky is going on
with the handlng of tildes.  Actually the same thing happens with a
leading "=" (tilde can be anywhere), so it's quotestring() that is
contributing to the mahem (the large "else if" condition on lines
5824-5836).

} In #2 and #3, the input is a prefix of a valid command line ("g
} $'\'foo\''" and "h "$'foo'"" respectively).

No, that's not what I meant.  The *word* being completed is meant to
be a partial command line, not the whole buffer.  I know that the doc
says "split on spaces into separate words, respecting the usual shell
quoting conventions" but the implementation calls set_comp_sep() which
"splits the current word as if it were a command line".  But read on.

} #2 does not involve an
} empty word; the word there is "'" (a single-byte word).

Also not quite true; the word in both #2 and #3 is an un-closed quoted
string.  The result of that parse is not well-defined.

I also don't know any circumstance in which it would be correct to call
"compset -q" twice in succession as you did in #3.

However, on closer inspection I don't think there's actually anything
wrong with the results if the debug warnings are ignored, unlike the
case with #1.

} Thanks again for the explanation.  I'd like to understand what the
} expected behaviour here is.  They triggered DPUTS calls so I assumed
} they were bugs.

This one --

    compcore.c:1657: expecting 'x' at offset 2 of "'x"

-- seems to be a legit problem with counting bytes when looking for an
unbalanced $'...'.  I don't think fixing that would change the outcome,
that is $'\' --> \' (see quoting converted, above).  I'm not confident
of how to fix it; PWS was last here in workers/22026 (git 34381548).

For this --

    utils.c:6826: BUG: unterminated $' substitution

-- my line numbers seem to be off-by-20 from yours, but its the same
commit as the previous bug, and it's correct about the unterminated
$'...', so it's probably a spurious DPUTS.