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 <vinc...@vinc17.net> - 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)
