It can be reproduced on Debian bullseye with bash 5.0.11 on urxvt and xterm and by a friend on MacOS with bash 3.2.57.
With this procedure I'm able to reproduce it consistently: - Move ~/.bashrc elsewhere just to start clean - Start a new terminal (in my case tput cols tells it's 79 columns, beware, the bug varies according to the terminal width). - run `bash --norc` in it, to start clean - Prompt in my case is `bash-5.0$ `, beware, the bug varies according to the length of the prompt. - type `printf "Hello World\n "` (1) - hit the `uparrow` of your keyboard to see the printf again (2) - hit C-a (bash shortcut for beginning-of-line) (3) After (1) you should see (I'm using ■ to mark the place of the cursor) which is OK: bash-5.0$ printf "Hello World\n Hello World bash-5.0$ ■ After (2) you should see (still OK): bash-5.0$ printf "Hello World\n " Hello World bash-5.0$ printf "Hello World\n "■ After (3) you should see (not OK): bash-5.0$ printf "Hello World\n " Hello World ■ bash-5.0$ printf "Hello World\n " The cursor should not go that far, it should stop on the `p` of `printf`. I straced and played a bit with, and noted a few interesting things: - Bug appear, or not, depending on the length of the prompt (happen with short prompts, bug disapear with long prompts) - Bug appear, or not, depending on the length of the command (happend with long commands, bug disapear with short commands) - Bug appear, or not, depending on the width of the terminal - When beginning-of-line calls `write(2, "\r\33[C\33[C\33[C\33[C\33[C...` I have the bug - When beginning-of-line calls `write(2, "\10\10\10\10\10\10\10\10\10...` I don't have the bug It can be reproduced without using spaces: mdk@seraph:~$ printf "Hello World\n01234567890123456789" Hello World 01234567890123456789mdk@seraph:~$ printf "Hello World\n01234567890123456789" ^ The point jumps here (on the 2nd 4) Cross-posted here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948343 -- Julien Palard https://mdk.fr