Colored prompt + cmdline ending at right margin => no explicit newline

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Colored prompt + cmdline ending at right margin => no explicit newline

Egmont Koblinger-2
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H   -I.  -I../. -I.././include -I.././lib  -Wdate-time
-D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/bash-IrsGKQ/bash-4.4=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall -no-pie
-Wno-parentheses -Wno-format-security
uname output: Linux blacky 4.13.0-16-generic #19-Ubuntu SMP Wed Oct 11
18:35:14 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.4
Patch Level: 12
Release Status: release

Hi,

Type a command (such as "echo asdfgh....") that just reaches the right edge
of the terminal (the cursor wraps to the next line) and execute it.

Then, do any of these:
 - double click on the last word of the command, or the first word of its
output,
 - copy-paste across this line boundary to a graphical text editor,
 - resize the terminal horizontally if it supports rewrap-on-resize (such
as gnome-terminal or urxvt).

With a simple prompt such as PS1='\u@\h $ ' the result is as expected:
 - double-click highlighting stops at that line boundary,
 - copy-pasting reveals that there's an explicit newline there,
 - rewrap on resize does what's expected.

Running 'script' reveals that the cursor is actually moved up, then to the
right by 79 columns, the last letter of the command is repainted and an
explicit newline is added.

Let's do the same with a colored prompt, e.g. PS1='\[\e[33m\]\u@\h
$\[\e[m\] '
 - double clicking selects across the line boundary,
 - copy-pasting doesn't insert an explicit linebreak,
 - rewrap on resize does silly things.

According to 'script', the cursor is moved upwards and then immediately a
newline is printed to move it back. This, at least in some popular/standard
terminal emulators I've tried now (xterm, urxvt, gnome-terminal) does not
cause that line to be terminated with a hard newline.

Could bash (readline?) please perform the "magic" of reprinting the last
character followed by an explicit newline, even in case of more complex
prompts?


thanks a lot,
egmont
Reply | Threaded
Open this post in threaded view
|

Re: Colored prompt + cmdline ending at right margin => no explicit newline

Egmont Koblinger-2
A bit of technical clarification:

Terminal emulators seem to default to lines ending in an explicit newline.
It's the implicit overflow (printing a letter that wraps to the next line)
which makes the previous line soft-wrapped, and a \e[K (clear to EOL) and
perhaps a few other similar sequences (e.g. character deletion) that makes
it hard-wrapped again.

Newlines are irrelevant, especially since it's often a CR LF so technically
the cursor is in the first column when it's moved to the next line.

I mistakenly omitted the fact that the "magic" also involves emitting that
\e[K before reprinting the last character of the command line, this is the
key to the expected behavior, as currently done with non-colored prompts
only.


thanks,
egmont
Reply | Threaded
Open this post in threaded view
|

Re: Colored prompt + cmdline ending at right margin => no explicit newline

Chet Ramey
In reply to this post by Egmont Koblinger-2
On 11/18/17 3:45 PM, Egmont Koblinger wrote:

> Bash Version: 4.4
> Patch Level: 12
> Release Status: release
>
> Hi,
>
> Type a command (such as "echo asdfgh....") that just reaches the right edge
> of the terminal (the cursor wraps to the next line) and execute it.
>
> Then, do any of these:
>  - double click on the last word of the command, or the first word of its
> output,
>  - copy-paste across this line boundary to a graphical text editor,
>  - resize the terminal horizontally if it supports rewrap-on-resize (such
> as gnome-terminal or urxvt).
>
> With a simple prompt such as PS1='\u@\h $ ' the result is as expected:
>  - double-click highlighting stops at that line boundary,
>  - copy-pasting reveals that there's an explicit newline there,
>  - rewrap on resize does what's expected.
>
> Running 'script' reveals that the cursor is actually moved up, then to the
> right by 79 columns, the last letter of the command is repainted and an
> explicit newline is added.
>
> Let's do the same with a colored prompt, e.g. PS1='\[\e[33m\]\u@\h
> $\[\e[m\] '
>  - double clicking selects across the line boundary,
>  - copy-pasting doesn't insert an explicit linebreak,
>  - rewrap on resize does silly things.
>
> According to 'script', the cursor is moved upwards and then immediately a
> newline is printed to move it back. This, at least in some popular/standard
> terminal emulators I've tried now (xterm, urxvt, gnome-terminal) does not
> cause that line to be terminated with a hard newline.
>
> Could bash (readline?) please perform the "magic" of reprinting the last
> character followed by an explicit newline, even in case of more complex
> prompts?

Yes. Thanks for the report and the reproducible test case. This happens in
_rl_update_final(), which needs to be updated to deal with a prompt
containing invisible characters in this special case.

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    [hidden email]    http://cnswww.cns.cwru.edu/~chet/