From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19577 invoked by alias); 14 Sep 2014 18:31:18 -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: 33169 Received: (qmail 24535 invoked from network); 14 Sep 2014 18:31:06 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 From: Bart Schaefer Message-id: <140914113029.ZM31296@torch.brasslantern.com> Date: Sun, 14 Sep 2014 11:30:28 -0700 In-reply-to: <140831135017.ZM739@torch.brasslantern.com> Comments: In reply to Bart Schaefer "Re: _expand_alias does not expand aliases that contain an "!"" (Aug 31, 1:50pm) References: <140830133206.ZM13172@torch.brasslantern.com> <140831135017.ZM739@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: _expand_alias does not expand aliases that contain an "!" MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Aug 31, 1:50pm, Bart Schaefer wrote: } Subject: Re: _expand_alias does not expand aliases that contain an "!" } } On Aug 30, 7:58pm, Jonathan H wrote: } } } } Oddly enough, for me _expand_alias works for all characters in } } [*#?@:+-^%$.,]. the only character that didn't work and wasn't already } } meaningful to the shell was the exclamation point. } } Hmm. Indeed, something is treating "!" as additionally special. The } interesting part is that it does not always treat the first character of } the $HISTCHARS variable as special, nor does it treat ! as special when } it is not the first character of $HISTCHARS. } } Or (more likely) internally somewhere is explicitly un-quoting file } expansion characters but is not doing so for history characters. This } could probably be fixed but might take a while to trace down. What this boils down to is that get_comp_string() calls the lexer to parse the word to be completed. Metacharacters like '*' and '?' get tokenized by the lexer, but the history character does not. Eventually callcompfunc() invokes multiquote() on the lexed word, which calls quotestring(), which does not re-quote the tokenized characters but does quote the history characters. (compcore.c:706) callcompfunc() then calls untokenize() and we end up with backslashes in front of history characters but not in front of pattern characters. I think that means the fix is as easy as the patch below; this doesn't seem to break history expansion, and I can't think of any other reason we'd want history enabled when performing word completion. The first hunk of the patch backs out the hack in 33069. There's a remaining, probably autoloading-related, weirdness, which is that _expand_alias doesn't work the first time you try it unless the completion system has already been invoked some other way (including by having tried _expand_alias at least once already). Tracing with _complete_debug shows that the first time through, a backslash is being inserted before '!' even though NO_banghist is in effect; but on the second and later attempts, there's no backslash. Puzzling. diff --git a/Completion/Base/Completer/_expand_alias b/Completion/Base/Completer/_expand_alias index 9064ce8..8240e41 100644 --- a/Completion/Base/Completer/_expand_alias +++ b/Completion/Base/Completer/_expand_alias @@ -25,8 +25,6 @@ else pre=(_main_complete - aliases) fi -[[ "$compstate[quoting]" = (single|double) ]] || word="${(Q)word}" - zstyle -s ":completion:${curcontext}:" regular tmp || tmp=yes case $tmp in always) sel=r;; diff --git a/Completion/compinit b/Completion/compinit index f9d2c57..dc84637 100644 --- a/Completion/compinit +++ b/Completion/compinit @@ -138,6 +138,7 @@ _comp_options=( unset NO_allexport NO_aliases + NO_banghist NO_cshnullglob NO_cshjunkiequotes NO_errexit