staceyc@sco.COM (Stacey Campbell) (03/01/91)
In article <1504@rascal.UUCP> theo@rascal.UUCP (T. Kramer) writes: >In article <10248@scolex.sco.COM> staceyc@sco.COM (Stacey Campbell) writes: >>You must define an acsc string for your terminal. > >Unfortunatly ACS is not portable across UNIX V.2, XENIX V.2 etc. This is >however, a strict requirement for our code. ACS_ macros work fine on both Xenix 2.3.2 (and later) and SCO Unix with the proviso I mentioned in the previous post that the Xenix tic command does not grok acsc in terminfo source files; in which case use the Unix tic and transport the ticced file back to Xenix. Some SCO products are now moving to curses color, so we develop on Unix and ship the color applications and color terminfo files for Xenix. >I would agree with you >that if I used the ACS_ defines I would not need (w)attron and (w)attrof, >but because our code must be portable including, hopefully, our terminfo >source files I can not depend on ACS_ defines. I've developed a fair bit of public domain code that compiles on BSD, System V.2, V.3.0, and V.3.2 curses and have come to the conclusion that it is very important to follow the manual for System V.2 and System V.3.[0-2] curses. Trying to fake out the ACS_ characters to maintain code portability with non-System V curses can be done, but because non-System V curses doesn't have a generally recognized way of storing ACS information, you will have to develop a system that works for every single terminal you plan on supporting. I usually find myself writing the following code; #ifdef ACS_HLINE box(win, 0, 0); #else UseCruftyBoxHack(win); #endif If you aren't willing to use ifdefs or use a seperate source pool (as seems to be the case) then adding, for example, color to a curses portable application becomes near impossible. >>"REMEMBER THAT sgr AND sgr0 MUST ALWAYS BE SPECIFIED". > >I need the call to (w)attrof as in my actual code I need to output >normal character information after for example having painted a box on >the screen. If you absolutely must use non-standard methods to put alternate characters on your screen then wattron() and wattroff() _will_ do what you want. >The point of my request for >help, however, is why does SCO Opendesktop Development System curses >not output an \E% or \E%% or \E\% but does output AA and BB and \E$ and ... >for the (w)attroff call? I seriously believe that this is a serious bug >in the curses package which makes it difficult if not impossible for me, >and I am sure many others who have selected curses for portability, to >generate production binaries using the SCO UNIX and Opendesktop development >systems! Which prompted me to go back to your original post and try out your program and terminfo file again. :-) The reason the qvt101+so entry is failing isn't exactly glaring, but once you see it all becomes clear. Your qvt101 entry contains the numeric capability xmc#0. The guy who wrote System V.3.2 curses claims that it deals with magic cookies correctly (he posts occasionally to Usenet), though I have yet to see a scrap of documentation that explains what is required of the terminfo file and the curses program (obviously something, otherwise your program would work). I am somewhat confused by the 0 in xmc#0, the manual says the numeric value to xmc is the "number of blank characters left by smso or rmso". If this value is zero then it would seem that there is no magic cookie required, therefore xmc should be removed. Perhaps the 0 is special. Either way, if xmc#0 is removed from the qvt101+so terminfo file the program will emit rmacs. The curses source implements in a number of places; if (! magic_cookie_glitch) turn_off_attributes(); I've added comp.unix.programmer to the Newsgroups line because I know there's some folks there who have dealt with this problem. A simple way to fix the problem is to see if your terminal supports _any_ attributes without magic cookies, then remove xmc and set smso and rmso to that attribute, for Wyse 50s I think this attribute is protected mode. Here is a program that demonstrates the problem; #include <curses.h> int main() { int index; int y, x; initscr(); addch(ACS_ULCORNER); for (index = 1; index < 20; index++) addch(ACS_HLINE); addch(ACS_URCORNER); refresh(); endwin(); } Here's the original terminfo file (with acsc and sgr0 added); # Terminfo source code for my (theo's) qvt101 terminal qp|qvt101+so|Qume qvt101 + terminal, cr=^M, cud1=^J, ind=^J, bel=^G, is2=\E0P\Ew\E.4\E(\EC\E%\EX\E\047\E+\Ef^M\Eg, clear=\E+, tbc=\E3, hts=\E1, sam, cols#80, lines#24, cr=^M, nel=^J, xmc#0, khome=^^, kcuf1=^L, kcub1=^H, kcud1=^J, kcuu1=^K, cup=\E=%p1%' '%+%c%p2%' '%+%c, cvvis=\E.1, cnorm=\E.4\E*, cbt=\EI, cud1=^J, cuf1=^L, cuu1=^K, home=^^, cub1=^H, ul, smso=\E), rmso=\E(, el=\Et, ed=\Ey, il1=\EE, dl1=\ER, dch1=\EW, ich1=\EQ, smul=\EG8, rmul=\EG0, rmacs=\E%%, smacs=\E$, sgr0=\E(\E%%, kf1=^A@^M, kf2=^AA^M, kf3=^AB^M, kf4=^AC^M, kf5=^AD^M, kf6=^AE^M, kf7=^AF^M, kf8=^AG^M, kf9=^AH^M, kf0=^AI^M, acsc=kkllmmjjnnwwvvuuttqqxx, -- Stacey Campbell Internet: staceyc@sco.com UUCP: {uunet,ucscc,att,sq,altos,lotus,sun,microsoft}!sco!staceyc
@usaos.uucp (03/01/91)
Xref: xenitec comp.terminals:1825 sco.opendesktop:592 comp.unix.programmer:1163 Keywords: qvt101, freedom100, curses Message-ID: <10513@scolex.sco.COM> Date: Thu, 28 Feb 91 20:26:18 GMT References: <1502@rascal.UUCP> <10248@scolex.sco.COM> <1504@rascal.UUCP> Sender: news@sco.COM In article <1504@rascal.UUCP> theo@rascal.UUCP (T. Kramer) writes: >In article <10248@scolex.sco.COM> staceyc@sco.COM (Stacey Campbell) writes: >>You must define an acsc string for your terminal. > >Unfortunatly ACS is not portable across UNIX V.2, XENIX V.2 etc. This is >however, a strict requirement for our code. ACS_ macros work fine on both Xenix 2.3.2 (and later) and SCO Unix with the proviso I mentioned in the previous post that the Xenix tic command does not grok acsc in terminfo source files; in which case use the Unix tic and transport the ticced file back to Xenix. Some SCO products are now moving to curses color, so we develop on Unix and ship the color applications and color terminfo files for Xenix. >I would agree with you >that if I used the ACS_ defines I would not need (w)attron and (w)attrof, >but because our code must be portable including, hopefully, our terminfo >source files I can not depend on ACS_ defines. I've developed a fair bit of public domain code that compiles on BSD, System V.2, V.3.0, and V.3.2 curses and have come to the conclusion that it is very important to follow the manual for System V.2 and System V.3.[0-2] curses. Trying to fake out the ACS_ characters to maintain code portability with non-System V curses can be done, but because non-System V curses doesn't have a generally recognized way of storing ACS information, you will have to develop a system that works for every single terminal you plan on supporting. I usually find myself writing the following code; #ifdef ACS_HLINE box(win, 0, 0); #else UseCruftyBoxHack(win); #endif If you aren't willing to use ifdefs or use a seperate source pool (as seems to be the case) then adding, for example, color to a curses portable application becomes near impossible. >>"REMEMBER THAT sgr AND sgr0 MUST ALWAYS BE SPECIFIED". > >I need the call to (w)attrof as in my actual code I need to output >normal character information after for example having painted a box on >the screen. If you absolutely must use non-standard methods to put alternate characters on your screen then wattron() and wattroff() _will_ do what you want. >The point of my request for >help, however, is why does SCO Opendesktop Development System curses >not output an \E% or \E%% or \E\% but does output AA and BB and \E$ and ... >for the (w)attroff call? I seriously believe that this is a serious bug >in the curses package which makes it difficult if not impossible for me, >and I am sure many others who have selected curses for portability, to >generate production binaries using the SCO UNIX and Opendesktop development >systems! Which prompted me to go back to your original post and try out your program and terminfo file again. :-) The reason the qvt101+so entry is failing isn't exactly glaring, but once you see it all becomes clear. Your qvt101 entry contains the numeric capability xmc#0. The guy who wrote System V.3.2 curses claims that it deals with magic cookies correctly (he posts occasionally to Usenet), though I have yet to see a scrap of documentation that explains what is required of the terminfo file and the curses program (obviously something, otherwise your program would work). I am somewhat confused by the 0 in xmc#0, the manual says the numeric value to xmc is the "number of blank characters left by smso or rmso". If this value is zero then it would seem that there is no magic cookie required, therefore xmc should be removed. Perhaps the 0 is special. Either way, if xmc#0 is removed from the qvt101+so terminfo file the program will emit rmacs. The curses source implements in a number of places; if (! magic_cookie_glitch) turn_off_attributes(); I've added comp.unix.programmer to the Newsgroups line because I know there's some folks there who have dealt with this problem. A simple way to fix the problem is to see if your terminal supports _any_ attributes without magic cookies, then remove xmc and set smso and rmso to that attribute, for Wyse 50s I think this attribute is protected mode. Here is a program that demonstrates the problem; #include <curses.h> int main() { int index; int y, x; initscr(); addch(ACS_ULCORNER); for (index = 1; index < 20; index++) addch(ACS_HLINE); addch(ACS_URCORNER); refresh(); endwin(); } Here's the original terminfo file (with acsc and sgr0 added); # Terminfo source code for my (theo's) qvt101 terminal qp|qvt101+so|Qume qvt101 + terminal, cr=^M, cud1=^J, ind=^J, bel=^G, is2=\E0P\Ew\E.4\E(\EC\E%\EX\E\047\E+\Ef^M\Eg, clear=\E+, tbc=\E3, hts=\E1, sam, cols#80, lines#24, cr=^M, nel=^J, xmc#0, khome=^^, kcuf1=^L, kcub1=^H, kcud1=^J, kcuu1=^K, cup=\E=%p1%' '%+%c%p2%' '%+%c, cvvis=\E.1, cnorm=\E.4\E*, cbt=\EI, cud1=^J, cuf1=^L, cuu1=^K, home=^^, cub1=^H, ul, smso=\E), rmso=\E(, el=\Et, ed=\Ey, il1=\EE, dl1=\ER, dch1=\EW, ich1=\EQ, smul=\EG8, rmul=\EG0, rmacs=\E%%, smacs=\E$, sgr0=\E(\E%%, kf1=^A@^M, kf2=^AA^M, kf3=^AB^M, kf4=^AC^M, kf5=^AD^M, kf6=^AE^M, kf7=^AF^M, kf8=^AG^M, kf9=^AH^M, kf0=^AI^M, acsc=kkllmmjjnnwwvvuuttqqxx, -- Stacey Campbell Internet: staceyc@sco.com UUCP: {uunet,ucscc,att,sq,altos,lotus,sun,microsoft}!sco!staceyc
staceyc@sco.COM (Stacey Campbell) (03/07/91)
In article <14405@ulysses.att.com> kpv@ulysses.att.com (Phong Vo[drew]) writes: >In article <10513@scolex.sco.COM>, staceyc@sco.COM (Stacey Campbell) writes: >: becomes clear. Your qvt101 entry contains the numeric capability >: xmc#0. The guy who wrote System V.3.2 curses claims that it deals >: with magic cookies correctly [...] > >On terminals with magic cookies, you must define "xmg" for terminfo >(or "sg" for termcap) for curses to work correctly. >You do not need to do anything else. Now we enter deep water. There is no mention of xmg in either the AT&T 3.2.0 source or AT&T 3.2.1 source. tic definitely doesn't like it. Do you mean xmc? I've compiled the following program with the stock AT&T 3.2.1 curses source and with xmc#0 and xmc#1 and it does not emit the sequence to turn off smacs (either sgr0 or rmacs). Is this a bug in the C example (probably not), terminfo file (maybe, I've never written a magic cookie terminfo file, though it looks okay), or in libcurses.a? Comments? #include <curses.h> int main() { int index; initscr(); addch(ACS_ULCORNER); for (index = 1; index < 20; index++) addch(ACS_HLINE); addch(ACS_URCORNER); refresh(); endwin(); } The terminfo file; # Terminfo source code for theo's qvt101 terminal qp|qvt101+so|Qume qvt101 + terminal, cr=^M, cud1=^J, ind=^J, bel=^G, is2=\E0P\Ew\E.4\E(\EC\E%\EX\E\047\E+\Ef^M\Eg, clear=\E+, tbc=\E3, hts=\E1, sam, cols#80, lines#24, cr=^M, nel=^J, xmc#0, khome=^^, kcuf1=^L, kcub1=^H, kcud1=^J, kcuu1=^K, cup=\E=%p1%' '%+%c%p2%' '%+%c, cvvis=\E.1, cnorm=\E.4\E*, cbt=\EI, cud1=^J, cuf1=^L, cuu1=^K, home=^^, cub1=^H, ul, smso=\E), rmso=\E(, el=\Et, ed=\Ey, il1=\EE, dl1=\ER, dch1=\EW, ich1=\EQ, smul=\EG8, rmul=\EG0, rmacs=\E%%, smacs=\E$, sgr0=\E(\E%%, kf1=^A@^M, kf2=^AA^M, kf3=^AB^M, kf4=^AC^M, kf5=^AD^M, kf6=^AE^M, kf7=^AF^M, kf8=^AG^M, kf9=^AH^M, kf0=^AI^M, acsc=kkllmmjjnnwwvvuuttqqxx, -- Stacey Campbell Internet: staceyc@sco.com UUCP: {uunet,ucscc,att,sq,altos,lotus,sun,microsoft}!sco!staceyc
peter@ficc.ferranti.com (Peter da Silva) (03/07/91)
Some televideo-braindamage style terminals allow you to set the attribute character width to 0, allowing you to write a character in the magic cookie cell. So the magic cookies don't show up on the screen but still do weird stuff like set the rest of the screen to the attribute. Try turning "ms" off and "xs" on. In terminfo, that means you must disable "move_standout_mode" and enable "ceol_standout_glitch". -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
theo@rascal.UUCP (T. Kramer) (03/09/91)
In article <10513@scolex.sco.COM> staceyc@sco.COM (Stacey Campbell) writes: > > ..... Trying to fake out the ACS_ characters to maintain >code portability with non-System V curses can be done, but because >non-System V curses doesn't have a generally recognized way of storing >ACS information, you will have to develop a system that works for every >single terminal you plan on supporting. I usually find myself writing >the following code; > >#ifdef ACS_HLINE > box(win, 0, 0); >#else > UseCruftyBoxHack(win); >#endif We have, in fact, done so. But thanks for the advice all the same, we will probably implement something like your suggestion in a following release :-) >I am somewhat confused by the 0 in xmc#0, the manual says the numeric >value to xmc is the "number of blank characters left by smso or >rmso". If this value is zero then it would seem that there is no >magic cookie required, therefore xmc should be removed. Perhaps >the 0 is special. Either way, if xmc#0 is removed from the qvt101+so >terminfo file the program will emit rmacs. Again, thanks very much for the advice, I have removed the xmc entry from my terminfo source and all works great, except and wait for it, every time I emit wattroff I get a '%' on the screen! Yes it does appear that the double percentage in the rmacs and sgr0 sequences are _not_ required! Sorry, it takes so long for me to respond. Lots of development pressures :-) Another problem that we have for curses is that we can not place an alternate character (not using ACS_ ) at the bottom right hand corner of the screen, This is for all terminals we use ie. SCO ansi, freedom 100, vt100, vt220, qvt101. +-------------------------------+--------------------------------------------+ | theo@rascal | And so the magic cookie crumbles | +-------------------------------+--------------------------------------------+
theo@rascal (03/10/91)
Xref: xenitec comp.terminals:1863 sco.opendesktop:621 comp.unix.programmer:1233 Keywords: qvt101, freedom100, curses Message-ID: <1508@rascal.UUCP> Date: Sat, 09 Mar 91 13:05:16 GMT References: <1502@rascal.UUCP> <10248@scolex.sco.COM> <1504@rascal.UUCP> <10513@scolex.sco.COM> Reply-To: theo@rascal.UUCP (T. Kramer) Followup-To: comp.terminals In article <10513@scolex.sco.COM> staceyc@sco.COM (Stacey Campbell) writes: > > ..... Trying to fake out the ACS_ characters to maintain >code portability with non-System V curses can be done, but because >non-System V curses doesn't have a generally recognized way of storing >ACS information, you will have to develop a system that works for every >single terminal you plan on supporting. I usually find myself writing >the following code; > >#ifdef ACS_HLINE > box(win, 0, 0); >#else > UseCruftyBoxHack(win); >#endif We have, in fact, done so. But thanks for the advice all the same, we will probably implement something like your suggestion in a following release :-) >I am somewhat confused by the 0 in xmc#0, the manual says the numeric >value to xmc is the "number of blank characters left by smso or >rmso". If this value is zero then it would seem that there is no >magic cookie required, therefore xmc should be removed. Perhaps >the 0 is special. Either way, if xmc#0 is removed from the qvt101+so >terminfo file the program will emit rmacs. Again, thanks very much for the advice, I have removed the xmc entry from my terminfo source and all works great, except and wait for it, every time I emit wattroff I get a '%' on the screen! Yes it does appear that the double percentage in the rmacs and sgr0 sequences are _not_ required! Sorry, it takes so long for me to respond. Lots of development pressures :-) Another problem that we have for curses is that we can not place an alternate character (not using ACS_ ) at the bottom right hand corner of the screen, This is for all terminals we use ie. SCO ansi, freedom 100, vt100, vt220, qvt101. +-------------------------------+--------------------------------------------+ | theo@rascal | And so the magic cookie crumbles | +-------------------------------+--------------------------------------------+
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (03/15/91)
As quoted from <9103100200.aa15841@xenitec.on.ca> by theo@rascal: +--------------- | Again, thanks very much for the advice, I have removed the xmc entry from | my terminfo source and all works great, except and wait for it, every time | I emit wattroff I get a '%' on the screen! Yes it does appear that the double | percentage in the rmacs and sgr0 sequences are _not_ required! +--------------- Correct. You need only use a double % when the sequence is parameterized; see the terminfo man page. In particular, "sgr" is parameterized but "rmacs" and "sgr0" are not. ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR on 40m, 10m when time Internet: allbery@NCoast.ORG permits; also 2m, 220, 440, 1200 America OnLine: KB8JRR // Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH