On 2025-05-12 11:10:03 +0200, Vincent Lefevre wrote:
> On 2025-05-10 15:49:20 +0100, Andrew Mass wrote:
> > One seemingly simple way to prevent this would be to sanitize /
> > disallow pasting buffers that contain this exact sequence. If
> > bracketed paste mode is active, it seems incorrect to me to allow
> > writing an "early" end sequence.
> >
> > I believe some other terminals take it a step further by sanitizing
> > all sorts of other potentially "dangerous" characters (e.g.:
> > https://gitlab.gnome.org/GNOME/vte/-/blob/master/src/pastify.cc)
>
> It seems that xterm changes ESC to a space and NUL to \0 (2 characters).
> The other control characters seem unfiltered, which is fine with zsh.
> Note that this is independent on whether bracketed paste mode is active
> (for instance, this also occurs in cooked mode).
Some other control characters are actually filtered by xterm
(replaced by a space, except NUL, which is replaced by "\0"). This
seems to correspond to disallowedPasteControls, as documented:
BS,DEL,ENQ,EOT,ESC,NUL,STTY
where
STTY special characters which are set with stty(1).
With zsh (in ZLE), ^\ (quit), ^Z (susp) and ^V (lnext) are not filtered,
contrary to the other ones (like ^C (intr)). I suspect that the cause is
that ZLE changes stty settings internally.
Anyway, it is up to the terminal to decide which character should be
filtered, under which condition, and how, and this could be configurable
like in xterm.
IMHO, whether bracketed paste mode is enabled or not, some of them
should really be filtered, like ESC and the special stty characters,
as the special stty characters would have an effect before they can
reach the application.
--
Vincent Lefèvre <vincent_AT_vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
Received on Mon May 12 2025 - 11:45:32 CEST