On Thursday 14 February 2008, Wael Nasreddine wrote:
> This One Time, at Band Camp, Andrey Borzenkov <arvidjaar@xxxxxxxxxx> said, On
Wed, Feb 13, 2008 at 10:01:21PM +0300:
> > On Wednesday 13 February 2008, Andrey Borzenkov wrote:
> > > On Monday 11 February 2008, Peter Stephenson wrote:
>
> > > > On Mon, 11 Feb 2008 16:07:09 +0100
> > > > antho.charles@xxxxxxxxx wrote:
> > > > > I didn't have this problem on Debian etch, but it appears when I
> > > > > upgraded to lenny. It's the same problem: if I set LANG to a non utf8
> > > > > encoding (fr_FR instead of fr_FR.UTF-8), RPROMPT is good, otherwise
> > > > > it's partially on another line and the cusor is after RPROMPT.
> > > > > (cf. http://tinyurl.com/3xjeqt)
>
> > > > Sounds like it ought to be fairly reproducible, but it's not happening
on
> > > > Fedora 8 (and it still sounds suspiciously like the shell is getting
duff
> > > > information about the environment, though that's certainly not the only
> > > > possibility). I've tried adding multibyte characters to the command
line
> > > > and complicating the RPROMPT and even adding multibyte characters to
that,
> > > > but it still works OK.
>
> > > > Are there any particular things on the command line, forms of RPROMPT
etc.
> > > > etc. that show this up? (We really need something that narrows this
down.)
>
>
> > > I can reproduce it on Mandriva cooker with locale en_US.UTF-8 or
ru_RU.UTF-8.
> > It
> > > does not matter whether there are UTF-8 characters on the screen (at
least, I
> > am
> > > not sure whether there are - en_US.UTF-8 should not emit any non-ASCII
strings
> > > as far as I can tell).
>
>
> > Actually the problem seems to be that terminal description contains
non-UTF-8
> > conform characters.
>
> > {pts/0}% infocmp | grep acsc
> > acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
> > {pts/0}% infocmp linux | grep acsc
> > acsc=+\020\,
> >
\021-\030.^Y0\333`\004a\261f\370g\361h\260i\316j\331k\277l\332m\300n\305o~p\304q\304r\304s_t\303u\264v\301w\302x\263y\363z\362
> > {\343|\330}\234~\376,
>
> > the first one is for dtterm, the second - for linux console.
>
> > The prompt is using q, l, m, j, k - at least some of them have high bit set.
>
> > So something gets confused computing prompt width. I am not really sure
> > how to fix it except teaching zsh about ACS mode. Is there any curses
function
> > that would return screen width of character string?
>
> Maybe that's the reason, but changing TERM has no effect whatsoever,
But replacing all ACS characters with space has:
PR_SET_CHARSET=""
PR_SHIFT_IN=""
PR_SHIFT_OUT=""
PR_HBAR=' '
PR_ULCORNER=' '
PR_LLCORNER=' '
PR_LRCORNER=' '
PR_URCORNER=' '
If you have time you could try them one by one to see which one(s) break prompt.
Attachment:
signature.asc
Description: This is a digitally signed message part.