[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug Report] The Unexpected Behavior When Using ANSI Escape Code
From: |
Michaelll Lee |
Subject: |
Re: [Bug Report] The Unexpected Behavior When Using ANSI Escape Code |
Date: |
Tue, 22 Mar 2022 10:43:13 +0800 |
On Mar 21, 2022, 9:39 PM Dennis Williamson <dennistwilliamson@gmail.com>
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 <
dennistwilliamson@gmail.com> wrote:
>
>
> On Mon, Mar 21, 2022 at 4:01 AM Michaelll Lee <lwl20th@gmail.com> 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
>
>
Re: [Bug Report] The Unexpected Behavior When Using ANSI Escape Code, L A Walsh, 2022/03/22