Zsh 3.1.9 on HP-UX 10.20/11.0

Zsh 3.1.9 on HP-UX 10.20/11.0

[Clint Olsen]

Hello:

Quite some time ago I reported a bug in Zsh where I was unable to use 3.1.6
on HP-UX 11.0 when the binary was built on a 10.20 machine.  The cursor
would essentially scroll wildly and the tty was hung.

Our 11.0 deployment was delayed, so I didn't pursue the problem any
further.  I recently downloaded 3.1.9 and built it on 10.20 (for forward
compatibility).  I can now login with this version of Zsh (thanks!).
However, the cursor is behaving a little strangely.  When I hit backspace,
the cursor advances as if I typed a <space>.  ^U doesn't seem to clear the
line either (well, it does, but the clear isn't reflected visually in the
tty).

I was wondering if anyone could offer any suggestions?  Unfortunately, it's
not feasible to configure my wrappers to use a different Zsh for different
versions of HP-Ucks.

Notes:

I'm using HPs performance C compiler to compile Zsh, not gcc.  I have my
own TERMINFO database I'm using for Thomas Dickey's color xterm.  My stty
settings appear to be identical on HP-UX 10.20 and 11.0.

I'm not on this mailing list, so please Cc: me on any replies you want me
to see.

Thanks!

-Clint

Re: Zsh 3.1.9 on HP-UX 10.20/11.0

[Bart Schaefer]

On Oct 18,  9:37am, Clint Olsen wrote:
} Subject: Zsh 3.1.9 on HP-UX 10.20/11.0
}
} I recently downloaded 3.1.9 and built it on 10.20 (for forward
} compatibility). I can now login with this version of Zsh (thanks!).
} However, the cursor is behaving a little strangely. When I hit
} backspace, the cursor advances as if I typed a <space>. ^U doesn't
} seem to clear the line either (well, it does, but the clear isn't
} reflected visually in the tty).

It sounds as though the terminal description (terminfo or termcap) doesn't
have the correct codes for some cursor motions.  Both of the symptoms you
described could be explained if zsh were emitting the wrong code for "move
cursor left" and then emitting either spaces (to cover up one character) or
clear-to-EOL (for ^U).  A simple "typescript" capture of a brief session
would show what's being emitted by ZLE.

} I was wondering if anyone could offer any suggestions?

My guess would be that there's some incompatibility in termcap and terminfo 
on the two versions of the OS.  Either zsh's configure is choosing the
"wrong one" when you build on the older HP-UX, or the one it finds is not
working properly with the terminal description database on the new machine,
or both.

You say:

} I have my own TERMINFO database I'm using for Thomas Dickey's color
} xterm.

Are you sure zsh is successfully reading that database on both platforms?
HP-UX probably has some utilitity equivalent to "strace" ("truss" on Sun)
that would let you examine the system calls to see which terminfo files
are actually being opened.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Zsh 3.1.9 on HP-UX 10.20/11.0

[Clint Olsen]

On Oct 18, Bart Schaefer wrote:
> 
> It sounds as though the terminal description (terminfo or termcap)
> doesn't have the correct codes for some cursor motions.  Both of the
> symptoms you described could be explained if zsh were emitting the wrong
> code for "move cursor left" and then emitting either spaces (to cover up
> one character) or clear-to-EOL (for ^U).  A simple "typescript" capture
> of a brief session would show what's being emitted by ZLE.

Script started on Wed Oct 18 13:24:39 2000
^[]0;phpw0019 ~^G^Mphpw0019 ~# asdfasdf^M^M
zsh: command not found: asdfasdf^M
^[]0;phpw0019 ~^G^Mphpw0019 ~# ^G^G    ^G^G^G^G^M^M
^[]0;phpw0019 ~^G^Mphpw0019 ~# ^M^M

script done on Wed Oct 18 13:24:48 2000

It appears that ^G is being emitted instead of ^H.

> Are you sure zsh is successfully reading that database on both platforms?
> HP-UX probably has some utilitity equivalent to "strace" ("truss" on Sun)
> that would let you examine the system calls to see which terminfo files
> are actually being opened.

I did a truss on "vim /etc/passwd", and I see:

open("/fs17/a/olsenc/.terminfo/x/xterm", O_RDONLY, 03) = 4

-Clint