FreeBSD and filePro weirdness

[Fairlight]

Been pondering this one, John.

Hmmm.  One thought...well, two.  I did at one point see a Cisco switch that
would hard-lock and require a power cycle if you sent the keystroke ^\ for
SIGQUIT from remote.  It was a low-end DSL router they had, something 600.
But this does imply it's -possible- to get odd behaviour via a remote
connection, although in my case it didn't affect the app, it affected the
router itself.  I suppose one could be subject to data corruption one
direction or even both, since everything's filtered through its I/O,
especially when it's being further encapsulated for a VPN.

However, thought two has to do with the timing of your breaks, and strikes
me far harder.  Ever run a shell script that runs sub jobs, then hit INTR
(^C in my case) and it moves on to the next program call listed in the
script?  I've had this with shell scripts depending on the shell, and I've
had it notably with 'make'.  The issue being that you're sending signals
to the child processes, so they die, but the parent does not.  In the case
where there's screen control going on at multiple levels, this would be a
perfect opportunity for screen corruption, both possibly from half-finished
tasks if it's not a clean-exit (ie., not designed to properly exit or back
out on SIGINT), but also (and more importantly) if one program restored a
terminal state while the other expects it in a wholly different state that
it set--but which was just unset by the program that "cleaned up" after
being killed.

Best guess as to the relevance of that behaviour.  Don't ask me to explain
why it won't happen locally though, unless the latencies introduced from
remote let it get 'x' far less or farther along in the screen painting
and/or terminal resetting.

mark->

This public service announcement was brought to you by John Esak:
> I don't have any other data about the problem other than I am using the
> *exact* same termcap locally on my WAN. The same Windows box using FacetWin,
> and the same OS on the Unix box (SCO 5.6.) and it *never* and I mean never
> happens in this situation. However, when I go across the WAN, either through
> my VPN or across the the public IP avoiding the VPN, the problem happens
> about 90% of the time I press BREAK while at the filePro clerk menu. Now,
> another (I think) very important factor. If I do not press BREAK to quickly
> after the clerk menu appears... it will not do the screw up. It only happens
> when I am say at a filePro record... and I press BREAK BREAK BREAK repatedly
> to back me out of the record, the index, the clerk menu, etc. back to the
> shell. When I do this quicly, the problem happens. When I do it slowly, the
> problem does not happen. Important??
> 
> John
> 
> 
> > -----Original Message-----
> > From: filepro-list-bounces+john=valar.com at lists.celestial.com
> > [mailto:filepro-list-bounces+john=valar.com at lists.celestial.com]On
> > Behalf Of Fairlight
> > Sent: Thursday, December 07, 2006 1:40 AM
> > To: filePro Mailing List
> > Subject: Re: FreeBSD and filePro weirdness
> >
> >
> > Well, how so on the ISP connection not being at issue comes down to
> > mechanism.  Facet uses TCP, not UDP.  Packets are guaranteed to arrive and
> > be presented at the application level in the same order they were sent.
> > Therefore, you can't be just dropping control characters for
> > screen control
> > on the floor.  Even if there was lag, it would -eventually- clear, and you
> > indicate it just stays squirrelly.
> >
> > Termcap being an issue?  It's the leading cause of odd half-draw and
> > screen corruption issues.  Termcap and/or stty settings getting munged.
> > I've dealt with a lot of flaky emulations over the years and while this is
> > going to sound a bit odd, it "feels" right.  :)  Scientific, I know, but
> > intuition has helped solve a lot of problems for me.
> >
> > I'm just not seeing how the net connectivity could do it.  What's your
> > thinking on the possible vector from network to screen corruption?  If it
> > seems reasonable, I'm happy to brainstorm on it.  I'm just not seeing it
> > without a little prodding.
> >
> > mark->
> >
> > >From inside the gravity well of a singularity, John Esak shouted:
> > > How so?
> > >
> > >
> > > > -----Original Message-----
> > > > From: filepro-list-bounces+john=valar.com at lists.celestial.com
> > > > [mailto:filepro-list-bounces+john=valar.com at lists.celestial.com]On
> > > > Behalf Of Fairlight
> > > > Sent: Wednesday, December 06, 2006 5:22 PM
> > > > To: filePro Mailing List
> > > > Subject: Re: FreeBSD and filePro weirdness
> > > >
> > > >
> > > > Question:  Why would you assume your ISP connection is
> > responsible for an
> > > > application not clearing the screen or only partially
> > clearing it?  That
> > > > seems implausible, and I don't connect those dots, personally.
> > > >
> > > > Sounds like a termcap issue in your specific case, John.
> > > >
> > > > mark->
> > > > --
> > > > Try our new SPF-0 lotion, SunScream[tm].  Get it while it's hot!
> > > > _______________________________________________
> > > > Filepro-list mailing list
> > > > Filepro-list at lists.celestial.com
> > > > http://mailman.celestial.com/mailman/listinfo/filepro-list
> > > _______________________________________________
> > > Filepro-list mailing list
> > > Filepro-list at lists.celestial.com
> > > http://mailman.celestial.com/mailman/listinfo/filepro-list
> >
> > --
> > Try our new SPF-0 lotion, SunScream[tm].  Get it while it's hot!
> > _______________________________________________
> > Filepro-list mailing list
> > Filepro-list at lists.celestial.com
> > http://mailman.celestial.com/mailman/listinfo/filepro-list
> 
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list

-- 
Try our new SPF-0 lotion, SunScream[tm].  Get it while it's hot!