Date: Fri, 29 Jul 2016 14:38:19 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 211360] ESC characters are not interpreted by /bin/sh Message-ID: <bug-211360-8-9370VsT1lp@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-211360-8@https.bugs.freebsd.org/bugzilla/> References: <bug-211360-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211360 Jilles Tjoelker <jilles@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jilles@FreeBSD.org --- Comment #1 from Jilles Tjoelker <jilles@FreeBSD.org> --- The breaking change is in libedit, not sh itself. The libedit in FreeBSD 11= .x uses a simple screen image array of wide characters indexed by the position= , so characters c with wcwidth(c) =3D=3D 0 are discarded. This includes not only= control characters but also combining characters such as U+0308 combining diaeresis. Unix-like systems usually use precomposed characters such as U+00E4 latin s= mall letter a with diaeresis which do not have this problem but precomposed characters do not exist for all combinations. The libedit in FreeBSD 10.x uses a simple screen image array of bytes, all = of which are assumed to be one cell wide. Therefore, control sequences confuse libedit's idea of the cursor position, and commands longer than the terminal width are not displayed properly if the prompt contains control sequences. Libedit has a feature to make this work (EL_PROMPT_ESC) but sh does not sup= port it and I have not tested it. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-211360-8-9370VsT1lp>