Re: ksh emacs search-history misbehaviour
On Sun, Sep 19, 2021 at 02:29:57AM +0100, ropers wrote:
> I appreciate not everyone is as verbose as I can be, but your initial
> email was very terse. For example, when you say:
>
> > in emacs search-history mode, abort if ^@ is encountered
>
> is that the desired behaviour or the problem behaviour?
>
> From testing, it seems like the current behaviour is that it's
> aborting, and from reading only your diff, it looks like you want it
> not to abort but ignore an accidentally typed U+ character. But
> it also looks like this could relate to another ksh/emacs.c
> history-related issue I've previously observed but STILL not offered
> up a diff for.
>
> I think if you elaborated a little, that might make your email more
> accessible. Don't assume people know what you know. The less
> work--even thinking--people need to do to see where you're coming from
> the better. Thus, what are your exact steps, etc.? Also, what
> exactly do zsh and bash do?
>
> I tried to test a little to obtain a better understanding of what's
> bugging you (and arguably ksh), and I got somewhat inconsistent
> results -- with ksh's behaviour depending on whether I'd already typed
> something else. Sometimes I got a "phantom abort" where it looked
> like I was back to the regular prompt but actually wasn't. I even got
> ksh to dump core once, but that was oksh on a Linux box, so YMMV.
> In short, I'm not sure I'm really doing and seeing what you're seeing.
> I suspect if you described things more comprehensively, that might
> help not just little old me understand.
>
> Thanks and regards,
> Ian
Thank you, Ian, for sharing your view. I did start writing the message
as a commit message, and probably elaborated way too little.
I'll start over with a new thread with more elaborative wording.
/Alexander
>
> On 18/09/2021, Alexander Hall wrote:
> > Ping. Please don't be discouraged or scared just because it's a diff to
> > ksh(1). It really is rather simple.
> >
> > Noone else ever ran into this ksh command line history search bug?
> >
> > /Alexander
> >
> > On September 14, 2021 12:17:22 AM GMT+02:00, Alexander Hall
> > wrote:
> >>in emacs search-history mode, abort if ^@ is encountered
> >>
> >>This has been bugging me for ages, and I finally realized it was me
> >>accidentally pressing Ctrl+, rendering ^@ (a.k.a '\0' or NUL)
> >>
> >>Easily tested with: Ctrl+R Ctrl+ ...
> >>
> >>Minimal investigation, for reference:
> >> bash: misbehaves in a slightly different manner
> >> zsh: behaviour matches this fix
> >>
> >>OK?
> >>
> >>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 - 1.88
> >>+++ emacs.c 13 Sep 2021 21:42:37 -
> >>@@ -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)
> >>
> >
> >
Re: ksh emacs search-history misbehaviour
I appreciate not everyone is as verbose as I can be, but your initial
email was very terse. For example, when you say:
> in emacs search-history mode, abort if ^@ is encountered
is that the desired behaviour or the problem behaviour?
>From testing, it seems like the current behaviour is that it's
aborting, and from reading only your diff, it looks like you want it
not to abort but ignore an accidentally typed U+ character. But
it also looks like this could relate to another ksh/emacs.c
history-related issue I've previously observed but STILL not offered
up a diff for.
I think if you elaborated a little, that might make your email more
accessible. Don't assume people know what you know. The less
work--even thinking--people need to do to see where you're coming from
the better. Thus, what are your exact steps, etc.? Also, what
exactly do zsh and bash do?
I tried to test a little to obtain a better understanding of what's
bugging you (and arguably ksh), and I got somewhat inconsistent
results -- with ksh's behaviour depending on whether I'd already typed
something else. Sometimes I got a "phantom abort" where it looked
like I was back to the regular prompt but actually wasn't. I even got
ksh to dump core once, but that was oksh on a Linux box, so YMMV.
In short, I'm not sure I'm really doing and seeing what you're seeing.
I suspect if you described things more comprehensively, that might
help not just little old me understand.
Thanks and regards,
Ian
On 18/09/2021, Alexander Hall wrote:
> Ping. Please don't be discouraged or scared just because it's a diff to
> ksh(1). It really is rather simple.
>
> Noone else ever ran into this ksh command line history search bug?
>
> /Alexander
>
> On September 14, 2021 12:17:22 AM GMT+02:00, Alexander Hall
> wrote:
>>in emacs search-history mode, abort if ^@ is encountered
>>
>>This has been bugging me for ages, and I finally realized it was me
>>accidentally pressing Ctrl+, rendering ^@ (a.k.a '\0' or NUL)
>>
>>Easily tested with: Ctrl+R Ctrl+ ...
>>
>>Minimal investigation, for reference:
>> bash: misbehaves in a slightly different manner
>> zsh: behaviour matches this fix
>>
>>OK?
>>
>>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 - 1.88
>>+++ emacs.c 13 Sep 2021 21:42:37 -
>>@@ -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)
>>
>
>
Re: ksh emacs search-history misbehaviour
Ping. Please don't be discouraged or scared just because it's a diff to ksh(1).
It really is rather simple.
Noone else ever ran into this ksh command line history search bug?
/Alexander
On September 14, 2021 12:17:22 AM GMT+02:00, Alexander Hall
wrote:
>in emacs search-history mode, abort if ^@ is encountered
>
>This has been bugging me for ages, and I finally realized it was me
>accidentally pressing Ctrl+, rendering ^@ (a.k.a '\0' or NUL)
>
>Easily tested with: Ctrl+R Ctrl+ ...
>
>Minimal investigation, for reference:
> bash: misbehaves in a slightly different manner
> zsh: behaviour matches this fix
>
>OK?
>
>Index: emacs.c
>===
>RCS file: /cvs/src/bin/ksh/emacs.c,v
>retrieving revision 1.88
>diff -u -p -r1.88 emacs.c
>--- emacs.c27 Jun 2021 15:53:33 - 1.88
>+++ emacs.c13 Sep 2021 21:42:37 -
>@@ -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)
>
ksh emacs search-history misbehaviour
in emacs search-history mode, abort if ^@ is encountered
This has been bugging me for ages, and I finally realized it was me
accidentally pressing Ctrl+, rendering ^@ (a.k.a '\0' or NUL)
Easily tested with: Ctrl+R Ctrl+ ...
Minimal investigation, for reference:
bash: misbehaves in a slightly different manner
zsh: behaviour matches this fix
OK?
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 - 1.88
+++ emacs.c 13 Sep 2021 21:42:37 -
@@ -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)
