bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Readline not being able to handle long lines


From: Mihail Konev
Subject: Re: [PATCH] Readline not being able to handle long lines
Date: Wed, 30 Nov 2016 07:34:25 +0500

On Tue, Nov 29, 2016 at 10:02:08AM -0500, Greg Wooledge wrote:
> On Tue, Nov 29, 2016 at 02:14:11PM +0500, Mihail Konev wrote:
> > > Buggy (replace the ^-sequences in the second line):
> > > PS1="[\${PWD##*/}]\$ "      # set the prompt
> > > PS1="^[]0;\$PWD^G^M$PS1"    # set the window title
> > > 
> > 
> > Turns out this was the only one buggy.
> > So it was all the (mis-) googled PS1 customizations,
> > that are actually incompatible with bash 3.2.0 and higher.
> 
> This is just plain wrong in any bash version.  Any part of the prompt that
> does not cause the cursor to change position needs to be protected inside
> \[ \].  Thus, the sequence from ESC to BEL on line 2 of your script should
> be inside \[ \].
> 
> Using a CR (^M) probably screws things up as well.  I don't even know why
> you have that in there.  If you want to ensure the prompt always starts
> on a new line, use a newline instead of a CR, which will presumably
> start to overwrite the last line of the previous command's output, if
> that output doesn't end with a newline of its own.  I would not expect
> this to be the desired behavior.
> 
> In any case, you have a working prompt in your original email, so you
> could just stick with that one.

Yes. This was all the \[ \] , the lack of them.

They are bash-specific, and when the ^G^M works in mksh 52
(somehow not overwriting the previous command), it /looks/ like
pitfall of the former (which actually is a fast-rendering feature).

Nitpicked version control due to non-clean-room testing, therefore.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]