zsh-workers
 help / color / mirror / code / Atom feed
From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: Frank Terbeck <ft@bewatermyfriend.org>
Cc: zsh-workers@zsh.org
Subject: Re: vcs_info: '%' in payloads not escaped
Date: Fri, 6 Jan 2017 16:40:12 +0000	[thread overview]
Message-ID: <20170106164012.GB4948@fujitsu.shahaf.local2> (raw)
In-Reply-To: <87wpe8pj0o.fsf@ft.bewatermyfriend.org>

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


  reply	other threads:[~2017-01-06 16:43 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-27 15:05 Daniel Shahaf
2016-12-27 15:13 ` Daniel Shahaf
2017-01-05 16:07 ` Daniel Shahaf
2017-01-05 16:27   ` Frank Terbeck
2017-01-06  2:21     ` Daniel Shahaf
2017-01-06 10:41       ` Frank Terbeck
2017-01-06 16:40         ` Daniel Shahaf [this message]
2017-01-06 17:27           ` Bart Schaefer
2017-01-23 11:04             ` Daniel Shahaf
2017-01-23 18:54               ` Frank Terbeck
2017-02-05  8:28                 ` [PATCH] vcs_info: Escape '%' signs in payloads Daniel Shahaf
2017-02-07  8:57                   ` Daniel Shahaf
2017-01-06 15:55   ` vcs_info: '%' in payloads not escaped Bart Schaefer
2017-01-06 16:49     ` Daniel Shahaf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170106164012.GB4948@fujitsu.shahaf.local2 \
    --to=d.s@daniel.shahaf.name \
    --cc=ft@bewatermyfriend.org \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).