Oops, email category changed. :-) Oh well, I guess POSIX are allowed to be wrong! Thanks for clarification.
Regards, Scott -----Original Message----- From: Chet Ramey <chet.ra...@case.edu> Sent: Thursday, 27 March, 2025 02:28 To: Scott ROCHFORD <scott.rochf...@amadeus.com>; bug-readline@gnu.org Cc: chet.ra...@case.edu Subject: Re: Bug: vi mode history navigation, <n>G goes backwards but not forwards On 3/25/25 11:58 PM, Scott ROCHFORD wrote: > CONFIDENTIAL Oh? > > > bash-4.4.20-5.el8.x86_64 & readline-7.0-10.el8.x86_64 on RHEL 8.10 > > $ echo $BASH_VERSION > > 4.4.20(1)-release > > $ set -o vi > > $ : one > > $ : two > > $ : three > > $ history > > 1 echo $BASH_VERSION > > 2 set -o vi > > 3 : one > > 4 : two > > 5 : three > > 6 history > > '<esc>4G' displays : > > $ :two > > '3G' displays > > $ :one > > '6G' - or any number greater than 3 - incorrectly displays first entry in > history > > $ echo $BASH_VERSION This was fixed in bash-5.2 to ring the bell and not change the current line, which is consistent with the POSIX standard for sh vi-mode editing. > Ideally 'G' on its own should jump to 'end-of-history' without having to > remap bindings (would lose <n>G functionality), but as it stands all roads > lead to beginning-of-history. That's how POSIX says it's supposed to work.
