dave@well.UUCP (Dave Hughes) (08/13/88)
We have two problems of adapting Foxbase db under Xenix,
both 286 and 386 to user interface realities. First, Foxbase db,
always opens with a hard-coded commercial banner before it goes
on to either the dot prompt or execute the first db program.
Secondly - if modem-callers who do NOT have terminal emulation
programs run it - plain tty mode - the whole session is
punctuated by OOPS's (coming from curses, I guess), and is
totally unsatisfactory.
We are using Foxbase db (DbaseIII+ compatible) for
online teachers in schools invariably equipped with low end
1200 baud Apples with as often as not, no terminal-emulation
software (some of which is hard-coded in modem ROMs).
We *want* to blank out the Foxbase banner (which usually
throws an elementary school teacher for a loop) but we *must*
filter out the OOPS for those who choose the 'tty' termcap mode.
Calls to SCO result in the comeback "Fox wants to force
that opening screen on everybody." And of course nobody ever
thought that 116 one-room school house teachers in Montana would
ever be using tty Apple IIs or printing terminals to run a
lesson plan data base remotely - so OOPS is a way of saying
"Get a fancy terminal."
We have a kludge that works, but introduces other
problems.
$foxplus search.prg | sed -f nooops
Where nooops is 1,4d s/OOPS//g in a little script file.
1,4d masks out the opening screen, and s/OOPS//g
converts the OOPS to spaces, but sed always holds the current
line in the pattern space until the following line runs.
Consequently the following programs never display the
last, usually an 'instruction' line, at page or program
pauses until an Enter is pressed. Then it displays it, such
as 'Press any key to continue' but too late. We can't get the
'p' or 'P' sed parameter to flush the pattern space at
pauses. (Probably don't have the syntax right here)
So sed works but not very well. 'tr' can't seem
to translate only a 'set' of chars "OOPS", but deletes all
subsequent Os, Ps, Ss individually too. And awk is a
mystery.
Any simple solutions here to our little problem?
Dave Hughes
** If a thing is worth doing at all, its worth doing badly **
hplabs!well!davedet@hawkmoon.MN.ORG (Derek E. Terveer) (08/22/88)
In article <6808@well.UUCP>, dave@well.UUCP (Dave Hughes) writes: > [First problem] > Secondly - if modem-callers who do NOT have terminal emulation > programs run it - plain tty mode - the whole session is > punctuated by OOPS's (coming from curses, I guess), and is > totally unsatisfactory. I've run into the exact same problem that you have seen when entering new terminals into the /etc/termcap file. Apparently, the OOPS is an exclaimation of suprise by curses when it encounters things in the termcap file it doesn't understand. This doesn't seem to be a documented feature. I have *not* seen this problem in terminfo files. I have seen the OOPS result in two different cases: 1. Any kind of capatilized capabilities in the termcap entry, such as "AL", etc. Just delete all capatilized capabilities. These are mostly "multiple commands" anyway, such as >1 line delete, etc., which vi doesn't seem to use anyway! (arg! (:-() 2. Any time there are the following type of push strings in the capability, for example, %p1 or %p2. I simply deleted these strings with "1,$s/%p[12]//g" in vi. The removal of these substrings from the capabilities removed the obnoxious OOPS from the screen and didn't seem to affect the curses capability. Good luck, hope this helps! derek
peter@ficc.UUCP (Peter da Silva) (08/23/88)
In article <269@hawkmoon.MN.ORG>, det@hawkmoon.MN.ORG (Derek E. Terveer) writes: > Apparently, the OOPS is an exclaimation of suprise by curses when it > encounters things in the termcap file it doesn't understand. This > doesn't seem to be a documented feature. Actually it's a documented error message from termlib which is what curses uses to do the actual termcap stuff on Version 7 based curses. It is caused by tgoto when it is given an invalid :cm: string, either because tgetstr didn't find the string (perhaps your .profiles aren't set up right for dialups... try "TERM=xxx; export TERM" or "setenv TERM xxx"), or when the string contains unexpected escape sequences (your termlib might be more advanced than foxbase's: %p is not a standard termcap function, it's borrowed from terminfo). tgoto is called for all parameterised sequences, which explains why multiline deletes could cause problems. See if you can find an older termcap definition, say from a V7 or BSD manual, and try cutting anything that doesn't show up in that. -- Peter da Silva `-_-' Ferranti International Controls Corporation. "Have you hugged U your wolf today?" sugar.uu.net!ficc!peter.
daveh@marob.MASA.COM (Dave Hammond) (08/24/88)
>In article <6808@well.UUCP>, dave@well.UUCP (Dave Hughes) writes: > >I've run into the exact same problem that you have seen when entering new >terminals into the /etc/termcap file. > >Apparently, the OOPS is an exclaimation of suprise by curses when it encounters >things in the termcap file it doesn't understand. This doesn't seem to be a >documented feature. I have *not* seen this problem in terminfo files. OOPS is indeed an expression of surprise, but from the Termcap routine tgoto(), not Curses. Which also explains why Terminfo does not exhibit the problem. It is documented in an older V7 TERMCAP(3) manpage: `If a % sequence is given which is not understood, then tgoto returns OOPS.' > >I have seen the OOPS result in two different cases: > > 1. Any kind of capatilized capabilities in the termcap entry, such as > "AL", etc.[...stuff deleted...] > 2. Any time there are the following type of push strings in the > capability, for example, %p1 or %p2 [...more deleted...] Most notably, OOPS appears when the CM capability is absent (as is the case with plain tty mode). Curses knows enough to just output spaces and newlines if it receives OOPS from tgoto, but programs making direct Termcap calls may not know to check for this (as appears to be the case with FoxBase). Dave Hammond UUCP: {uunet|...}!masa.com!{dsix2|marob}!daveh DOMAIN: dsix2!daveh@masa.com ------------------------------------------------------------------------------
ray@madnix.UUCP (Ray P. Hill) (08/24/88)
In article <6808@well.UUCP>, dave@well.UUCP (Dave Hughes) writes: > Secondly - if modem-callers who do NOT have terminal emulation > programs run it - plain tty mode - the whole session is > punctuated by OOPS's (coming from curses, I guess), and is > totally unsatisfactory. The "OOPS" error comes from the termcap call "tgoto". According to the XENIX docs: "If a % sequence is given which is not understood, then tgoto returns OOPS". According to "Advanced C Programming for Displays" (page 70): "In case of error, tgoto returns a very strange error indication: the string OOPS. If you ever run a screen program that displays that your terminal, you'll know where it came from!" This book also says that termcap entries for "BC" and "UP" are required for programs that use "tgoto". That means to run the program your users will HAVE to have some sort of terminal emulation. Ray Hill -- UUCP: {harvard|rutgers|ucbvax}!uwvax!nicmad!madnix!ray {decvax|att}!
root@unibase.UUCP (Super User) (09/02/88)
I am using Foxbase (not +) on my xenix system and also must
display information to schools using apples. There are two ways
in which I attempt to get around the problem of screen
emulation... first I make a lot of use of ? for printing to
screen rather than @ say statements. The second solution was
to set up a termcap entry for the apple. I have added the
following entry to my termcap file, and I know that it works
with some of the communications programs that do not support
terminal emulation.
z2|appleIIe|appleII|appleII plus:\
:am:bs:co#80:li#24:cl=^L:ce=^]:cd=^K:\
:cm=^^%r%+ %+ :\
:se=^N:so=^O:ho=\E^Y:nd=^\:\
:ku=^K:kd=^J:kl=^H:kr=^U:kb=\177
I am running a system for educators here in Saskatchewan and
would be interested in discussing possibilities of interaction
between teachers on your system an this one. I have been
talking with educators in New York and Montana about promoting
some international activity discussing educational issues for
K-12 teachers. If you would be interested in this, please
contact me either on the system or direct by voice.
uunet!mcl!unibase!leigh
Leigh Calnek Co-ordinator, Education Technology
3002 Harding St. E. Saskatchewan Education
Regina, Sk. Canada 2220 College Ave.
S4V 0Y4 Regina, Sk. Canada
phone: home (306)789-9007 S4P 3V7
bus. (306)787-9448