Re: lynx-dev peculiar behavior

[Klaus Weide]

Larry, to eliminate one factor first: does this also happen outside
of screen?  If you have other ways to log into that system (xterm,
telnet, ...), is it independant of that?

On Sat, 10 Jul 1999, Larry W. Virden wrote:

> From: Kim DeVaughn <address@hidden>
> 
> > You might try seeing if it happens when other programs invoke your editor.
> > Try going into vi from "less" and "more" with their "v" command, then hit
> > ^Z, and see if you get similar behavior to lynx -> vi -> ^Z.
> 
> I tried it with less and trn and had no problems.
> 
> > BTW ... also try setting EDITOR/VISUAL to (say) emacs, and see if it
> > still happens when you ^Z out of *that* editor (and also is there any
> > problem when you hit ^G inside of emacs, and then exit it).
> 
> I better not try that - if emacs is around here (and I don't know that it
> is) I wouldn't have the foggiest notion of how to get out of it <grin>.

Then please try replacing it with another interactive program that can
be suspended - less, some other editor, even lynx itself.  Try several.
My guess is you'll see similar behaviour.

I have seen something like this in the past with lynx.  I think the
problem lies in the implementation of system().

> >  One other thing to look at ... when you're in your lynx invoked vi, do
> > a ps from another screen before the ^Z, then after the ^Z, then after
> > you fg it.
> 
> > Anything change in the ps output ... like one of your processes maybe
> > "disappeared" for no reason ...?
> 
> Nope:
> 
> Processes on the tty before I invoked my editor:
>  8 S    lwv26 12619  1805  1  41 20 610b4f78    558 61eb9576 07:52:04 pts/4   
>  0:01 lynx http://purl.org/thecliff/tcl/w
>  8 S    lwv26  1805  1784  0  51 20 61208238    221 612082a8 17:12:27 pts/4   
>  0:07 /bin/ksh
> 
> 
> While I am in the editor:
> 
>  8 S    lwv26 12619  1805  1  41 20 610b4f78    574 610b4fe8 07:52:04 pts/4   
>  0:01 lynx http://purl.org/thecliff/tcl/w
>  8 S    lwv26 12650 12649  0  51 20 60a07b90    246 61eb9576 07:52:51 pts/4   
>  0:00 nvi /ldatae/tmp/L12619-3TMP
>  8 S    lwv26  1805  1784  0  51 20 61208238    221 612082a8 17:12:27 pts/4   
>  0:07 /bin/ksh
>  8 S    lwv26 12649 12619  0  51 20 610576a0    116 61057710 07:52:51 pts/4   
>  0:00 sh -c nvi  /ldatae/tmp/L12619-3TMP

One step is missing here:  what's the state after the ^Z but before the
fg?  (There should be several T where now there is S).

> After I have typed ^Z and then did the fg back to the editor:
> 
>  8 S    lwv26 12619  1805  0  41 20 610b4f78    574 610b4fe8 07:52:04 pts/4   
>  0:01 lynx http://purl.org/thecliff/tcl/w
>  8 S    lwv26 12650 12649  0  41 20 60a07b90    246 61eb9576 07:52:51 pts/4   
>  0:00 nvi /ldatae/tmp/L12619-3TMP
>  8 S    lwv26  1805  1784  0  41 20 61208238    221 612082a8 17:12:27 pts/4   
>  0:07 /bin/ksh
>  8 S    lwv26 12649 12619  0  41 20 610576a0    116 61057710 07:52:51 pts/4   
>  0:00 sh -c nvi  /ldatae/tmp/L12619-3TMP

Can you please repeat this experiment, but with the following change:
instead of typing ^Z, send a SIGTSTP singnal explicitly to the nvi process
(not the process group).  I.e. go to another screen, find nvi's pid, then
   kill -TSTP <pid>
What happened to the lynx session?  If it hangs (screen still shows nvi,
no input accepted) that's good.  (You may have to kill the whole thing
explicitly with kill, or continue the nvi with kill -CONT, in order to
recover).  If lynx has regained control (showing lynx screen, accepting
input) that's bad.  It would mean that system() has returned prematurely.

> I'm using ksh, rather than sh.  ksh signal handling seems to be fine.

I *think* it's not the shell that is relevant here.  But maybe I'm wrong.
(I guess it could also have something to do with ncurses.  Maybe you
can try a slang-compiled version.)

Larry, what does the system() man page say?  Mine says (linux)

       system() executes a command specified in string by calling
       /bin/sh -c string, and returns after the command has  been
       completed.   During execution of the command, SIGCHLD will
       be blocked, and SIGINT and SIGQUIT will be ignored.

Does yours also mention signals, especially SIGCHLD?

   Klaus