Re: [Lynx-dev] Strange behavior

[Bela Lubkin]

I'm quoting this whole message body as I don't know if Tom is a
lynx-dev subscriber (though perhaps he must be, because the list
probably only allows inbound messages from subscribers?)

Anyway, I'm a little worried that he went completely silent after
several suggestions were offered.

Mouse <address@hidden> wrote:

> >> The only thing I have been able to find is if I do a -trace the
> >> trace file shows a GETCH0 got 0xffffffff just before lynx closed
> >> down.
>
> > As Thorsten Glaser said, this is exactly how it would behave if it
> > received a legitimate EOF.
>
> Indeed.  And the suggestions are all good ones.  I just have three
> minor remarks:
>
> (1)
>
> > (e.g.: changing stdio settings like vmin & vtime).
>
> Minor nit: those are tty settings, not stdio settings.

Yes, my inattention.

> (2)
>
> > Essentially nothing about this has to do with Lynx,
>
> We don't actually know that at present.  It could be that there is
> something wrong in lynx that's making one piece of code think another
> got an EOF from the tty when it actually didn't.  Unlikely, yes, but no
> more so than some of the other theories given.

Technically true, but I'm going to predict that if we ever learn the
outcome, it will not have been caused by a Lynx misbehavior.

> (3)
>
> And, finally, are there any other ways of switching vtys?  Some systems
> support software-initiated switching as well as keyboard-initiated
> switching; I don't know Ubuntu (or for that matter any Linux) well
> enough to know whether it does.  If so, it might be worth trying
> switching other ways to see if it makes a difference.  (Of course, this
> could be difficult to test unless you have another computer you can ssh
> in from or some such.)

Ah, good suggestion.  Yes, there are such programs.  I don't know how
universal these are, but Ubuntu at least has programs `fgconsole` (print
the number of the currently active console virtual terminal AKA VT); and
`chvt` (activate a VT by number).  Tom indicated that he was hitting
ctrl-alt-f4, so that must be a different VT, so the following ought to
work to briefly flip the console away (this is bash / POSIX shell
syntax, won't work if you're using csh or something exotic):

   $ cur_vt=$(fgconsole); chvt 4; sleep 2; chvt $cur_vt

To test that against Lynx, something like this ought to work:

   $ cur_vt=$(fgconsole)
   $ (sleep 2; chvt 4; sleep 2; chvt $cur_vt) & lynx .

-- then let Lynx sit idle for 10 seconds.  If it is not disturbed,
that's evidence that the problem isn't caused by the VT switching.  I
think the most likely alternative is the keyboard action of invoking
the VT switch.

> Basically, at this point we're still in the information-collection
> phase, trying to probe the envelope of the problem to see if we can get
> any hints as to where it might be.

We do not start from a place of complete ignorance; speculating about
probable causes is reasonable, without requiring a complete research
project to search for hints.  The speculation might be wrong, but would
not have caused any significant problem if so.

>Bela<