[Bug Report] The Unexpected Behavior When Using ANSI Escape Code
*Below are generated automatically by **'/usr/bin/bashbug' due to the absence of 'rmail**’** command.* --- *From:* Michael(lwl2...@gmail.com) *To:* bug-bash@gnu.org *Subject: *The Unexpected Behavior When Using ANSI Escape Code. *Configuration Information [Automatically generated, do not change]:* Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin' -DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc' -DSYS_BASH_LOGOUT='/etc/bash.bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS uname output: Linux arch80g 5.16.13-arch1-1 #1 SMP PREEMPT Tue, 08 Mar 2022 20:07:36 + x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.1 Patch Level: 16 Release Status: release *Description:* Background: A normal Bash user for a while. When ``PS1’’ environment variable contains the ANSI escape codes, Bash will behavior unexpectedly when Copy&Paste the content from clipboard using Ctrl+V. This unexpected behaviour could be easily reproduced in a few steps. Reproduceable steps are: 1) $ PS1='---Test \\ \e[0m ---\\$ ' [Press Key] 2) [Paste '123456789_123456789_' with ] 3) [Press Key] 4) [Everything Is Fine] 5) [Paste '123456789_123456789_123456789_' with ] 6) [Press Key] 7) ---Test \ ---$ 1234123456789_123456789_123456789 [Result in Extra Charavters: The Leading '1234'] 8) [Paste '123456789_123456789_'] 9) [Press Key] 10) [Everything Is Fine] According to my limited tests, this behavior (i.e., Step7) could exist on serveral platforms on which the BASH_VERSION is 5.x.x. However, this behavior cannot be found on the same platforms while 4.x.x/3.x.x version of Bash is invoked. When the steps mentioned above being applied to other counterparts which currently being as active development as Bash, Step7 would not happen for them. Hence, it is a reasonable guess that this might be bug for 5.x.x version of Bash. If not, that would be my misuse of Bash, and would appreciate for taking time reading my report. *Repeat-By:* No currently. *Fix:* Would be glad to provide a fix if I'm capable of. --- 2022/03/20 Michael Lee lwl2...@gmail.com
Re: [Bug Report] The Unexpected Behavior When Using ANSI Escape Code
@Andreas Have it solved by following that manual page and using "\[ ... \]" combination. Thanks for the hint! By the way, apparently the content about "non-printing characters" in that man page has not been modified across the several versions of Bash, for example in my machine, "3.2.57(1)-release" and "5.1.0(1)-release" share nearly the same document for section "PROMPTING", and both of them have not mentioned about the necessity to wrap around the non-printing characters with "\[...\]". While using non-printing characters without "\[...\]" proves to be fine in versions prior to 5.x.x (e.g., many suggestions from some online forums have suggested "PS1=\e[0m" for using ANSI escape code in the prompt), the same configuration in 5.x.x is not as stable as the previous versions(i.e., "PS1=\[\e[0m\]" should be used instead of "PS1=\e[0m", otherwise the unexpected behavior(STEP7) will happen). This might not be a bug for the current release of Bash, but we, as long-term users, indeed needs to add some extra configurations to Bash5 make things work as normal as the versions prior to 5.x. According to my limited tests, "Using standard ANSI escape code in prompt variable PS1" is exactly the case. I think it would be better to document it in man page/manual, or at least give a hint/warning for using non-printing characters. Nevertheless, Bash Long Live! On Sun, Mar 20, 2022 at 10:43 PM Andreas Schwab wrote: > On Mär 20 2022, Michaelll Lee wrote: > > > 1) $ PS1='---Test \\ \e[0m ---\\$ ' > > Read the manual about non-printing characters in the prompt. > > > https://www.gnu.org/software/bash/manual/html_node/Controlling-the-Prompt.html > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different." >
Re: [Bug Report] The Unexpected Behavior When Using ANSI Escape Code
On Mar 21, 2022, 9:47 PM Chet Ramey wrote: > Unless told otherwise, it assumes that every character it outputs contributes > to that physical cursor position. Thank you Sir, for pointing out this clearly, and now I think my previous thoughts would be my misunderstanding. On Mon, Mar 21, 2022 at 9:47 PM Chet Ramey wrote: > > On 3/21/22 5:00 AM, Michaelll Lee wrote: > > > While using non-printing characters without "\[...\]" proves to be fine in > > versions prior to 5.x.x (e.g., many suggestions from some online forums > > have suggested "PS1=\e[0m" for using ANSI escape code in the prompt), the > > same configuration in 5.x.x is not as stable as the previous versions(i.e., > > "PS1=\[\e[0m\]" should be used instead of "PS1=\e[0m", otherwise the > > unexpected behavior(STEP7) will happen). > > This has never been true. > > Readline's display relies on knowing the physical cursor position. Unless > told otherwise, it assumes that every character it outputs contributes to > that physical cursor position. Eventually, the incorrect value that results > from non-printing characters will mess up redisplay. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [Bug Report] The Unexpected Behavior When Using ANSI Escape Code
On Mar 21, 2022, 9:39 PM Dennis Williamson wrote: > > Note that the difference you see in Bash 5 is due to new paste behavior. >From the perspective from users, would be more appropriate to see a hint for this new kind of behavior in man page/manual. Anyway, thanks for the clarification. On Mon, Mar 21, 2022 at 9:39 PM Dennis Williamson < dennistwilliam...@gmail.com> wrote: > > > On Mon, Mar 21, 2022 at 4:01 AM Michaelll Lee wrote: > >> . . . >> While using non-printing characters without "\[...\]" proves to be fine in >> versions prior to 5.x.x (e.g., many suggestions from some online forums >> have suggested "PS1=\e[0m" for using ANSI escape code in the prompt), the >> same configuration in 5.x.x is not as stable as the previous >> versions(i.e., >> "PS1=\[\e[0m\]" should be used instead of "PS1=\e[0m", otherwise the >> unexpected behavior(STEP7) will happen). >> . . . > > > Note that the difference you see in Bash 5 is due to new paste behavior. > However, prior versions are *not* fine without the escaped brackets. Bash > loses track of the position of the cursor if there are unbracketed > non-printing sequences. This is visible when stepping back through commands > in history and a long command wraps, for an example. > https://mywiki.wooledge.org/BashFAQ/053 > >
