Acknowledgement sent
to Vincent Lefevre <[email protected]>:
New Bug report received and forwarded. Copy sent to Debian X Strike Force <[email protected]>.
(Thu, 08 Nov 2018 15:54:04 GMT) (full text, mbox, link).
Subject: xterm: exec-formatted yields a tilde character in zsh and emacs
Date: Thu, 8 Nov 2018 16:51:28 +0100
Package: xterm
Version: 337-1
Severity: normal
In my XTerm configuration, I have:
*VT100*translations: #override \n\
Meta<Btn1Down>: exec-formatted("browser %s", PRIMARY)
The problem is that when exec-formatted is invoked from zsh or emacs
(when run in xterm, e.g. with "emacs -nw"), a ~ character appears.
Other shells such as dash, bash and ksh are not affected. Curses
applications such as mutt and tack are not affected either.
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.18.0-2-amd64 (SMP w/12 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages xterm depends on:
ii libc6 2.27-8
ii libfontconfig1 2.12.6-0.1
ii libfreetype6 2.6.3-3.2
ii libice6 2:1.0.9-2
ii libtinfo6 6.1+20181013-1
ii libutempter0 1.1.6-3
ii libx11-6 2:1.6.7-1
ii libxaw7 2:1.0.13-1+b2
ii libxft2 2.3.2-2
ii libxinerama1 2:1.1.4-1
ii libxmu6 2:1.1.2-2
ii libxpm4 1:3.5.12-1
ii libxt6 1:1.1.5-1
ii xbitmaps 1.1.1-2
Versions of packages xterm recommends:
ii x11-utils 7.7+4
Versions of packages xterm suggests:
pn xfonts-cyrillic <none>
-- no debconf information
On Thu, Nov 08, 2018 at 04:51:28PM +0100, Vincent Lefevre wrote:
> Package: xterm
> Version: 337-1
> Severity: normal
>
> In my XTerm configuration, I have:
>
> *VT100*translations: #override \n\
> Meta<Btn1Down>: exec-formatted("browser %s", PRIMARY)
>
> The problem is that when exec-formatted is invoked from zsh or emacs
> (when run in xterm, e.g. with "emacs -nw"), a ~ character appears.
>
> Other shells such as dash, bash and ksh are not affected. Curses
> applications such as mutt and tack are not affected either.
I don't see how this could happen unless you combined the action with
some pasting (such as bracketed-paste). xterm's formatting of the
string is shell-agnostic, and the exec'd "browser" command would only
depend on what the formatted URL looked like.
In either case, steps-to-reproduce seem obscure.
--
Thomas E. Dickey <[email protected]>
https://invisible-island.netftp://ftp.invisible-island.net
Acknowledgement sent
to Vincent Lefevre <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <[email protected]>.
(Sat, 24 Nov 2018 23:12:03 GMT) (full text, mbox, link).
Subject: Re: Bug#913237: xterm: exec-formatted yields a tilde character in
zsh and emacs
Date: Sun, 25 Nov 2018 00:08:03 +0100
On 2018-11-21 19:02:33 -0500, Thomas Dickey wrote:
> I don't see how this could happen unless you combined the action with
> some pasting (such as bracketed-paste).
I paste nothing.
> xterm's formatting of the string is shell-agnostic, and the exec'd
> "browser" command would only depend on what the formatted URL looked
> like.
>
> In either case, steps-to-reproduce seem obscure.
With zsh, one can reproduce the issue with:
$ xterm -e zsh -f
then in the xterm:
zira% bindkey -e
What's strange is that in the Xterm log, I can get either ^G~, or
just ~, or nothing.
--
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
On Sun, Nov 25, 2018 at 12:08:03AM +0100, Vincent Lefevre wrote:
> On 2018-11-21 19:02:33 -0500, Thomas Dickey wrote:
> > I don't see how this could happen unless you combined the action with
> > some pasting (such as bracketed-paste).
>
> I paste nothing.
>
> > xterm's formatting of the string is shell-agnostic, and the exec'd
> > "browser" command would only depend on what the formatted URL looked
> > like.
> >
> > In either case, steps-to-reproduce seem obscure.
>
> With zsh, one can reproduce the issue with:
>
> $ xterm -e zsh -f
If you added a "-l" option, that would turn on xterm's logging feature
xterm -l -e zsh -f
which could be interesting. But the bug report deals with programs
run from xterm, which the shell wouldn't see -- unless it's reading
xterm's output in some way.
>
> then in the xterm:
>
> zira% bindkey -e
Perhaps "zira%" is your shell prompt.
What does "bindkey -e" have to do with exec-formatted?
--
Thomas E. Dickey <[email protected]>
https://invisible-island.netftp://ftp.invisible-island.net
Acknowledgement sent
to Vincent Lefevre <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <[email protected]>.
(Tue, 27 Nov 2018 09:00:06 GMT) (full text, mbox, link).
Acknowledgement sent
to Vincent Lefevre <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <[email protected]>.
(Wed, 05 Dec 2018 09:00:06 GMT) (full text, mbox, link).
Subject: Re: Bug#913237: xterm: exec-formatted yields a tilde character in
zsh and emacs
Date: Wed, 5 Dec 2018 09:58:21 +0100
On 2018-12-04 21:50:47 -0500, Thomas Dickey wrote:
> That looks as expected, if you've got two different things writing to
> the terminal at the same time:
>
> https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Bracketed-Paste-Mode
So, perhaps I can see something with zsh (without Ctrl-V first) and
Emacs because bracketed paste is enabled or something like that.
> but the execvp command by itself doesn't do the writing
So, what is doing the writing?
Note that I get the same behavior with key "a" when I use
*VT100*translations: #override \n\
<Key>a: exec-formatted("browser %s", PRIMARY)
so that the cause cannot be the window manager or some X driver
on special key + mouse button combination.
--
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Acknowledgement sent
to Vincent Lefevre <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <[email protected]>.
(Wed, 05 Dec 2018 09:15:03 GMT) (full text, mbox, link).
On Wed, Dec 05, 2018 at 10:13:35AM +0100, Vincent Lefevre wrote:
> On 2018-12-05 09:58:21 +0100, Vincent Lefevre wrote:
> > On 2018-12-04 21:50:47 -0500, Thomas Dickey wrote:
> > > That looks as expected, if you've got two different things writing to
> > > the terminal at the same time:
> > >
> > > https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Bracketed-Paste-Mode
> >
> > So, perhaps I can see something with zsh (without Ctrl-V first) and
> > Emacs because bracketed paste is enabled or something like that.
> >
> > > but the execvp command by itself doesn't do the writing
> >
> > So, what is doing the writing?
>
> According to strace, it is xterm:
sure: xterm replies to the application for bracketed paste.
I don't see anything in the trace which makes it print anything for
the exec-formatted action, however.
> 9880 10:04:49.481717 execve("/bin/true", ["/bin/true"], 0x55e69924beb0 /* 131 vars */ <unfinished ...>
> [...]
>
> (For the test, I replaced "browser %s" by "/bin/true" for simplicity.)
--
Thomas E. Dickey <[email protected]>
https://invisible-island.netftp://ftp.invisible-island.net
On Wed, Dec 05, 2018 at 09:58:21AM +0100, Vincent Lefevre wrote:
> On 2018-12-04 21:50:47 -0500, Thomas Dickey wrote:
> > That looks as expected, if you've got two different things writing to
> > the terminal at the same time:
> >
> > https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Bracketed-Paste-Mode
>
> So, perhaps I can see something with zsh (without Ctrl-V first) and
> Emacs because bracketed paste is enabled or something like that.
>
> > but the execvp command by itself doesn't do the writing
>
> So, what is doing the writing?
I'm not able to see that. In your hexdump, in the small section mentioned,
there appeared to be a missing escape character in the sequence, which
would be due to interleaving two or more inputs (displacing some characters).
If you investigate zsh with bracketed paste disabled, you probably will
get different results.
--
Thomas E. Dickey <[email protected]>
https://invisible-island.netftp://ftp.invisible-island.net
Acknowledgement sent
to Vincent Lefevre <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <[email protected]>.
(Wed, 05 Dec 2018 10:33:03 GMT) (full text, mbox, link).
Subject: Re: Bug#913237: xterm: exec-formatted yields a tilde character in
zsh and emacs
Date: Wed, 5 Dec 2018 11:30:03 +0100
On 2018-12-05 05:03:46 -0500, Thomas Dickey wrote:
> On Wed, Dec 05, 2018 at 10:13:35AM +0100, Vincent Lefevre wrote:
> > According to strace, it is xterm:
>
> sure: xterm replies to the application for bracketed paste.
You mean that it is zsh that does the paste?
Why isn't there any system call from zsh in the strace output
(between the Ctrl-Meta-Click and the exec-formatted), then?
--
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Information stored
: Bug#913237; Package xterm.
(Wed, 05 Dec 2018 10:33:10 GMT) (full text, mbox, link).
Acknowledgement sent
to Vincent Lefevre <[email protected]>:
Extra info received and filed, but not forwarded.
(Wed, 05 Dec 2018 10:33:10 GMT) (full text, mbox, link).
Acknowledgement sent
to Vincent Lefevre <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <[email protected]>.
(Wed, 05 Dec 2018 12:36:05 GMT) (full text, mbox, link).
Subject: Re: Bug#913237: xterm: exec-formatted yields a tilde character in
zsh and emacs
Date: Wed, 5 Dec 2018 13:33:41 +0100
On 2018-12-05 11:30:03 +0100, Vincent Lefevre wrote:
> On 2018-12-05 05:03:46 -0500, Thomas Dickey wrote:
> > On Wed, Dec 05, 2018 at 10:13:35AM +0100, Vincent Lefevre wrote:
> > > According to strace, it is xterm:
> >
> > sure: xterm replies to the application for bracketed paste.
>
> You mean that it is zsh that does the paste?
>
> Why isn't there any system call from zsh in the strace output
> (between the Ctrl-Meta-Click and the exec-formatted), then?
[Another test on a different machine...]
If I type 'b' in xterm, the strace shows:
26473 13:22:10.942153 write(4, "b", 1) = 1
[...]
26473 13:22:10.961746 read(4, "b", 4096) = 1
So, it seems that the "write(4, ...)" corresponds to what xterm sends
to the application (here, zsh), and the "read(4, ...)" corresponds to
what zsh outputs (which is received by xterm): Since I've typed "b" in
xterm, xterm sends "b" to zsh, which handles it by inserting it in its
command line buffer and displaying it.
So, concerning the
26473 13:22:16.545126 write(4, "\33[201~", 6 <unfinished ...>
generated by Meta-Click with
Meta<Btn1Down>: exec-formatted("/bin/true", PRIMARY)
in the VT100 translations, this is what xterm sends to zsh. So, it is
xterm that is the cause, not zsh.
Note also that for a bracketed paste,
https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Bracketed-Paste-Mode
says:
When bracketed paste mode is set, the program will receive:
ESC [ 2 0 0 ~ ,
followed by the pasted text, followed by
ESC [ 2 0 1 ~ .
but here, only "\33[201~" is present in the strace output:
cventin:~> grep '\\33\[20' str.out
26473 13:22:16.545126 write(4, "\33[201~", 6 <unfinished ...>
Thus is cannot correspond to a bracketed paste.
--
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Acknowledgement sent
to Vincent Lefevre <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <[email protected]>.
(Wed, 05 Dec 2018 13:15:09 GMT) (full text, mbox, link).
Subject: Re: Bug#913237: xterm: exec-formatted yields a tilde character in
zsh and emacs
Date: Wed, 5 Dec 2018 14:12:32 +0100
On 2018-12-05 13:33:41 +0100, Vincent Lefevre wrote:
> Note also that for a bracketed paste,
>
> https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Bracketed-Paste-Mode
>
> says:
>
> When bracketed paste mode is set, the program will receive:
> ESC [ 2 0 0 ~ ,
> followed by the pasted text, followed by
> ESC [ 2 0 1 ~ .
>
> but here, only "\33[201~" is present in the strace output:
>
> cventin:~> grep '\\33\[20' str.out
> 26473 13:22:16.545126 write(4, "\33[201~", 6 <unfinished ...>
>
> Thus is cannot correspond to a bracketed paste.
I suspect a bug in doSelectionFormat() in button.c that makes xterm
think that there was a bracketed paste, whose consequence is to
generate the "ESC [ 2 0 1 ~ .".
If I remove
#if OPT_READLINE
mydata->paste_brackets = screen->paste_brackets;
SCREEN_FLAG_unset(screen, paste_brackets);
#endif
then I no longer get the "\33[201~". There's another issue, but
that's a start.
In any case, exec-formatted has nothing to do with paste (brackected
or not). So, I don't understand the contents of doSelectionFormat.
--
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Acknowledgement sent
to Vincent Lefevre <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <[email protected]>.
(Wed, 05 Dec 2018 13:48:02 GMT) (full text, mbox, link).
On 2018-12-05 14:12:32 +0100, Vincent Lefevre wrote:
> I suspect a bug in doSelectionFormat() in button.c that makes xterm
> think that there was a bracketed paste, whose consequence is to
> generate the "ESC [ 2 0 1 ~ .".
>
> If I remove
>
> #if OPT_READLINE
> mydata->paste_brackets = screen->paste_brackets;
> SCREEN_FLAG_unset(screen, paste_brackets);
> #endif
>
> then I no longer get the "\33[201~". There's another issue, but
> that's a start.
Replacing
mydata->paste_brackets = screen->paste_brackets;
by
mydata->paste_brackets = 0;
seems to solve the problem for exec-formatted. But doSelectionFormat
is also used by insert-formatted. I propose the attached patch, which
doesn't change the behavior for insert-formatted. But I don't know
about the
SCREEN_FLAG_unset(screen, paste_brackets);
line. Perhaps
#if OPT_PASTE64
mydata->base64_paste = screen->base64_paste;
screen->base64_paste = 0;
#endif
needs to be modified in a similar way, I don't know.
--
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Changed Bug title to 'xterm: exec-formatted sends an ending bracketed-paste sequence to the application (when enabled)' from 'xterm: exec-formatted yields a tilde character in zsh and emacs'.
Request was from Vincent Lefevre <[email protected]>
to [email protected].
(Wed, 05 Dec 2018 15:54:07 GMT) (full text, mbox, link).
On Wed, Dec 05, 2018 at 02:44:43PM +0100, Vincent Lefevre wrote:
> On 2018-12-05 14:12:32 +0100, Vincent Lefevre wrote:
> > I suspect a bug in doSelectionFormat() in button.c that makes xterm
> > think that there was a bracketed paste, whose consequence is to
> > generate the "ESC [ 2 0 1 ~ .".
> >
> > If I remove
> >
> > #if OPT_READLINE
> > mydata->paste_brackets = screen->paste_brackets;
> > SCREEN_FLAG_unset(screen, paste_brackets);
> > #endif
> >
> > then I no longer get the "\33[201~". There's another issue, but
> > that's a start.
>
> Replacing
>
> mydata->paste_brackets = screen->paste_brackets;
no - it's more complicated than that. The problem is that when xterm's
handling selectToClipboard, the X libraries delay the call to
SelectionReceived, and in working on #758633, I didn't notice this
particular scenario.
(I'm debugging a solution, will probably put out #338 when this is resolved)
--
Thomas E. Dickey <[email protected]>
https://invisible-island.netftp://ftp.invisible-island.net
Source: xterm
Source-Version: 338-1
We believe that the bug you reported is fixed in the latest version of
xterm, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Sven Joachim <[email protected]> (supplier of updated xterm package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Wed, 12 Dec 2018 20:31:33 +0100
Source: xterm
Binary: xterm
Architecture: source
Version: 338-1
Distribution: unstable
Urgency: medium
Maintainer: Debian X Strike Force <[email protected]>
Changed-By: Sven Joachim <[email protected]>
Description:
xterm - X terminal emulator
Closes: 901249913237913815
Changes:
xterm (338-1) unstable; urgency=medium
.
* New upstream release.
- Amend solution for #758633 to ensure that replies for bracketed
paste are not sent while processing a selection for exec-formatted
(Closes: #913237).
- Change compiled-in default for saveLines to match the resource-file
changed in xterm 192 (Closes: #913815).
- Revert the change which prevented concurrent ownership of different
selection targets, and instead modify selection storage so that
different concurrent requests for different selection targets will
be stored/retrieved independently (Closes: #901249).
* Mark the autopkgtests as superficial.
* Update copy of XTerm FAQ to revision 1.375 (dated 2018/10/16).
Checksums-Sha1:
b41f54fa6bd8db84609075c78413d721fbf4dfcf 2406 xterm_338-1.dsc
50a3111fa3a583321521e3c2dcece56a022afbb3 1344219 xterm_338.orig.tar.gz
37b9e095fb559cfd5bfe8d19f4ccb8e73b8c19dc 251 xterm_338.orig.tar.gz.asc
0f11f5327696d7a426eaab7e55ee3799e07c97bb 108444 xterm_338-1.debian.tar.xz
00bbc2a8536997bd036a0e58e4480427396ee2bd 8217 xterm_338-1_source.buildinfo
Checksums-Sha256:
a07602b2a813800ae63807512c53f590091cc2f7129f2fe9456bacbdf1137195 2406 xterm_338-1.dsc
b93536f5ed9847a701c1a9a81aca99a769cfd5dc001652b5e1bb600d7bfb871e 1344219 xterm_338.orig.tar.gz
9b5e7a085bd02320241110a56f7ae01a17bf5e4b76437f5bea3a8d1b1bf4565a 251 xterm_338.orig.tar.gz.asc
348d4aca6b269d9c9e3743c953955cb19ae8d32ebdd9e3d15ff8ec01a8e8467e 108444 xterm_338-1.debian.tar.xz
696640bcf9d8c59007e27e28f95657f70b0e0633aad22897b101c154c0cde7eb 8217 xterm_338-1_source.buildinfo
Files:
6882d3b28892f861093cc4a0deb504b6 2406 x11 optional xterm_338-1.dsc
76b32f050eec2ca80e825f3644a3168e 1344219 x11 optional xterm_338.orig.tar.gz
b4417dbcbff7748841a4977e81c728e7 251 x11 optional xterm_338.orig.tar.gz.asc
77fecac2005b0d2c68a87e339d36093c 108444 x11 optional xterm_338-1.debian.tar.xz
536463bce1302e300c8dca3637122311 8217 x11 optional xterm_338-1_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEKF8heKgv5Jai5p4QOxBucY1rMawFAlwRYk0ACgkQOxBucY1r
MawnOg/+Ndo9iWnOWdIrRNo5iWNI2Mcx2xHliOzYC3AK6LQogJi6dTZMGSxGyjCd
WCuz51qbmd2m7d05rn46Crl+W1ImYeUdD5qgl4eZiC8Y1d1vrf4004pscv4N0bOy
6ou9AMeDSG1otaOeEbEJIgSg6jDPmTdI0BHUETAFpMVfy3zQO34smRIxqlb2N4bx
W+uQQJDPGp1jRpQuf2y9suB2tg2JsNjvlVJ6hoBGGYsDpLqlPcTXJktzYYuPV4QB
gCr6FaTKSOpjtKXt5aFnN42s2VcgsnfxJ42Q+OcijBEi0BWL6wADRfRtE8A+TeTv
MbWwRE1fIOxKE49QPNDnnRnmuRtv4qL2R5jmsgzqWt0goGkKJI7rg2682r5KTpSS
erWNHMiR/oS2VzknOBw3auz2VhwD0K1PLk0Hg3g+7X1Qo4O4XkGkJ1guIZLCTb1r
2P65Mmy6IVqctZg1NPvItnYF+GUYwrXSwgWIcuMLP25XIDdWCsxDl/SmNJmb5fXE
aVGudE7zhZssRIfNCpaO9DyXYbs7FAKAV2dfMvTvQeDlU2k1ItGo5oGE3Dhg6Vuc
u2HKfEazepziywibR+s/ennpr/Kf39vt3aI+8jP/XFrphnwyCJkUj9Y9HefRybrC
5EQPS0ulCHm1Eq3Q6TnkP5VVszpStQKEZ/2brN7EndjP3nUmPXk=
=CqOL
-----END PGP SIGNATURE-----