Re: compset -q oddities

[Daniel Shahaf <d.s@daniel.shahaf.name>]

Bart Schaefer wrote on Mon, Sep 12, 2016 at 23:28:53 -0700:
> 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.
> 

I would have expected the second <TAB> press to do nothing, since that's
what it does if the _f compadd's "xyz" instead of "~~~".

> 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 \\\~\\\~\\\~.
> 

All this is fine.  It would also have been correct for the first level
of quoting not to occur, since «~~~» doesn't need command-line escaping.

> 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).

That condition quotes the tilde because isset(EXTENDEDGLOB) is true.
This makes sense as far as quotestring() is concerned, but when called
from completion, this causes the tilde to be quoted even though
${_comp_caller_options[extendedglob]} is unset.

Bypassing this by making _f restore options[extendedglob] before calling
compadd fixes a few cases with «compadd 'a~b'» and with «compadd '~~~'»
followed by «f ~~~<TAB>», but «f <TAB><TAB>» is still wrong: it gives
\\~~~ and then \\\~\~\~\\~~~.

The backslash in \\~~~ is probably added by quotestring() [despite
unsetting extendedglob] because the 'u==s' part of the condition is
true.  Perhaps making quotestring() not add that redundant first
backslash would workaround the issue, i.e., would cause the "wonkiness"
in comp*.c not to get triggered.

> } 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.
> 

Okay.

> 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.
> 

Something like this:

    sh -c "sh -c '<TAB>

The documentation of compset explicitly mentions that 'compset -q' might
be called recursively.

> However, on closer inspection I don't think there's actually anything
⋮
> $'...', so it's probably a spurious DPUTS.

Thanks for the detailed answer.

Daniel