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