From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20262 invoked by alias); 13 Sep 2016 06:36:39 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 39304 Received: (qmail 3563 invoked from network); 13 Sep 2016 06:36:39 -0000 X-Qmail-Scanner-Diagnostics: from mail-pf0-f173.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.192.173):SA:0(0.0/5.0):. Processed in 0.906495 secs); 13 Sep 2016 06:36:39 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at brasslantern.com does not designate permitted sender hosts) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=NnWXGa/RuUUV5DFlxEqrNQiZzcf1pptGfIMbzCW5CeE=; b=H869//AFdZFNyaIquI9pXUm6VD72CxHENVTYD7P9Qax7Mn2MD88cD5NVS8+d4x7aXE xAC/r2lNtEMy4glaCc1uN2bD0ibMff9MwEiDtE4nQnLnIv8hNjLXThSbzjNiLJRFlan2 02MCEu6pliuesu48QW7vtGDTKkQhWUfMlcoVUexTSk1FtZt/nZMpOrxJjEH4Hi/oqfP4 8E4NQABHT8HgolXGbCnaIPJVn22+fD5A2UC4XQOzcIsfBkek5IjR9PY5qCs9AZQVkK3O vmwikEvko0TjIrHKkBf7EFkZjIz1s+VAuXeDXHmh6OeHdk4vzHOxiClZQRPTcMpDxBze NnQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=NnWXGa/RuUUV5DFlxEqrNQiZzcf1pptGfIMbzCW5CeE=; b=kg80NOp8xKGdebM7CoQ2wwyATZv7stQrmm1nfY6tb0iwEH1l0n5WfkBJEposaGExfA ABGFduRUKkF1INATmxsyp6RgwoOMSQ5SADcjh+qYOIBw+4zfggE5dZEvqG5i5T5qQdEj Flb8jDtYZ91H8wCoQWuUSh8q+gYvtlJNnkHtm1faVUB9hVNACUmyyyvYmxwrc52nOoYf aaw0lEuszAp3uUS47ibwxk/1676B1I3VM0L4O1zqeWvGzxqRl/sCbl0eosXScL74Qwdz iEBdozvTBW+9j6ks86GwyaIuXFikCucsUiG9f6uSQHA0G5e6LIAYLHQvowjFrNVMH69o mHVA== X-Gm-Message-State: AE9vXwPBtmW19MDkKBqVgClWFRYrPDIqOno8YYLswB8lsGQAgriuTyqyOQ/6yE3ocHHNqA== X-Received: by 10.98.100.73 with SMTP id y70mr40550574pfb.84.1473748129568; Mon, 12 Sep 2016 23:28:49 -0700 (PDT) From: Bart Schaefer Message-Id: <160912232853.ZM27002@torch.brasslantern.com> Date: Mon, 12 Sep 2016 23:28:53 -0700 In-Reply-To: <20160912230632.GA29577@fujitsu.shahaf.local2> Comments: In reply to Daniel Shahaf "Re: compset -q oddities" (Sep 12, 11:06pm) References: <20160911073031.GA19137@fujitsu.shahaf.local2> <160911191422.ZM21970@torch.brasslantern.com> <20160912230632.GA29577@fujitsu.shahaf.local2> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: compset -q oddities MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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.