Re: lynx-dev Problem with ^Z suspending: more ncurses

[Klaus Weide]

On Wed, 27 Jan 1999 address@hidden wrote:

> I've been following this thread (and aside from applying other people's
> patches, seems to be the top item on lynx+ncurses for the moment).  I'll
> have to ifdef it, probably (not all platforms have the tcgetpgrp, I assume).

Btw. I had not checked whether it is guaranteed that &cur_term->Nttyb
(used after continuing in reset_prog_mode) has always been filled in at
least once.  Looking now, it seems Nttyb is first set by newterm.
Near the end it has,

        _nc_signal_handler(TRUE);

        /* open a connection to the screen's associated mouse, if any */
        _nc_mouse_init(SP);

        /* Initialize the terminal line settings. */
        _nc_initscr();

the relative order between _nc_signal_handler(TRUE) and _nc_initscr()
should be changed to avoid a small window where Nttyb hasn't yet been
filled.


Here's another problem with ncurses:
SIGTSTP is always ignored during curses_mode character output, as in

sigaction(SIGTSTP, {SIG_IGN}, {0x4000c6b0, [], SA_RESTART}) = 0
write(1, "\33[1;32r\33[39;49m\33[0;10m\33["..., 2800) = 2800
write(1, "ur server.\r\n\33[39;49m\33[33m "..., 110) = 110
sigaction(SIGTSTP, {0x4000c6b0, [], SA_RESTART}, NULL) = 0

That's bad - if (say) lynx is called via another process, then that
parent will get the SIGTSTP and stop, while lynx goes on and doesn't
notice.  Normally lynx would then be stopped too by either SIGTTOU or
SIGTTIN, but that won't reset the screen first; and after fg'ing the
tty mode will be messed up (depending on what the interactive shell
does).  And if lynx has been invoked directly from a shell, the ^Z
is just dropped, which also isn't necessary.

I assume the intention is to prevent interruption during output
when the cursor is in the middle of the screen and some weird
attributes might be in effect.  But in the indirect invocation
case it has kind of the opposite effect.  I can produce the
effect by pressing ^L and then very quickly ^Z.

It's these lines in doupdate():

        _nc_signal_handler(FALSE);

        [ ... lots of stuff where output is written ... ]

        _nc_signal_handler(TRUE);

I think they should just be replaced by sigprocmask calls to
block SIGTSTP and at the end restore the original mask.  (if
sigprocmask is available)

This brings the question whether some other signals should also
be blocked (while we're at it).  If SIGTSTP is blocked but
SIGTTOU isn't, we create another getting-stopped-twice situation.
But since (as far as I can see) the bracketed section generates
only write() and not ioctl(), that would be subject to the tostop
flag, and (for me  at least :) ) -tostop is the normal case, so
that's not too bad.  Blocking SIGTTOU during all output would
make the tostop flag kind of useless, I don't think ncurses should
make that decision (an application program can still do something
about SIGTTOU if it wishes), so I think blocking just SIGTSTP
is ok.

   Klaus