lmc@cisden.UUCP (Lyle McElhaney) (10/29/85)
Pet peeve time: Many newer terminals have features that didn't exist back when Mark Horton first (or even the second or third time) wrote termcap. When it was young, it seems to have experienced growth and change (witness the obsolete functions that still exist). However, over what appears to be the last 5 years or so the capability repertoire has been frozen. Doug Gwynn has told me in the past that new entries to the "official" termcap repertory are not being made in order to keep termcap compatible with terminfo. With all due respect, there is another possibility allowed by that argument: change terminfo too. The whole idea of termcap was to provide a common interface to all the terminals available; it is easy to see how termcaps could be constructed to cover these newer terminal features, but it seems to never get done. Nuts, I don't care if anyone uses the conventions that I established (for my own programs) to use line- drawing character sets; I just wish that there were some common place where they were accepted (rejected) and thereafter appeared in termcaps where they are applicable. Then I wouldn't feel guilty about using Gs/Ge in a program without adding 30 lines of comments to explain it all. While I'm at it, wouldn't it be nice if termcap.... ...looked for an entry in ~.termcap before running off to /etc/termcap? ...set BUFSIZ to 2048 rather than 1024? ...edited out redundancies from the termcap entries (to make them smaller, barring the 2048 BUFSIZ mentioned above)? ...had a way of saying, essentially, that rs is the same string as is (for example)? This could certainly be done by convention, by saying in some authoritative way that rs defaults to is if is is not given, but tset (for one) doesn't use that rule, and therefore it isn't followed. I guess that I want a software way in termcap to enforce defaults. And now that I've finished knocking everything, I'll say that I'm posting to mod.sources a program which I knocked together to provide termcap capabilities to shell programs. It, for example, would clear the screen given the command "tc cd", turn on an auxilliary printer given "tc po", and place the cursor in the middle of the screen given "tc cm 11 39". More on all of the above later. Lyle McElhaney ....cisden!lmc
chris@umcp-cs.UUCP (Chris Torek) (10/30/85)
Among other things, you suggest that termcap use a 2048 byte buffer (as opposed to the current 1024 byte buffers found in most programs). Well, having 2048 characters to work with would help, but still that is not really right: one should dynamically allocate enough space to hold the termcap entry, however large it may be. By the way, note that termcap buffers must be provided in three (!) places, at least with the current implementation in 4.3BSD: in -ltermlib itself---termcap.c has several 1024 byte buffers; and twice in user code: once for the buffer into which the termcap is stored and once more for the buffer into which decoded strings are stored by tgetstr(). Worse yet, there is no manifest constant anywhere. Programs simply assume a maximum of 1024 bytes, or whatever worked for the programmer. As I recall, 4.2BSD curses assumed that there were at most 128 characters of decoded strings, untrue in several of my own termcaps. I have never quite understood why the interface provided by the termcap library is as it is; I would prefer something like char * tgetent(type) char *type; Returns a pointer to the termcap entry for terminal type `type', or NULL if it could not be found. The termcap entry is in static space, thus overwritten by future calls. int tgetflag(te, fl) char *te, *fl; Returns true iff flag `fl' is set in termcap entry `te'. int tgetnum(te, nu) char *te, *nu; Returns the value of `nu' in termcap entry `te', or -1 if not set. char * tgetstr(te, st) char *te, *st; Returns a pointer to the decoded string `st' from termcap `te'. The string is in dynamically allocated space. Less efficient, perhaps, but cleaner---and no other code need assume *anything* about the size of termcap entries. But alas, it is too late for termcap. Terminfo is better anyway. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (11/01/85)
The termcap capabilities described in the 1980 manual entry have since been augmented somewhat, and several of their meanings have been clarified; an updated manual entry is in the works which may make it into 4.3BSD. An early version of this manual entry has been distributed with BRL software. However, it is true that there has been no consensus on capabilities for such things as box-construction graphics and color. I believe Mark once mentioned that terminfo may support these at some future date; if we could all come to a consensus on what these capabilities are then termcap names for them could easily be invented (maybe adopt Lyle's) and added to the "official" description. There is of course a limit to how far the termcap model of a "terminal" can be pushed; it really cannot cope with true graphics, bitmaps, etc. Terminfo has a better design for adding things such as multiple windows, etc., but its underlying model is similar. In general, termcap has enough significant design deficiencies that future efforts should be concentrated on terminfo instead. > While I'm at it, wouldn't it be nice if termcap.... > > ...looked for an entry in ~.termcap before running off to > /etc/termcap? The TERMCAP environment variable, while not accomplishing precisely the same action, is intended for this sort of thing. > ...set BUFSIZ to 2048 rather than 1024? Chris Torek answered this one nicely. > ...edited out redundancies from the termcap entries (to make them > smaller, barring the 2048 BUFSIZ mentioned above)? We do this ourselves for terminals in heavy use here; their entries in /etc/termcap are self-contained and non-redundant. > ...had a way of saying, essentially, that rs is the same string as > is (for example)? This could certainly be done by convention, > by saying in some authoritative way that rs defaults to is if > is is not given, but tset (for one) doesn't use that rule, and > therefore it isn't followed. I guess that I want a software way > in termcap to enforce defaults. This should be a tset/reset function, not a termcap rule. > And now that I've finished knocking everything, I'll say that I'm posting > to mod.sources a program which I knocked together to provide termcap > capabilities to shell programs. It, for example, would clear the screen > given the command "tc cd", turn on an auxilliary printer given "tc po", > and place the cursor in the middle of the screen given "tc cm 11 39". SVR2 (terminfo) has a corresponding utility called "tputs".
lmc@cisden.UUCP (Lyle McElhaney) (11/07/85)
> an updated manual entry is in > the works which may make it into 4.3BSD. An early version > of this manual entry has been distributed with BRL software. > Could you send me a copy? Thanks. > However, it is true that there has been no consensus on > capabilities for such things as box-construction graphics > and color. I believe Mark once mentioned that terminfo > may support these at some future date; if we could all > come to a consensus on what these capabilities are then > termcap names for them could easily be invented (maybe > adopt Lyle's) and added to the "official" description. > Well, the convention I use was posted way-back by eric@aerospace, and consist of the string variables Gs (into line-drawing mode), Ge (out of line-drawing mode), Tl, Tr, Bl, Br (corners), Vl, Hl (lines), Tj, Bj, Lj, Rj (joins; Lj is |-) Cj (center join, or cross) and Xc (extra character, like diamond or box or other character available in line-drawing mode). I haven't found a terminal with l-d yet that this won't work with (except the execrable ADM-11, with magic cookies to go in and out of l-d). Anyone have a counter example? > There is of course a limit to how far the termcap model > of a "terminal" can be pushed; it really cannot cope > with true graphics, bitmaps, etc. Terminfo has a better > design for adding things such as multiple windows, etc., > but its underlying model is similar. > Yes, absolutely. But termcap is more available (maybe because it is much simpler to implement) than terminfo, and available on more machines. On the restricted set of character-oriented terminals (still in the great majority) it does excellently, providing the standard for adding/deleting/refining caps is available. Its like the government mandating uhf receivers on TVs; useless at the time, but now there is an audience for the uhf station. No one will write software using new capabilities unless there is a guaranteed "market" in which the cap is defined and exists in published termcaps. Same goes for terminfo, by the way, as well as library routines etc etc. > In general, termcap has enough significant design > deficiencies that future efforts should be concentrated > on terminfo instead. > Yes, true. It may well even be too late for terminfo. > > ...looked for an entry in ~.termcap before running off to > > /etc/termcap? > > The TERMCAP environment variable, while not accomplishing > precisely the same action, is intended for this sort of > thing. > Yes, except that it useless when, after TERMCAP gets properly set, you need to execute tset (or reset) to get your terminal back after an accidental insanity. The reset strings in the published termcaps are often too "weak" to correct things, but I can't get to my own... Lyle McElhaney ...cisden!lmc
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (11/08/85)
> > > ...looked for an entry in ~.termcap before running off to > > > /etc/termcap? > > > > The TERMCAP environment variable, while not accomplishing > > precisely the same action, is intended for this sort of > > thing. > > > Yes, except that it useless when, after TERMCAP gets properly set, you > need to execute tset (or reset) to get your terminal back after an > accidental insanity. The reset strings in the published termcaps are often > too "weak" to correct things, but I can't get to my own... I don't understand this. Setting TERMCAP=$HOME/.termcap will substitute your own termcap file for /etc/termcap. Perhaps you were thinking that $TERMCAP could only contain the actual terminal description? If it starts with a `/' it is assumed to be the pathname of a file..