From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16016 invoked by alias); 6 Jan 2017 16:43:32 -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: 40283 Received: (qmail 22505 invoked from network); 6 Jan 2017 16:43:32 -0000 X-Qmail-Scanner-Diagnostics: from out2-smtp.messagingengine.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(66.111.4.26):SA:0(-0.7/5.0):. Processed in 1.216608 secs); 06 Jan 2017 16:43:32 -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.7 required=5.0 tests=RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= daniel.shahaf.name; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= mesmtp; bh=zYpf1SmtdJgX0h1lCW7jdPudTFI=; b=tzVtrult0B0C9BwErGTOe 9A27+ufR/+YcSJZHPCT33XyRHDszKutduckux/eLk293ipQN0mt2UWZh3tkdIkdo upckXhkg3HyHk/7x6JYUdap0iUNw5grmffo5AAUnuhbOlAUgxCj2oNy8twRjdrD+ 6BU8LoXQ0IDfaj8C8YBsQ0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=zYpf1SmtdJgX0h1lCW7jdPudTFI=; b=ZId3giCgMi8IpLCH4JPc 1xEAkGnTlK7zf1ayMDYiTmigYu2oDcpf950CE6Pa/TQJ8BBhRGZRToKbDz+aSvfw wkB7bdy8t6yPwXdKJnw8Xj2UHfPo5fS/ZrVVnN0kpqmAM16dC/WLx9BhSZAHeivT 4yBnrTn78iBYD3q6g9NMFCI= X-ME-Sender: X-Sasl-enc: UVXHtupj9tmflOQCCBbxdYdbPYHkgaaqxTqcGNc623Lv 1483721007 Date: Fri, 6 Jan 2017 16:40:12 +0000 From: Daniel Shahaf To: Frank Terbeck Cc: zsh-workers@zsh.org Subject: Re: vcs_info: '%' in payloads not escaped Message-ID: <20170106164012.GB4948@fujitsu.shahaf.local2> References: <20161227150507.GA20351@fujitsu.shahaf.local2> <20170105160730.GA21106@fujitsu.shahaf.local2> <871swhqxph.fsf@ft.bewatermyfriend.org> <20170106022128.GA6197@fujitsu.shahaf.local2> <87wpe8pj0o.fsf@ft.bewatermyfriend.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87wpe8pj0o.fsf@ft.bewatermyfriend.org> User-Agent: Mutt/1.5.23 (2014-03-12) Frank Terbeck wrote on Fri, Jan 06, 2017 at 11:41:59 +0100: > Daniel Shahaf wrote: > > Frank Terbeck wrote on Thu, Jan 05, 2017 at 17:27:06 +0100: > [...] > >> I honestly don't know. Isn't this like kind-of-predictable behavior > >> versus a — potentially — a lot of special cases? I don't think that it's > >> possible to get this right in the general case. It's in-band data that > >> is indistinguishable from data that is interpreted by something that > >> interprets zsh's prompt language. > > > > A lot of special cases, how? $git_applied_s contains a string derived > > from git, so we know that any and all percent signs in it need escaping. > > The percent characters need escaping if the result is to be used in zsh > prompts. In other cases, like tmux window titles, they don't. But maybe > the hash sign (#) does, over there. > > I think this is already non-trivial in zsh itself, because there may be > uses that exceed prompts. But in the general case, I don't think its > possible. Well, of course I'm not going to write an escape function that produces a string that can be inserted, verbatim, into any context. That's mathematically impossible. However, I do think this problem is solvable. The string we produce in $vcs_info_msg_N_ should have a defined escaping. I would suggest to define that that string is prompt-escaped — which would be consistent with existing code, such as . precmd() { print -Plr -- ${vcs_info_msg_0_} ${vcs_info_msg_1_} } . and . setopt promptsubst PS1='${vcs_info_msg_0_}%# ' . — and then, if people want to use that string in tmux, they can: . 1 local tmux_command 2 print -v tmux_command -Pr -- $vcs_info_msg_0_ 3 tmux set-option set-titles-string ${vcs_info_msg_0_//'#'/##} All of these code excerpts work today, and I will commit no patch that breaks either of them. So I'm still not sure what your concern is. Suppose, for example, the string that is to be printed is "Lorem ipsum 50% Foo#Bar". In this case, after `vcs_info` returns, $vcs_info_msg_0_ is set to "Lorem ipsum 50%% Foo#Bar"; the `print -v -Pr` de-doubles the percent; and line three escapes the hash sign. Perfectly predictable, well-defined, consistent, generalizable, and all those other good adjectives... isn't it? Cheers, Daniel