fnf@estinc.UUCP (Fred Fish) (03/30/89)
/*
* This little program demonstrates what I believe to be a bug
* in the SCO 2.3 development package curses library. During
* installation, the "terminfo curses" option was selected.
* There is garbage standout "blanks" left at the end of a line.
*
* Compile as "cc -o cursesbug2 cursesbug2.c -lcurses"
*
* Note that you have to have the environment variable
* TERM=ansi (the default) and the length of the strings
* is significant.
*
*/
#include <curses.h>
main ()
{
initscr ();
move (0,3);
standout ();
printw ("this is standout!");
standend ();
move (0,30);
printw ("this is just a normal run of text..");
refresh ();
erase ();
move (0,3);
standout ();
printw ("standout again!");
standend ();
move (0,30);
printw ("note the garbage standout at end of line");
refresh ();
endwin ();
}
--
# Fred Fish, 1835 E. Belmont Drive, Tempe, AZ 85284, USA
# 1-602-491-0048 asuvax!{nud,mcdphx}!estinc!fnferskine@dalcsug.UUCP (Neil Erskine) (04/02/89)
][b In article <74@estinc.UUCP> fnf@estinc.UUCP (Fred Fish) writes: > >/* > * This little program demonstrates what I believe to be a bug ... short curses program that ends with reverse video spaces appearing where they ought not... > The bug is actually in the console device driver, which does not perform the ANSI standard actions for ANSI standard sequences. The bug arises with the clear sequences, which are SUPPOSED to remove all graphic symbols (characters) and associated graphic renditions (character attributes) from the affected area. Instead it effectively pushes the current cursor position, writes spaces into the affected area, and pops the cursor position. The result, if you happen to be in reverse video mode, is that reverse video spaces are written in the area you ordered cleared. Curses assumes (quite reasonably) that the 'terminal' works properly. The same problem arises when you write a newline on the last line of the screen while in reverse video mode: You end up with a complete line of reverse video spaces at the bottom of the screen. Easy way to recreate: type to the shell \E[7m\E[K\n replacing \E with the ESC code, and \n with RETURN. I have reported this bug a few times per year, including references to ANSI documents (page/section/paragraph ad nauseum), since 1984 (Xeinx-86), but SCO shows no interest in repairing it, even though they recently 'rewrote' the damn thing (or so they claim). A couple of times SCO admitted that it was a bug, a couple of times they said "wait for the next release, and let us know if the problem is still there", and a couple of times they said it "might be a bug, I dunno". (Notes in quotes are the gist only, not true quotes). They have never said they would fix it. It is interesting to note that when IBM Xenix was being distributed, and I reported the identical problem to IBM, THEY admitted that it didn't work according to ANSI standard (but then weaseled out of fixing it by saying that they didn't claim to implement the ANSI standard; the fact that escape sequences and names matched the ANSI sequences and names was coincidental). SCO however DOES make the claim that they implement that standard. Can ANSI take action against a company falsely claiming to support an ANSI standard? CONCLUSION: Do not ever expect to get a version of curses from SCO that works around SCO's bugs. They aren't interested. At the company I work for we ended up dumping SCO's curses and writing our own. A workaround that works most of the time (at the expense of having reverse video disappear sometimes) is to code \E[0m at the beginning of all your clear sequences for the console. Postscript: On the whole we were fairly pleased with SCO's support. Their product has never been particularly slick, but it usually works. They just don't care to play with making things work exactly right; almost right seems to be close enough for them. Their sales have proved this attitude to be a profitable one. ||!][b
kevin@iisat.UUCP (Kevin Davies) (04/03/89)
In article <366@dalcsug.UUCP>, erskine@dalcsug.UUCP (Neil Erskine) writes: > ][b > In article <74@estinc.UUCP> fnf@estinc.UUCP (Fred Fish) writes: > ... short curses program that ends with reverse video spaces appearing > where they ought not... > > > ... A description of what the actual problem is within the SCO driver... > ... paragraph on reporting this bug to SCO etc. > It is interesting to note that when IBM Xenix was being > distributed, and I reported the identical problem to IBM, THEY > admitted that it didn't work according to ANSI standard (but then > weaseled out of fixing it by saying that they didn't claim to > implement the ANSI standard; the fact that escape sequences and names > matched the ANSI sequences and names was coincidental). I would say that this (particular) curses bug is only found in the SCO and IBM distributions. I tried it on Tandy Xenix (1.0) which is roughly equivalent to SCO 2.2 (286 version) which is based on the Microsoft base with some AT&T copyrights. Both bugs 2 & 3 worked without any of the problems that have been reported. What I have seen in some curses implementations is the need to do a refresh() before and after and stand[end|out] mode, otherwise the command would not seem to have any affect. So I was plesantly surprised that these 2 code fragments ran without any difficulties. It must be something in the console driver specific to the SCO and IBM distributions (Did IBM use SCO as a distribution base?). -- Kevin Davies International Information Service (IIS) UUCP: {uunet,utai,watmath}!dalcs!iisat!kevin Bitnet/Uucp: kevin@iisat.uucp Arpanet: kevin%iisat.uucp@uunet.uu.net