Hi,
In ksh(1) emacs editing mode, the search-history editing command
(normally bound to ^R), is used for interactive searching through the
history of previously given commands.
While performing such a search, emitting a NUL character (i.e. '\0',
or ^@) adds said character to the search pattern. As the search is
performed using ordinary string functions, this causes a buffer overrun
and unexpected behaviour.
At least in my setup, Ctrl+<space> also renders ^@.
Example:
$ echo hello miss molly
hello miss molly
$ echo ohno
ohno
$ <-- Press ^R for search-history -->
I-search: <-- Press Ctrl+<space>, and then any characters -->
$ echo ohno^@^@miss molly^J^@
In this case, the search pattern starts with '\0', so the last command
will always match, no matter how many characters are added to the
pattern. Eventually, the length of the pattern will exceed the length
of the matched command, and will start printing more of the matched
command than there is, exposing whatever follows the command in the
memory.
Solution:
I suggest that entering a NUL character will abort the search-history
mode, much like ^[ does. This leaves the handling of said character to
the "ordinary" command editing.
Not that I care much about consistency with other shells in this regard,
but from light testing, this seems to match the behaviour of zsh in our
ports tree.
OK?
/Alexander
Index: emacs.c
===================================================================
RCS file: /cvs/src/bin/ksh/emacs.c,v
retrieving revision 1.88
diff -u -p -r1.88 emacs.c
--- emacs.c 27 Jun 2021 15:53:33 -0000 1.88
+++ emacs.c 13 Sep 2021 21:42:37 -0000
@@ -897,7 +897,7 @@ x_search_hist(int c)
if ((c = x_e_getc()) < 0)
return KSTD;
f = kb_find_hist_func(c);
- if (c == CTRL('[')) {
+ if (c == CTRL('[') || c == CTRL('@')) {
x_e_ungetc(c);
break;
} else if (f == x_search_hist)
