jwp@larry.sal.wisc.edu (Jeffrey W Percival) (05/02/89)
I am running Ultrix 2.2 and 3.0, and noticed that although cbreak and nocbreak are mentioned in the curses man pages, they do not exist in /lib/libcurses.a! Is this an error? Where can I get them? Have they been displaced by some other call? -- Jeff Percival (jwp@larry.sal.wisc.edu)
rmyers@net1.ucsd.edu (Robert Myers) (05/03/89)
In article <172@larry.sal.wisc.edu> jwp@larry.sal.wisc.edu (Jeffrey W Percival) writes: >cbreak and nocbreak are mentioned in the curses man pages, >they do not exist in /lib/libcurses.a! I think you need to use crmode() and nocrmode(). Raul Rathmann - raul%sdnp1@ucsd.edu
grr@cbmvax.UUCP (George Robbins) (05/03/89)
In article <172@larry.sal.wisc.edu> jwp@larry.sal.wisc.edu (Jeffrey W Percival) writes: > I am running Ultrix 2.2 and 3.0, and noticed that although > cbreak and nocbreak are mentioned in the curses man pages, > they do not exist in /lib/libcurses.a! > > Is this an error? Where can I get them? Have they been > displaced by some other call? Traditionally, BSD has used "crmode()" for this purpose. In the 4.3BSD curses.h header file, cbreak and crmode are made equivalent. Apparently, the DEC folks haven't implemented this change. There is also a long standing "bug" with Ultrix curses that shows up if you try to make the net.sources "sc" spread sheet program under Ultrix. If you do it under 4.3 it works fine, and the 4.3 executable works fine with Ultrix, but if you do the compile under Ultrix, you get this intersting diagonal effect instead of columns. It may be fixed in 3.0, I don't know... Apparently some confused person at DEC tried to "fix" some other "bug" he perceived with curses, but broke the proper operation... Adding the following lines to the end of sc.h (or curses.h 8-) backs out the screwup... #ifdef ultrix #undef nl #undef nonl #define nl() (_tty.sg_flags |= CRMOD,_pfast = _rawmode,stty(_tty_ch, &_tty)) #define nonl() (_tty.sg_flags &= ~CRMOD, _pfast = TRUE, stty(_tty_ch, &_tty)) #endif -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
gordon@prls.UUCP (Gordon Vickers) (05/03/89)
In article <6745@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes:
->
->There is also a long standing "bug" with Ultrix curses that shows up if
->you try to make the net.sources "sc" spread sheet program under Ultrix.
->If you do it under 4.3 it works fine, and the 4.3 executable works fine
->with Ultrix, but if you do the compile under Ultrix, you get this intersting
->diagonal effect instead of columns. It may be fixed in 3.0, I don't know...
Yes, It's been fixed in Ultrix 3.0
->Apparently some confused person at DEC tried to "fix" some other "bug" he
->perceived with curses, but broke the proper operation... Adding the
->following lines to the end of sc.h (or curses.h 8-) backs out the screwup...
->
->#ifdef ultrix
->#undef nl
->#undef nonl
->#define nl() (_tty.sg_flags |= CRMOD,_pfast = _rawmode,stty(_tty_ch, &_tty))
->#define nonl() (_tty.sg_flags &= ~CRMOD, _pfast = TRUE, stty(_tty_ch, &_tty))
->#endif
Or, make the change in curses.h so you won't have to troubleshoot
the problem later when you try to compile something else.hobbes@Portia.Stanford.EDU (Andrew Zimmerman) (05/05/89)
In article <172@larry.sal.wisc.edu>, jwp@larry.sal.wisc.edu (Jeffrey W Percival) writes: > I am running Ultrix 2.2 and 3.0, and noticed that although > cbreak and nocbreak are mentioned in the curses man pages, > they do not exist in /lib/libcurses.a! > > Is this an error? Where can I get them? Have they been > displaced by some other call? > -- > Jeff Percival (jwp@larry.sal.wisc.edu) As the previous article mentions, cbreak, and nocbreak don't exist in /lib/libcurses.a. Instead, DEC has chosen to put them in /lib/libcursesX.a. If memory serves my right, there is also a different include file for this package. I ran across this problem a couple of month ago when I tried to compile the unix spreadsheet program sc. Actaully, DEC's libs are becoming a major pet peeve of mine. In addition to the above problem, I have a had lib problems with both xdvi and just today with xfig. The problem with xdvi was that it used some of the athena libs. When I talked to DEC about it, they said that they have chosen not to support the athena libs. This would have been fine with me, but the routine that was calling the anthena funtion was part of DEC's library. When compiling xfig, I got the message that calloc was multiple defined. It turns out that calloc was defined in both libc.a and libX11.a. After removing the function Xvmsalloc.o from libX11.a xfig compiled. In the case of xdm, I finally just gave up. Although it did compile, it have major problems handling the display. It has gotten to the point that I am beginning to question the choice of using DEC equipment with the Xwindow environment. Orignally, we tried to use decwindow, but the rest of the users complained that it was two slow. Even though this was true, I continued to encourage the use of decwindows, until a user showed me how to become su through a bug in decwindows. It was at this point that we switched over to "X11". Sorry to be so negative of DEC. In general we have had very good luck with their hardware and service. However, in my opinion, DEC's software could be improved. Andrew Zimmerman zimmer@calvin.stanford.edu (a DEC 3200 running Ultrix 3.0)