Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel!munnari.oz.au!spool.mu.edu!uunet!paladin.american.edu!gatech!news.byu.edu!ux1!fcom.cc.utah.edu!park.uvcc.edu!ns.novell.com!thisbe.Eng.Sandy.Novell.COM!terry From: terry@thisbe.Eng.Sandy.Novell.COM (Terry Lambert) Subject: Re: AT&T Long Distance Boycott (was: BNR2SS, Mach, and The Lawsuit) Message-ID: <BuDFBD.MJL@Novell.COM> Sender: usenet@Novell.COM (Usenet News) Nntp-Posting-Host: thisbe.eng.sandy.novell.com Organization: Novell NPD -- Sandy, UT References: <1992Sep08.192000.4488@kithrup.COM> <1992Sep10.015548.4228@pegasus.com> <1992Sep10.055834.6643@kithrup.COM> Date: Thu, 10 Sep 1992 16:33:12 GMT Lines: 69 In article <1992Sep10.055834.6643@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >In article <1992Sep10.015548.4228@pegasus.com> richard@pegasus.com (Richard Foulk) writes: >>Termcap/terminfo is a standard that's available on, pretty much, all >>Unixes. So why leave it out of the POSIX standard? > >Termcap and terminfo are two different things. Or aren't you aware of that? >Which one should be standardised on? > >Choose termcap, and you choose an outdated, limited, and obsolete >technology. That you can expand without having to modify a structure and re-tic all the terminfo files and recompile all applications relying on the library routines (which you also have to rebuild). For istance, how do I support named attributes for graphic characters no in the VT100 alternate set with terminfo? >Choose terminfo, and you leave out all of the non-SysV sites out there, such >as BSD systems. And you are still choosing a limited and obsolete >technology. But not outdated, I suppose... 8-). >Create an alternative, and you run the risk of creating something that is >unworkable, overly complicated, difficult to implement, or just out and out >broken. Ask Henry Spencer or Dan Bernstein about that. And precisely what you are suggesting for porting to nominally "standard" environments based on POSIX. You can't have it both ways, Sean. I think the real question is not support of a particular data format (since most of us have untic/tic/infocmp/infocap/captoinfo if we're into hacking terminal definitions, anyway), but support for standard curses libraries, and what has historically been called "the termcap library". This means the functions, tgetent(), tgetstr(), tgetnum(), tgetflag(), tgoto(), and tputs(), and some arbitrary mechanism for changing the assumed "rows" and "columns" values which act as soft limits for these functions, so that you can implement window resizing and the functional equivalent of SIGWINCH. I think most people who are only interested in using an existing terminal definition could care less what the underlying data storage mechanism was. They just want the functions above with an ISO standard curses library on top of it. VMS, to take our non-UNIX "POSIX" example again, has a database of terminal information, but has no "termcap" library to get at it, and it's curses library is non-ISO, both of which are "bad things". There was no good [non-political] reason to leave the "termcap" and "curses" library *functions* out of POSIX (and to hell with the underlying data format, which only serves to muddy the issue of why the data isn't available in any form, which is the real issue). I reiterate (for the umpteenth time) POSIX is a good first step, but it is certainly not sufficient as the type of platform you paint it. I can more easily port an application to 386bsd (which has *not* passed a POSIX validation test) than to VMS (which has). Both Robert Withrow and myself have a certain amount of experience in this area, and POSIX is simply not sufficient for out-of-the-box compilation, nor is it functionally sufficient such that all applications can be coded strictly within it's bounds and fulfill requirements. Terry Lambert terry_lambert@gateway.novell.com terry@icarus.weber.edu --- Disclaimer: Any opinions in this posting are my own and not those of my present or previous employers.