Path: csiph.com!goblin2!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From: Chet Ramey <chet.ramey@case.edu>
Newsgroups: gnu.bash.bug
Subject: Re: Bug with new lines
Date: Mon, 24 Aug 2020 17:20:04 -0400
Organization: ITS, Case Western Reserve University
Lines: 33
Approved: bug-bash@gnu.org
Message-ID: <mailman.1072.1598304016.2469.bug-bash@gnu.org>
References: <CABNJF6eOxmU5XdqMiA81Vz=M_BT0uv29CYjM4kXHgQp+xKST1A@mail.gmail.com> <23644e5f-6d1f-fd39-7bb2-5ea01bc92c57@case.edu>
Reply-To: chet.ramey@case.edu
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Cc: chet.ramey@case.edu
To: =?UTF-8?B?0KjQutGW0L/QtdGAINCU0LXRgdC90LA=?= <shkiper.d1000@gmail.com>, bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
Autocrypt: addr=chet.ramey@case.edu; prefer-encrypt=mutual; keydata= mQGiBEEOsGwRBACFa0A1oa71HSZLWxAx0svXzhOZNQZOzqHmSuGOG92jIpQpr8DpvgRh40Yp AwdcXb8QG1J5yGAKeevNE1zCFaA725vGSdHUyypHouV0xoWwukYO6qlyyX+2BZU+okBUqoWQ koWxiYaCSfzB2Ln7pmdys1fJhcgBKf3VjWCjd2XJTwCgoFJOwyBFJdugjfwjSoRSwDOIMf0D /iQKqlWhIO1LGpMrGX0il0/x4zj0NAcSwAk7LaPZbN4UPjn5pqGEHBlf1+xDDQCkAoZ/VqES GZragl4VqJfxBr29Ag0UDvNbUbXoxQsARdero1M8GiAIRc50hj7HXFoERwenbNDJL86GPLAQ OTGOCa4W2o29nFfFjQrsrrYHzVtyA/9oyKvTeEMJ7NA3VJdWcmn7gOu0FxEmSNhSoV1T4vP2 1Wf7f5niCCRKQLNyUy0wEApQi4tSysdz+AbgAc0b/bHYVzIf2uO2lIEZQNNt+3g2bmXgloWm W5fsm/di50Gm1l1Na63d3RZ00SeFQos6WEwLUHEB0yp6KXluXLLIZitEJLQwQ2hldCBSYW1l eSAoQ2FzZSBzdGFuZGFyZCkgPGNoZXQucmFtZXlAY2FzZS5lZHU+iF8EExECAB8FAkPi19EC GwMHCwkIBwMCAQMVAgMDFgIBAh4BAheAAAoJELtYafBk6nSrelkAn31Gsuib7GcCZHbv5L5t VKYR9LklAJ4hzUHKA49Z0QXR+qCb80osIcmPSbkBDQRBDrBvEAQAkK6TAOKBEM+EC4j6V/7o /riVZqcgU5cid2qG9TXdwNtD9a3kvA/ObZBO93sX59wc6Bnwo4VJxsOmMlpGrAjJsxNwg3QH akEtf8LXRbVpj5xStdmBdQZUhIQyalo/2/TZq5OijtddUQcL5cs70hTv/FpT3wUvr2Xr8rjF 41IFEz8AAwcD/A0CZEGlzIrT5WCBnl6xBog/8vKiUCbarByat3d1mL6DbizvKNXQRTC9E/vE dENAWCQCjr75Bu55xT8n3SXGtWdDC5xmZ/P3OBYORP8yl8H8I1FIosWOFirbIeYdZPq8SPD1 HL+EXo9zSiHVrrZRJ19ooCKKbSdXHFCY+aJG+0KZiEkEGBECAAkFAkEOsG8CGwwACgkQu1hp 8GTqdKvjcACfZlkVCDwaz/NTO9cy3t69oWpVPNwAnRwe0qk/WL/gfhH346xh5B3HFbFN
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
In-Reply-To: <CABNJF6eOxmU5XdqMiA81Vz=M_BT0uv29CYjM4kXHgQp+xKST1A@mail.gmail.com>
Content-Language: en-US
Received-SPF: pass client-ip=129.22.103.226; envelope-from=chet.ramey@case.edu; helo=mpv1-2015.case.edu
X-Spam_score_int: -66
X-Spam_score: -6.7
X-Spam_bar: ------
X-Spam_report: (-6.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-2.25, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-BeenThere: bug-bash@gnu.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Bug reports for the GNU Bourne Again SHell <bug-bash.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/bug-bash>
List-Post: <mailto:bug-bash@gnu.org>
List-Help: <mailto:bug-bash-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=subscribe>
X-Mailman-Original-Message-ID: <23644e5f-6d1f-fd39-7bb2-5ea01bc92c57@case.edu>
X-Mailman-Original-References: <CABNJF6eOxmU5XdqMiA81Vz=M_BT0uv29CYjM4kXHgQp+xKST1A@mail.gmail.com>
Xref: csiph.com gnu.bash.bug:16810

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/