Re: lynx-dev Problem with ^Z suspending

[Klaus Weide]

On Sun, 24 Jan 1999, Bela Lubkin wrote:

> This reminded me that the script I was testing with *does* exec Lynx as
> its last act.  When I changed that, I was able to observe a minor
> behavioral difference.  So this problem does exist on my system, but has
> such small symptoms that I never noticed it.

This is getting into the more cosmetic area (but it still should be
fixed if possible), I have seen the same kinds of different behavior
with other ncurses programs, for example "less" (I have it as PAGER,
which causes man to start it as one of the child processes).  I also
see this kind of thing with a slang compile of lynx.  What I haven't
seen here with other programs than ncurses-lynx is the second, more
severe aspect, that the process gets stopped twice.

Still waiting whether someone can confirm that, at least for linux...

> Before I hit ^Z, Lynx is idle, displaying a page.  The bottom line shows
> me the URL of the current link, and the cursor is in the rightmost
> column of the screen:
> 
>   -more- http://vagabond:457/cgi-bin/man//man/html.S/catopen.S.html           
> _
> 
> When I hit ^Z, the shell prints a message, "[1] + Stopped      docsearch
> catalog".
>
> If this is a standalone Lynx (or was exec'd as the last command in a
> shell script", the shell's message overwrites Lynx's bottom line -- as
> if Lynx had issued a carriage return (\015) but no linefeed (\012):

If your curses acts like ncurses, it's probably just positioning the
cursor at the beginning of the last line (whether that's done with
a \015 or an ESC sequence).

>   [1] + Stopped      docsearch catalogan//man/html.S/catopen.S.html

Let's call this behavior 1 for reference.

> However, if the script is going to continue after Lynx finishes, I see:
> 
>   -more- http://vagabond:457/cgi-bin/man//man/html.S/catopen.S.html           
> [
>   1] + Stopped      docsearch catalog

( I would also expect you to see the cursor not being in the right
horizontal place in the following shel prompt line. )

Let's call this behavior 2.

> -- as if Lynx didn't issue that carriage return.

( I think it did exactly the same, only it output gets written to the
tty _after_ the interactive shell has already written its "[1] .." and
prompt lines. )

I suggest that you try both again with -show_cursor toggled, that may
give you a better idea.

One difference for me is that bash as interactive shell, after it's child
has stopped, writes an extra '\n' (after having put the tty in a mode where
that acts like CRLF, before writing the "[1] + Stopped ..."), so I don't get
overwriting of the last statusline, since it is scrolled up.  Other than
that, with an ncurses-lynx that has signal(SIGTTOU, SIG_IGN) I get essentially
what you get.  

I'm quite sure the difference between the two cases can be completely
explained in terms of who gets to write to the screen first - lynx or
the interactive shell.  However, I *sometimes* see behavior 1 also
occur when lynx is an indirect child (but that would all depend on
which process the kernel schedules first to react to the signal).

Actually, I now tried with two other shells.  With ash, I see exactly
what you see, modulo different appearance of the "[1] .." line and
prompt.  With pdksh the same but more weirdness occurs... when lynx
is fg'd again after behavior 2, the tty ends up being in icanon and
echo mode... argh, I don't want to look at that closer right now.

> Again, seeing as Lynx has no SIGTSTP handler of its own, this must be a
> behavior of the OpenServer libcurses that I'm linking against.  Tom can
> fix it in ncurses; perhaps I can fix it in my curses as well...

There may not really be a reasonable way around _this_ part of the
problem (the one described by you, which I call more or less
cosmetic).  Maybe things are working as well as we can expect,
unless the interactive shell can somhow be made to wait for more
than its direct children.

Workarounds could be to (1) use exec where possible, or (2) to
prevent the script shell process from stopping before its child does.
Something like (2) should be possible depending on what the shell can
do, with something like trap and wait builtin commands...

   Klaus