Re: lynx-dev Lynx 2.8.4rel1 on HP-UX 11i.

[Thomas Dickey]

On Fri, Aug 16, 2002 at 04:39:19PM -0400, Arne Sagnes wrote:
> Thomas,
>   thank you for all your replies.  They have been helpful in guiding us
> towards a solution that has yet to present itself. :-)  We have a little
> more information available now.  The original application that executes
> Lynx does not use curses itself.  It uses some Sybase Forms library that
> unfortunately is outdated these days.  The application and the execution
> of Lynx works well under HP-UX 10.20, which is what it was developed on.
>   We were able to reproduce the problem by having the application spawn
> a shell, then execute Lynx manually.  The same problem was evident, but
> I was unable to find anything different in any 'stty' or environment
> settings.  One thing I did notice is that it seems like Lynx doesn't
> pick up the "single key press".  For instance, in normal-Lynx you're
> able to simply hit "q" for "quit".  In our spawned-Lynx, you must hit
> "q", followed by "Enter" for it to acknowledge the key-press.  Does that
> give anyone new ideas? :-)  Thanks again for all the help.  We really
> appreciate it.

Well, there are the two effects I mentioned before: (a) the terminal I/O
modes, which you _should_ be able to see with stty, and (b) the terminfo
settings.  I think the latter is not related to this.  But the comment
about "Enter" reminds me of two harder-to-verify things:

        a) it is common to use setbuf or some related function in curses to
           make the output buffered.  That's something that is both associated
           with terminal I/O modes (which I'd like to think that stty could
           show), and program state.  But perhaps the C runtime does not
           initialize properly if the spawned shell's terminal I/O is subtly
           malfunctioning.
           
        b) I have in mind a case that someone recently reported to me that
           (reducing the report to the real cause) HPUX did not allow the
           'dialog' program to properly open /dev/tty for both input and
           output.  Something in the lower-level library is confused (both
           curses and ncurses behave the same, making the 'newterm()' function
           ineffective on that platform).  I was able to do some investigation
           and found that HPUX's ioctl's claimed that the modes were set
           successfully.  But they didn't work properly.  (I worked around this
           by making dialog only try to do that for the particular case where I
           wanted both open, so only one option fails rather than the whole
           program).
           
           Commenting on a different platform a few years ago, (SCO) Bela
           Lubkin told me that some analogous problems were due to /dev/tty
           being "really" the same stream which was duplicated.  So I'm
           guessing that HP's runtime is confused about what the actual modes
           of the input and output really are. 

If that's the case, there seems to be only a few options (I assume you cannot
modify the Sybase application - most of these discussions seem to be based
on code that no one can recompile):

        a) experiment with writing a short application to try to set the
           terminal I/O mode explicitly (that may work - but if it's
           fundamentally broken, probably not worth spending more than a couple
           of hours finding that it doesn't help).

        b) make the lynx application run in a separate window (but I have a
           hunch you're supporting some remote access where that isn't an
           option).

        c) recent versions of lynx use newterm().  I don't see the same
           situation that caused dialog to fail to initialize, but it's
           possible that there's something I'm overlooking there (though if
           you're using ncurses rather than HPUX curses, I doubt it).  You
           could build lynx with the definition HAVE_NEWTERM removed from the
           lynxcfg.h file.

If you could modify the Sybase application, it's possible to use brute force
(relink the application making lynx a subroutine ;-).  To test that idea, I'd
start with a small curses application.

-- 
Thomas E. Dickey <address@hidden>
http://invisible-island.net
ftp://invisible-island.net

; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden