[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#265552: pstree indentation doesn't line up in xterm



On Fri, Aug 13, 2004 at 09:00:13PM +0200, Joey Hess wrote:
> I've managed to capture some pstree output to a file that seems to
> reproduce the problem when I cat it in an xterm, even an xterm on
> another machine. I've attached that file. When this file is catted,
> the result is not identical to the pstree indentation problem I
> described above; only one or two lines are displated without
> indentation. I hope it's enough to help reproduce the bug.

I only see a problem with wrapping on the line containing "xterm zsh upnet"
which does the wrong thing at the "p" in "offlineimap".  Rendering the
file, I see this (all characters are printable, I'm showing the full line):

\n
\E(0^Ox
\E(B
\E(0^Ox
\E(B
\E(0^Otq
\E(B4*[xterm
\E(0^Oqqq
\E(Bzsh]
\n
\E(0^Ox
\E(B
\E(0^Ox
\E(B
\E(0^Otq
\E(Bxterm
\E(0^Oqqq
\E(Bzsh
\E(0^Oqqq
\E(Bupnet
\E(0^Oqqq
\E(Bmovemail
\E(0^Oqqq
\E(Bofflineimap
\E+
\n

Note the "\E+".  That's an error (in psmisc, since it has no reason to generate
something like that).  There's no such escape sequence.  That is, not as you
see it.  \E+ followed by a final character looks like this in ctlseqs.ms:

ESC + C        Designate G3 Character Set (ISO 2022)
               Final character C for designating character sets (0 , A
               and B  apply to VT100 and up, the remainder to VT220 and
               up):
                 C = 0  -> DEC Special Character and Line Drawing Set
                 C = A  -> United Kingdom (UK)
                 C = B  -> United States (USASCII)
                 C = 4  -> Dutch
                 C = C  or 5  -> Finnish
                 C = R  -> French
                 C = Q  -> French Canadian
                 C = K  -> German
                 C = Y  -> Italian
                 C = E  or 6  -> Norwegian/Danish
                 C = Z  -> Spanish
                 C = H  or 7  -> Swedish
                 C = =  -> Swiss

(this doesn't apply if you're in UTF-8 mode by the way).  A correctly
behaving terminal will allow some control characters in the middle of
the sequence, so the newline gets through.  But when it hits a noncontrol
character such as space, it terminates the sequence (eats the characters).

I don't see the \E+ explicitly in pstree.c - it's most likely some trash
that it's producing in out_char as I noted in my first response.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

Attachment: pgpTclMF56yhk.pgp
Description: PGP signature


Reply to: