Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #16810

Re: Bug with new lines

Show key headers only | View raw

On 8/24/20 3:05 PM, Шкіпер Десна wrote:
> Hello!
> If I use something like `user@localhost:/folder$ echo -n 123`, then in a
> new line before 'user...' I see '123', but it's yet normal, but if I use
> something like `user@localhost:/folder$ echo -n $(echo 123)` or
> `user@localhost:/folder$ printf %s 123`, it may seem that everything is in
> order, but if I tap up (to copy previous command) and then tap down (to
> back), Bash will leave from start so many chars, like 'user@localhost:/folder$
> ' has, i.e., I'll get 'user@localhost:/folde'. The only way to repair it is
> to press "enter". If I just press up after `user@localhost:/folder$ printf
> %s 123`, then nothing unusual happens — it appends the previous command
> after '...$ ', like usual ('123' in the beginning doesn't disappear). If I
> tap it again, some many times, again nothing unusual, but once it will cut
> the ending of 'user@localhost:/folder$ '. I don't know exactly where the
> logic is. If I tap up twice or more, but the ending yes hasn't been
> clipped,  I can tap down and it won't be clipped, for except the last tap,
> when I get the current command.

This isn't a bug. Readline assumes it can use the entire line for redisplay
and that it starts in column 0. Any text can be overwritten otherwise.

Here are a few links to recent discussions of the issue.

https://lists.gnu.org/archive/html/bug-bash/2020-01/msg00005.html
https://lists.gnu.org/archive/html/bug-bash/2020-02/msg00002.html

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

Back to gnu.bash.bug | Previous | Next | Find similar

Thread

Re: Bug with new lines Chet Ramey <chet.ramey@case.edu> - 2020-08-24 17:20 -0400

csiph-web