On 12/10/06, Otto Moerbeek <[EMAIL PROTECTED]> wrote:

On Sun, 10 Dec 2006, Alexander Farber wrote:

> Hello Martin and others,
>
> On 12/6/06, Martin Hedenfalk <[EMAIL PROTECTED]> wrote:
> > On 12/2/06, Alexander Farber <[EMAIL PROTECTED]> wrote:
> > > IMHO it would be better, if ESC-p and ESC-n wouldn't "cycle"
> > > but would stop at the last matching command - same as in tcsh.
> > >
> > > Because otherwise a user might go through several useless
> > > "cycles" until (s)he reliazes that the needed command isn't there
> >
> > I've put an updated patch up on
> > http://bzero.se/patches/ksh-history-v2.patch.
>
> thanks for your new patch (sorry, I didn't have time to test it
> during the week). Now it almost works - I enter
>
>  bind '^XA'=history-search-backward
>  bind '^XB'=history-search-forward
>
> and then enter few letters and can use the up- and down-arrows -
> and they work and do not cycle after the last match (which is good IMHO).
>
> However there are still 2 differences to tcsh:
>
> 1) ESC-p and ESC-n aren't bound by default (maybe it's ok for ksh?)

A version 3 of the patch binds these keys by default:
http://bzero.se/patches/ksh-history-v3.patch

> 2) When I type few letters, like "ls " and then use the up-key to search
>    for matching commands, and then see that my command isn't there -
>    then I press the down-key several times to get back to the 3 letters
>    that I have entered initially ("ls ").
>
>    In tcsh I can get back to the "ls ", but in your new ksh I'm stuck
>    with the last matched command (like "ls /tmp" - which I don't want),
>    and have to press CTRL-c

I see. Fixing this seems to add a bit more complexity, and this issue
doesn't annoy me enough to warrant adding that complexity. FWIW, it is
consistent with bash.

> Regards
> Alex

I found one other problem:

if the match equals the string typed in, the match is never found.

$ foo
$ bar
$ fooESC-P
does beep.

This happens only when foo is the possible match. If there's a foorbar
with a higher history number, that is found, and next the foo is
found.

I would say that this is the correct behaviour in this case, because
there are no other consecutive unique matches to be found.

/martin

Reply via email to