Re: [Lynx-dev] Strange behavior
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 wrote: > >> The only thing I have been able to find is if I do a -trace the > >> trace file shows a GETCH0 got 0x 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< ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Strange behavior
I've never used brltty, so can't speak to it directly, but I have used ubuntu (and still do), as well as screen and another one I can't remember at the moment, and neither one of those caused lynx to abort when switching sessions. It might be worth asking on the blind linux list, or on the brltty list (I don't have the info for joining those lists, as I'm not a member of either one, I tend to use linux without braille, only speech). It's possible it's something in brltty (which would make sense), though why it would do this, I have no idea. However, I understand the brltty developer is quite responsive, and may even log directly into your machine (if possible and given permission) to fix issues, I know he's done this before for others. It's likely asking him would do more good than posting here. I do use lynx periodically, but most of my linux/BSD machines are having trouble, so I don't use them as often as I'd like, other than my softcon site, which is actually using a virtual host from linode). On Fri, 15 Feb 2019, Mouse wrote: The only thing I have been able to find is if I do a -trace the trace file shows a GETCH0 got 0x 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. (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. (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.) 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. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Strange behavior
Mouse dixit: >switching; I don't know Ubuntu (or for that matter any Linux) well I'm somewhat familiar enough with Linux by now, but the addition of brltty may throw off that knowledge, since it adds another layer few people are familiar with. bye, //mirabilos -- cool ein Ada Lovelace Google-Doodle. aber zum 197. Geburtstag? Hätten die nicht noch 3 Jahre warten können? bis dahin gibts google nicht mehr ja, könnte man meinen. wahrscheinlich ist der angekündigte welt- untergang aus dem maya-kalender die globale abschaltung von google ☺ und darum müssen die die doodles vorher noch raushauen ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Strange behavior
>> The only thing I have been able to find is if I do a -trace the >> trace file shows a GETCH0 got 0x 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. (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. (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.) 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. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Strange behavior
Tom Masterson wrote: > I am using Ubuntu 18.04 (Bionic Beaver) and among other things I am > running brltty as I am blind. When running lynx under a virtual console > (say tty3) if I switch to another console using ctrl-alt-function > (ctrl-alt-f4) and then switch back to lynx the computer has closed lynx. > The only thing I have been able to find is if I do a -trace the trace file > shows a GETCH0 got 0x just before lynx closed down. It appears to > be a normal shutdown. This occurs with the packaged build of 2.8.9dev.16 > or a built version of 2.9.0dev.1. > > I have not seen this in previous versions of Ubuntu or other distros. Any > ideas where I should look to figure out why this is happening? As Thorsten Glaser said, this is exactly how it would behave if it received a legitimate EOF. Here are a few troubleshooting steps I would take, and then where to go next would depend on results. Thet're in the order I thought of them, not necessarily best order to try them... 1. Question: does Lynx die (exit) when you switch away, or switch back? Use `ps` to check. Crudely, `ps --no-headers -C lynx | wc -l` will output how many Lynx processes are running. While Lynx is running, switch away and run that. Switch back and run it again (at the new command line after Lynx died). If they're the same (even nonzero), Lynx died on switch-away; if different by 1, on the switch-back. Significance: dying on switch-away suggests some sort of spurious input character issued by the switch-away keyboard sequence. Dying on switch-back suggests some sort of signal or plumbing issue, possibly in the console driver. 2. Do any unexpected processes have your tty open? Check this before starting Lynx. Run `lsof $(tty)`. Explain any unexpected outputs. Example: I just added a new tab to my running `mate-terminal` (ctrl-shift-t). `lsof $(tty)` there showed 3x `bash` (my running shell's stdin/out/err); 3x `lsof` (itself); 1x `mate-terminal` (not sure why it still has the slave side of the pty open, but it's not entirely unexpected, and it has the pty of every other tab open as well -- along with the expected N times /dev/ptmx). Nothing else. Significance: some other process could be doing something to trigger an EOF (e.g.: changing stdio settings like vmin & vtime). Why it would do that on vty switching is a mystery, but any other processes would be suspicious. Explain them, or kill (or `kill -STOP`) them before doing a test switch-away. Of course killing or suspending unexplained processes may have its own weird effects. But assuming not, if this allows a switch / switch-back to happen without killing Lynx, focus on those other process(es). 3. Run Lynx under `strace`. e.g. `strace -f -tt -o /tmp/lynx.trace lynx`. "-f" to catch child processes; "-tt" to timestamp the lines, which might show whether it happens on switch-away or switch-back, or other insights. Other flags might be useful. Once running, pause a few seconds; switch away; pause a few seconds; switch back. The pauses are to make the timestamps tell a clear story. What happens in the trace when Lynx dies? 4. What if you switch away to a different vty (ctrl-alt-F5)? Maybe it's something bad about the specific vty you've been targeting. Maybe the console stupidly injects an extra ctrl-D when you hit ctrl-alt-F4, but not for other vtys' switch sequences. This is improbable but so easy to test... Also try switching to a vty which has nothing running on it (if any). Maybe it's some misbehavior of whatever are taking the roles of getty, login, and shell, running on the switched-to vty (very unlikely but still easy to test). 5. Suppose you aren't running Lynx, but something simpler? e.g., if I run: $ bash $ read foo _ it's waiting for me to type something and hit Enter ... I hit ctrl-D $ -- shell prompt returned So, start a simple "read foo" (under `bash`, because I'm not 100% confident other shells will behave identically). Switch away; switch back. Did it return to the prompt? ... Essentially nothing about this has to do with Lynx, just some oddity on your system. Feel free to reply directly to me if you want to pursue some sort of additional troubleshooting and don't want to burden the list. (OTOH, list members might want to be in the loop; I'm not sure what the proper etiquette is in such a case.) >Bela< ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Strange behavior
Hi Tom, > trace file shows a GETCH0 got 0x hmm, 0x means -1 means EOF, end of file, so perhaps lynx thinks something closed the terminal. Somewhat cynically I suspect systemd might be behind something like that, but don't have an idea myself. Does this also happen with other programs? I'd suggest checking out on IRC whether some developers might have ideas to try, but I’m not familiar with the Ubuntu ones, only Debian. Sorry about that. Good luck nevertheless, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-) ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
[Lynx-dev] Strange behavior
I am using Ubuntu 18.04 (Bionic Beaver) and among other things I am running brltty as I am blind. When running lynx under a virtual console (say tty3) if I switch to another console using ctrl-alt-function (ctrl-alt-f4) and then switch back to lynx the computer has closed lynx. The only thing I have been able to find is if I do a -trace the trace file shows a GETCH0 got 0x just before lynx closed down. It appears to be a normal shutdown. This occurs with the packaged build of 2.8.9dev.16 or a built version of 2.9.0dev.1. I have not seen this in previous versions of Ubuntu or other distros. Any ideas where I should look to figure out why this is happening? Thanks Tom ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
[Lynx-dev] strange behavior opening localfile with #
I've got a report about Lynx's strange behavior opening localfile with # on Windows. These are the behaviors which I found, putting a file, which name is foo#bar, on the current directory and d:/tmp. 1. It SHOULD be opend and actually it is. (expected) lynx -cfg=lynx.cfg -lss=lynx.lss foo#bar 2. It SHOULD be opend but actually it isn't. (unexpected) lynx -cfg=lynx.cfg -lss=lynx.lss ./foo#bar lynx -cfg=lynx.cfg -lss=lynx.lss d:/tmp/foo#bar lynx -cfg=lynx.cfg -lss=lynx.lss file://localhost/d:/tmp/foo%23bar 3. It SHOULDN'T be opend and actually it isn't. (expected) lynx -cfg=lynx.cfg -lss=lynx.lss ./foo%23bar lynx -cfg=lynx.cfg -lss=lynx.lss d:/tmp/foo%23bar lynx -cfg=lynx.cfg -lss=lynx.lss file://localhost/d:/tmp/foo#bar 4. It SHOULDN'T be opend but actually it is. (unexpected) lynx -cfg=lynx.cfg -lss=lynx.lss ./foo%2523bar lynx -cfg=lynx.cfg -lss=lynx.lss d:/tmp/foo%2523bar lynx -cfg=lynx.cfg -lss=lynx.lss file://localhost/d:/tmp/foo%2523bar I've tested 2.8.6rel.1 for Windows got from this URL. http://pervalidus.50webs.org/cygwin/lynx/ -- Takeshi Hataguchi E-mail: [EMAIL PROTECTED] ___ Lynx-dev mailing list Lynx-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] strange behavior opening localfile with #
On Thu, 4 Jan 2007, [EMAIL PROTECTED] wrote: I've got a report about Lynx's strange behavior opening localfile with # on Windows. These are the behaviors which I found, putting a file, which name is foo#bar, on the current directory and d:/tmp. 1. It SHOULD be opend and actually it is. (expected) lynx -cfg=lynx.cfg -lss=lynx.lss foo#bar 2. It SHOULD be opend but actually it isn't. (unexpected) lynx -cfg=lynx.cfg -lss=lynx.lss ./foo#bar lynx -cfg=lynx.cfg -lss=lynx.lss d:/tmp/foo#bar lynx -cfg=lynx.cfg -lss=lynx.lss file://localhost/d:/tmp/foo%23bar 3. It SHOULDN'T be opend and actually it isn't. (expected) lynx -cfg=lynx.cfg -lss=lynx.lss ./foo%23bar lynx -cfg=lynx.cfg -lss=lynx.lss d:/tmp/foo%23bar lynx -cfg=lynx.cfg -lss=lynx.lss file://localhost/d:/tmp/foo#bar 4. It SHOULDN'T be opend but actually it is. (unexpected) lynx -cfg=lynx.cfg -lss=lynx.lss ./foo%2523bar lynx -cfg=lynx.cfg -lss=lynx.lss d:/tmp/foo%2523bar lynx -cfg=lynx.cfg -lss=lynx.lss file://localhost/d:/tmp/foo%2523bar I've tested 2.8.6rel.1 for Windows got from this URL. http://pervalidus.50webs.org/cygwin/lynx/ I can reproduce this (will see). thanks -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Lynx-dev mailing list Lynx-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/lynx-dev
