bernsten@phoenix.Princeton.EDU (Dan Bernstein) (02/19/89)
DESCRIPTION: It appears on several BSD and ULTRIX systems that sysline(1) does not check that for an environment TERMCAP before searching /etc/termcap. There is no apparent way to specify a different termcap file to sysline. This means that individual users cannot use sysline with individually installed terminal descriptions. REPEAT-BY: Find a terminal whose /etc/termcap description does not have ds, es, or fs. Set your TERMCAP variable to be the standard termcap for that terminal, plus any ds, es, and fs strings. Observe that sysline does not recognize the environment TERMCAP. Similarly, by changing TERM, TERMCAP, and /etc/termcap, convince yourself that sysline searches for TERM within /etc/termcap, and only works if the /etc/termcap description has the appropriate strings. FIX: Not having sysline source, I have so far been content to write my own code to use the terminal status line. I suspect that termcap is used in sysline without using the termcap(3) routines. ---Dan Bernstein, bernsten@phoenix.princeton.edu
guy@auspex.UUCP (Guy Harris) (02/21/89)
>Find a terminal whose /etc/termcap description does not have ds, es, or >fs. Set your TERMCAP variable to be the standard termcap for that >terminal, plus any ds, es, and fs strings. Observe that sysline does >not recognize the environment TERMCAP. It worked for me when I compiled the "sysline" from the 4.3BSD source (making minor changes as necessary, none of which had anything to do with the "termcap" code) and set TERMCAP to the standard "sun" entry plus the stuff from the "sun-s" entry. >Not having sysline source, I have so far been content to write my own >code to use the terminal status line. I suspect that termcap is used in >sysline without using the termcap(3) routines. Nope - at least not in the 4.3BSD version; it uses the standard "termcap" routines to fetch them. Maybe the versions you worked with either 1) were built against a broken version of the "termcap" library that fails to recognize TERMCAP or 2) were older versions that didn't use the "termcap" library?
david@ms.uky.edu (David Herron -- One of the vertebrae) (02/24/89)
As long as people are talking about sysline ...
We have a number of terminals here which if you print in the last
character position on the screen the terminal does a "CR". If this
was done as part of a status line update, the following "fs" (from
status-line) stuff ends up with the cursor at the beginning of the line
that it originally came from.
This is (at least) on Ampex 210's and TVI 950's. (I think). I know this
is for certain on the Ampex 210's. (A210's are *VERY* similar to TVI925's)
The fix we had here .. er .. well, the fix hasn't survived over the years
I'm afraid. It was fixed under 4.3bsd as I recall but when we back-pedalled
to Ultrix v2.2 (now v3.0) the fixed version was lost. But the fix was
to make sure it *NEVER* printed beyond column 79. If I remember aright
there is some code which checks a setting in the termcap entry, and we
changed that code to be one character more stringent than before.
--
<-- David Herron; an MMDF guy <david@ms.uky.edu>
<-- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<-- Now I know how Zonker felt when he graduated ...
<-- Stop! Wait! I didn't mean to!romain@pyramid.pyramid.com (Romain Kang) (02/25/89)
In article <11142@s.ms.uky.edu> david@ms.uky.edu (David Herron -- One of the vertebrae) writes: | We have a number of terminals here which if you print in the last | character position on the screen the terminal does a "CR". If this | was done as part of a status line update, the following "fs" (from | status-line) stuff ends up with the cursor at the beginning of the line | that it originally came from. | This is (at least) on Ampex 210's and TVI 950's. (I think). I know this | is for certain on the Ampex 210's. (A210's are *VERY* similar to TVI925's) The problem you describe certainly exists in vanilla 4.3 sysline used with "magic cookie terminals". For example, Wyse 50's and Wyse 50 emulators, like Ampex 230's actually have a a 78-column bottom status line (in 80-column mode). (I'm assuming that A230's are similar to A210's.) For these terminals, you avoid going past column 77. Lou Salkind of NYU had a fix that looked for a "cg" numeric attribute, which I guess meant "column gap". This is the difference between the width of the terminal screen and the width of the sysline. So a Wyse 50 would use "cg#2". Additionally, since there's a "ws" attribute described the 4.3BSD termcap(5), it seems reasonable to use that, if it's available. Here's a diff against "sysline.c 5.6 (Berkeley) 1/9/86": *************** *** 1182,1187 } ! /* the "-1" below is to avoid cursor wraparound problems */ ! columns = tgetnum("co") - 1; if (window) { strcpy(to_status_line, "\r"); --- 1187,1198 ----- } ! if ((columns = tgetnum("ws")) < 0) { ! int gap; ! columns = tgetnum("co"); ! if ((gap = tgetnum("cg")) > 0) ! columns -= gap; ! } ! columns--; /* avoid cursor wraparound */ ! if (window) { strcpy(to_status_line, "\r"); It would be cleverer to add a boolean attribute for the status line which would be analogous to "am", rather than blithely shortchanging all status lines by one character. What would one name that attribute? And if you really wanted to play with the two-letter attribute names, you could add a secondary status line -- Wyse 50's can use a 46-column "host message area" at the top of the screen, as well as the 78-column region at the bottom. "Jeepers, feepers! / Where'd you get those features ...."