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
