On Mon, Aug 08, 2016 at 08:21:50AM +0200, Martin Natano wrote: > On Mon, Aug 08, 2016 at 03:33:23AM +0200, Ingo Schwarze wrote: > > Hi Dave, > > > > redirecting from misc@ to tech@ because i'm appending a patch > > at the very end, lightly tested. > > > > This has indeed been annoying me for years, but it never occurred > > to me that i might be able to figure out what's going on. > > Thanks for providing your analysis, i think it's spot on. > > > > So the solution is to not swallow up that escape character, right? > > Thats not always correct. With your patch ksh now eats the next key you > type when you exit the search prompt with the escape key. The only way > to know whether the esacpe is part of a longer sequence or was typed by > the user is timing. I've sent a patch some time ago that checks if more > bytes are available from the input descriptor to decide whether the esc > was a single one or part of a sequence: > https://marc.info/?l=openbsd-tech&m=141240304628749&w=2 > > Below an updated version of that patch.
Looks right and works fine for me. OK halex@ /Alexander > > natano > > > Index: edit.c > =================================================================== > RCS file: /cvs/src/bin/ksh/edit.c,v > retrieving revision 1.53 > diff -u -p -r1.53 edit.c > --- edit.c 17 Mar 2016 23:33:23 -0000 1.53 > +++ edit.c 8 Aug 2016 06:19:34 -0000 > @@ -10,6 +10,7 @@ > > #include <sys/ioctl.h> > #include <sys/stat.h> > +#include <poll.h> > > #include <ctype.h> > #include <errno.h> > @@ -149,6 +150,16 @@ x_puts(const char *s) > { > while (*s != 0) > shf_putc(*s++, shl_out); > +} > + > +int > +x_avail(void) > +{ > + struct pollfd pfd[1]; > + > + pfd[0].fd = STDIN_FILENO; > + pfd[0].events = POLLIN; > + return poll(pfd, 1, 0) == 1; > } > > bool > Index: edit.h > =================================================================== > RCS file: /cvs/src/bin/ksh/edit.h,v > retrieving revision 1.11 > diff -u -p -r1.11 edit.h > --- edit.h 26 Jan 2016 17:39:31 -0000 1.11 > +++ edit.h 8 Aug 2016 06:19:34 -0000 > @@ -39,6 +39,7 @@ int x_getc(void); > void x_flush(void); > void x_putc(int); > void x_puts(const char *); > +int x_avail(void); > bool x_mode(bool); > int promptlen(const char *, const char **); > int x_do_comment(char *, int, int *); > Index: emacs.c > =================================================================== > RCS file: /cvs/src/bin/ksh/emacs.c,v > retrieving revision 1.65 > diff -u -p -r1.65 emacs.c > --- emacs.c 26 Jan 2016 17:39:31 -0000 1.65 > +++ emacs.c 8 Aug 2016 06:19:35 -0000 > @@ -893,9 +893,12 @@ 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('[')) { > + /* might be part of an escape sequence */ > + if (x_avail()) > + x_e_ungetc(c); > break; > - else if (f == x_search_hist) > + } else if (f == x_search_hist) > offset = x_search(pat, 0, offset); > else if (f == x_del_back) { > if (p == pat) { > > > > > > Yours, > > Ingo > > > > > > Dave Cohen wrote on Sun, Aug 07, 2016 at 04:52:50PM -0700: > > > > > I'll try to describe an annoyance with my ksh setup. Web and man > > > page searching has not provided a solution. I'm relatively new to > > > both ksh and openbsd. I'm on version 5.9 release. > > > > > > Problem happens when I navigate command history with ctrl-r, then > > > use left or right arrow. Hitting left arrow writes "[D", right > > > inserts "[C". I'm hitting the arrow keys so I can edit my prior > > > command. It's a habit I'm used to that works in bash. > > > > > > For example to reproduce, let's say I ran "ls -l" but I wanted > > > to run "ls -la"... > > > > > > run the first command, "ls -l". > > > > > > type "ctrl-r ls". This works as expected, and my cursor is now > > > in the middle of "ls -l". > > > > > > type right arrow. This is where the problem is. The command I'm > > > editing becomes "ls[C -l". > > > > > > From this point, arrow keys work as expected. I can use left or > > > right to navigate and edit the command. > > > > > > If, instead of arrows, I use ctrl-b or ctrl-f, these work fine. > > > No artifacts like "[C" or "[D". > > > > > > If I use bash instead of ksh, this problem does not occur. > > > > > [...] > > > I understand from `man ksh` that these key bindings are defaults: > > > bind '^[[C'=forward-char > > > bind '^[[D'=backward-char > > > > > > My assumption is that when in ctrl-r mode, the '^[' is interpreted > > > as part of the ctrl-r search (which doesn't match), then the '[C' > > > or '[D' is interpreted as the next key (which is inserted). Can > > > this behavior be changed? > > > > > > Index: emacs.c > > =================================================================== > > RCS file: /cvs/src/bin/ksh/emacs.c,v > > retrieving revision 1.65 > > diff -u -p -r1.65 emacs.c > > --- emacs.c 26 Jan 2016 17:39:31 -0000 1.65 > > +++ emacs.c 8 Aug 2016 01:25:13 -0000 > > @@ -893,9 +893,10 @@ 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('[')) { > > + x_e_ungetc(c); > > break; > > - else if (f == x_search_hist) > > + } else if (f == x_search_hist) > > offset = x_search(pat, 0, offset); > > else if (f == x_del_back) { > > if (p == pat) { > > >