Re: lynx-dev peculiar behavior

[Kim DeVaughn]

On Sat, Jul 10, 1999, Larry W. Virden (address@hidden) said:
|
| I won't call this a bug - just yet - but I do want to know if others
| are seeing this behavior.

It's a bug ... though quite probably not a lynx bug ...


| I type along.  I need to pop out to look at something.  I press control Z
| to halt nvi.  After finding what I need, I do a fg.
|
| Instead of displaying nvi again, what I appear to be getting is this.
|
| Input goes to nvi.
|
| Output APPEARS to be coming from lynx - I see on the screen the empty
| form I was getting ready to submit.  As I type, I see nvi messages.
|
| So I write out the file I was working on and then quit nvi.  Now I appear
| to be back to lynx fully.  But things still are not right.  Pressing
| function keys results in the CSI strings (]B or whatever) appearing on
| the screen.  When I finally manage to exit lynx, my terminal is left in
| a raw terminal mode.

This sounds alot like the busted signal handling that was a problem for
quite awhile with FreeBSD.

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.

Might also try ^Z'ing out of an invoked vi from programs like trn/tin/nn,
mutt/elm/pine, etc.

If it *only* happens when lynx invokes vi, then it's possible that lynx
*is* futzing with signals in a strange way that tweaks the Sparc's tail
in a way it doesn't like.

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).


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 ...?



The thing I found as a tempfix workaround on the older FreeBSD revs,
was to patch trn/trn4/less/mutt/etc, so that /bin/bash would be used
instead of /bin/sh, when the programs were spawning the editor (via a
fork/exec, system() call, whatever).  It seems that bash was handling
signals properly, whereas sh wasn't.

You might try some similar hack ... just don't try using tcsh/csh based
shells ... :-) ...

/kim