Re: lynx-dev Problem with ^Z suspending - so far...

[Klaus Weide]

On Wed, 27 Jan 1999, Bela Lubkin wrote:
> Tom Dickey 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).
> 
> You will probably have to #ifdef it a lot; though, in theory,
> distribution of tcgetpgrp() should exactly match distribution of
> SIGTTOU, since they are separate parts of the implementation of the same
> mechanism, job control.

The following seems like a safe bet: if a system has SIGTTOU _and_
TERMIOS (tcgetattr etc.) _and_ HAVE_SIGACTION, then it certainly
must have tcgetpgrp.  Though that may be much too restrictive.

> In fact, perhaps the way to do it is for configure to ask "are all of
> these pieces present?"  If so, #define WE_HANDLE_JOB_CONTROL.  If not,
> #undef it and don't do any of this code, let the shell deal with it.
> That means: don't trap any JC signals at all; be completely unaware of
> them.  

You could already test this behavior (without changing the library)
by doing signal(SIGTSTP, SIG_IGN) before the curses initialization.
Ncurses should then never change the handler at all.

> In practice, this means that ncurses handles its own job control
> on most systems; on a few, with partial implementations, the shell
> handles it; and on older ones with no job control, nobody handles it
> because it doesn't exist...

I doubt that Tom will go for this - it seems too radical a change.
Well I don't know the characteristics of those "partial
implementations", or to what systems that applies.  But "no SIGTSTP
handler" for those system would also mean that an ncurses program
(without its own handler) would leave the screen contents in a mess
when interrupted, not just the tty flags.  Shells can deal with the
latter, but none of the ones I have checked seem to deal with the
first (ar character attributes).

Getting still further away from lynx...
For what it's worth, I have come to think of the different behaviors
in terms of the following classification:

This is only as far as switching with ^Z is concerned, regarding
tty settings.  It applies to interactive shells as well as user
programs.

Programs can be

tty-ignorant: Don't know, don't care.
      Strictly this doesn't even apply to ls or cat, or any
      other utility producing some lines of output.

tty-naive: Have certain needs, may establish them once (e.g. at
      initialization) but then don't bother further.

tty-aware: Try to ensure that their own needs are met.

tty-polite: Try to ensure that the other program's needs are met
      before it is switched to.

The last two can be subclassified further:

tty-aware-static: Always knows what its required tty mode is, it
      doesn't change (but may be established at initialization).

tty-aware-dynamic: Doesn't always keep track of what it needs, has
      to query current tty state to see what mode it has established.

tty-polite-static: Has a fixed assumption about what the other will
      require - probably some normal "canonical" and "sane" mode.

tty-polite-dynamic: Tries to keep track of what the other side wants,
      by querying tty after regaining control.

(Usually being polite includes being aware, with the exception being
ksh without line-editing (emacs or vi) mode: it is polite-dynamic
but not aware...)

Examples:

ash: tty-naive
bash: tty-aware-static, tty-polite-static
ksh: tty-aware-static (or not), tty-polite-dynamic

slang (as used in lynx): tty-aware-static, tty-polite-dynamic
ncurses (default handler): tty-aware-dynamic, tty-polite-dynamic

(That's all a bit fuzzy, for really exact classification one would
have to regard each bit of tty mode separately...)

Confusion can arise when naive meets naive; or when events happen in
an unexpected order and polite meets aware-dynamic, or aware meets
polite-dynamic, or...  One could make an N by N table here.

Using these terms, Bela's proposal means making ncurses tty-naive on
some platforms.  That's worse for interacting with a tty-naive shell,
but probably better for interacting with a polite-dynamic shell.

There may not be one choice of behavior for a given program that will
be optimal in all pairings.  To be sure, one would have to draw that
hypothetical table...

(My patch for ncurses lib_tstp can be classified as not changing the
behavior, just making the tty-aware-dynamic aspect less error prone.)

   Klaus