Re: [Bug Report] The Unexpected Behavior When Using ANSI Escape Code

2022-03-21 Thread Michaelll Lee
ion. 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 >> ve

Re: [Bug Report] The Unexpected Behavior When Using ANSI Escape Code

2022-03-21 Thread Michaelll Lee
, 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 &q

Re: [Bug Report] The Unexpected Behavior When Using ANSI Escape Code

2022-03-21 Thread Michaelll Lee
r 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,

[Bug Report] The Unexpected Behavior When Using ANSI Escape Code

2022-03-20 Thread Michaelll Lee
*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