From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29035 invoked by alias); 21 Jul 2015 20:12:45 -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: 35844 Received: (qmail 22282 invoked from network); 21 Jul 2015 20:12:40 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.0 X-Originating-IP: [80.3.228.158] X-Spam: 0 X-Authority: v=2.1 cv=JuUM15MC c=1 sm=1 tr=0 a=P+FLVI8RzFchTbbqTxIDRw==:117 a=P+FLVI8RzFchTbbqTxIDRw==:17 a=NLZqzBF-AAAA:8 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=94I4HS5TTZWfXccI-skA:9 a=CjuIK1q_8ugA:10 Date: Tue, 21 Jul 2015 21:07:01 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Unmetafy of getsparam() Message-ID: <20150721210701.457212d9@ntlworld.com> In-Reply-To: <150719011354.ZM18370@torch.brasslantern.com> References: <7277.1437023995@thecus.kiddle.eu> <14646.1437186782@thecus.kiddle.eu> <150718101725.ZM3963@torch.brasslantern.com> <18322.1437262124@thecus.kiddle.eu> <150719011354.ZM18370@torch.brasslantern.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 19 Jul 2015 01:13:54 -0700 Bart Schaefer wrote: > Here's a patch that attempts to clean up [un]metafication of non-special > parameter values used internally to the shell. Well, some of them. Seems to make sense. You can commit it now. (Oops...) > I'm unsure what to do with: > > - ENV in init.c -- for parsestr() is a tokenized string also metafied? The intention must surely be yes: parsestr() operates on internal strings way after the input stage, and indeed metafication occurs early in that, as witness zleread() returns a metafied line back to input.c (and so does shingetline() if ZLE is not in use), so it's already metafied by the time it hits the input stack --- so the string to be parsed needs to be metafied as it's put back on the input stack. Whether all pathways are correct is another question. > - untok_and_escape() in subst.c I think this has internal (metafied) strings at both input and output. > - spckword() in utils.c -- patcompile expects a metafied string? Yes, it does: I think spckword() gets a metafied string: zle_tricky.c isn't easily penestrable but that's because it's dealing with shell internal string, which should be metafied. > - all of hist.c is a mess with respect to handling of HISTFILE Yes, Mikael and I had extreme fun with this together with heckles from the crowd for added effect about our efforts to keep it consistent. (No doping allegations, at least...) Probably best left alone until something else turns up. > - getcvar() in math.c That's supposed to be handling it already within the function. > - savesession() in zftp.c This is all internal state, isn't it? So as long as it's consistent it doesn't matter. > - LISTPROMPT in complistmatches() That turns ultimately into the fmt used in compprintfmt, I think. This already seems to be prepared to handle metafied strings, though again whether it does so consistently may well not have been checked. > - MENUSELECT, MENUSCROLL, MENUMODE, MENUPROMPT in domenuselect() Look to me like they all go to places that have some sort of a metafied feel about them. I'm guessing something customisable like this is likely to have had a fair amount of kanji or katakana thrown at it by now. pws