NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/unix/bsd/5472

Text File | 1992-09-10 | 3.9 KB | 82 lines

Newsgroups: comp.unix.bsd
Path: sparky!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: [e-mail] (Terry Lambert)
Subject: Re: AT&T Long Distance Boycott (was: BNR2SS, Mach, and The Lawsuit)
Message-ID: <[e-mail]>
Sender: [e-mail] (Usenet News)
Nntp-Posting-Host: thisbe.eng.sandy.novell.com
Organization: Novell NPD -- Sandy, UT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 10 Sep 1992 16:33:12 GMT
Lines: 69

In article <[e-mail]> [e-mail] (Sean Eric Fagan) writes:
>In article <[e-mail]> [e-mail] (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
                    [e-mail]
                    [e-mail]

---
Disclaimer:  Any opinions in this posting are my own and not those of
my present or previous employers.