hyc@hanauma.jpl.nasa.gov (Howard Chu) (03/15/91)
Here's a couple small additions to Oliver Lauermann's program screen 2.0,
the ANSI terminal multiplexer... I just noticed that this is now a GNU
copylefted program, but don't know who's currently maintaining it. These
diffs should apply to the 2.1 source without any trouble.
Two simple changes - make the program get and set the kernel's notion of
the screen size, if the ioctl's are present. Also respond to the "report
cursor position" query.
It's not as flexible to use now that SunOS has gone to terminfo for their
curses implementation. Mebbe someone can add code to compile terminfo
definitions on the fly, the way this constructs termcap entries?
-- Howard
RCS file: RCS/screen.c,v
retrieving revision 1.1
diff -c -r1.1 screen.c
*** /tmp/,RCSt1018792 Thu Mar 14 14:33:32 1991
--- screen.c Thu Nov 1 22:51:07 1990
***************
*** 8,14 ****
* not modified.
*/
! static char ScreenVersion[] = "screen 2.0a 19-Oct-88";
#include <stdio.h>
#include <sgtty.h>
--- 8,14 ----
* not modified.
*/
! static char ScreenVersion[] = "screen 2.0hyc 1-Nov-90";
#include <stdio.h>
#include <sgtty.h>
***************
*** 809,814 ****
--- 809,822 ----
ioctl (0, TIOCSPGRP, &mypid);
(void) setpgrp (0, mypid);
SetTTY (0, &OldMode);
+ #ifdef TIOCSWINSZ
+ {
+ struct winsize wbuf;
+ wbuf.ws_row = rows;
+ wbuf.ws_col = cols;
+ ioctl (0, TIOCSWINSZ, &wbuf);
+ }
+ #endif
NewEnv[2] = MakeTermcap (aflag);
sprintf (ebuf, "WINDOW=%d", n);
NewEnv[3] = ebuf;
===================================================================
RCS file: RCS/ansi.c,v
retrieving revision 1.1
diff -c -r1.1 ansi.c
*** /tmp/,RCSt1018792 Thu Mar 14 14:37:04 1991
--- ansi.c Thu Nov 1 22:45:56 1990
***************
*** 8,16 ****
* not modified.
*/
! char AnsiVersion[] = "ansi 2.0a 19-Oct-88";
#include <stdio.h>
#include <sys/types.h>
#include "screen.h"
--- 8,17 ----
* not modified.
*/
! char AnsiVersion[] = "ansi 2.0hyc 1-Nov-90";
#include <stdio.h>
+ #include <sgtty.h> /* See if TIOCGWINSZ is supported */
#include <sys/types.h>
#include "screen.h"
***************
*** 94,101 ****
--- 95,112 ----
Msg (0, "No TERM in environment.");
if (tgetent (tbuf, s) != 1)
Msg (0, "Cannot find termcap entry for %s.", s);
+ #ifdef TIOCGWINSZ
+ {
+ struct winsize wbuf;
+
+ ioctl(0, TIOCGWINSZ, &wbuf);
+ rows=wbuf.ws_row;
+ cols=wbuf.ws_col;
+ }
+ #else
cols = tgetnum ("co");
rows = tgetnum ("li");
+ #endif /* TIOCGWINSZ */
if (cols <= 0)
cols = 80;
if (rows <= 0)
***************
*** 778,783 ****
--- 789,801 ----
if (PO && curr->GotArg[0] && a1 == 5) {
curr->stringp = curr->string;
curr->state = PRIN;
+ }
+ break;
+ case 'n': /* Report cursor position? */
+ if (curr->GotArg[0] && a1 == 6) {
+ char sbuf[16];
+ sprintf(sbuf,"[%d;%dR\n",curr->y+1,curr->x+1);
+ write(curr->ptyfd,sbuf,strlen(sbuf));
}
break;
}
--
-- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA
Disclaimer: How would I know, I just got here!woods@eci386.uucp (Greg A. Woods) (03/20/91)
In article <1991Mar14.203404.21113@jato.jpl.nasa.gov> hyc@hanauma.jpl.nasa.gov (Howard Chu) writes: > It's not as flexible to use now that SunOS has gone to terminfo for their > curses implementation. Mebbe someone can add code to compile terminfo > definitions on the fly, the way this constructs termcap entries? I don't mean to flame Oliver (or Howard), but I suspect someone has mis-interpreted how curses and/or terminfo/termcap should be used. Why do you say screen is less flexible when using terminfo? Why change the terminal definition on the fly? If all it's changing are the lines/cols, why not set up environment variables (LINES/COLUMNS are recognized by most sane termcap/termlib implementations) (in addition to setting the lines/cols in the driver)? The layers terminal I'm on works fine with different sized windows. There's magic in termlib that knows about the JWIN ioctl(), and termlib also knows about LINES/COLUMNS. The only problem is that SYSV doesn't have a SIGWINCHG and terminfo curses can't change the window size on the fly (without doing an endwin();initscr() sequence). Actually, what I'd really like is for wrefresh() to notice the changed size (i.e. do a JWIN or TCIOGWINSZ(?)) and automatically "do the right thing". -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA Political speech and writing are largely the defense of the indefensible-ORWELL
net@opal.cs.tu-berlin.de (Oliver Laumann) (03/21/91)
In article <1991Mar19.164204.21361@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes: > Why do you say screen is less flexible when using terminfo? Why > change the terminal definition on the fly? Because the capabilities of the virtual terminal that is emulated by screen depend on the capabilities of the physical terminal on which screen has been started. Example: screen cannot emulate the "blinking" attribute if the physical terminal doesn't support this capability. Thus, screen has to dynamically create a TERMCAP environment variable on startup. It doesn't change anything "on the fly". screen tries hard to fully emulate a virtual VT220/X3.64 terminal, but, of course, it is unable to support certain capabilities if your "real" terminal is sufficiently dumb. -- Oliver Laumann net@tub.cs.tu-berlin.de net@tub.UUCP net@gnu.ai.mit.edu
clipper@det.csd.uwo.ca (Khun Yee Fung) (03/22/91)
>>>>> On 21 Mar 91 12:38:24 GMT, net@opal.cs.tu-berlin.de (Oliver >>>>> Laumann) said: Oliver> In article <1991Mar19.164204.21361@eci386.uucp> Oliver> woods@eci386.UUCP (Greg A. Woods) writes: > Why do you say screen is less flexible when using terminfo? Why > change the terminal definition on the fly? Oliver> Because the capabilities of the virtual terminal that is Oliver> emulated by screen depend on the capabilities of the physical Oliver> terminal on which screen has been started. Is it possible to do the following: I usually use screen on a VT100 clone. One day of a week I will use a vc404. On that day, since I never exit from screen, I have to restart up screen, with all the VT100 escape sequences on the screen, terminate it, and then start a new screen. Is there a way to tell screen on the fly that the physical terminal has changed? Khun Yee -- ---- Name: Khun Yee Fung Email: clipper@csd.uwo.ca Paper Mail: Department of Computer Science Middlesex College The University of Western Ontario London, Ontario, N6A 5B7 CANADA
net@opal.cs.tu-berlin.de (Oliver Laumann) (03/22/91)
In article <CLIPPER.91Mar21181432@det.csd.uwo.ca> clipper@det.csd.uwo.ca (Khun Yee Fung) writes: > Is there a way to tell screen on the fly that the physical terminal > has changed? No. This wouldn't work in general. Suppose you start screen on a terminal that supports the "blinking" attribute. In this case screen puts a capability for "blinking" into the TERMCAP environment variable of the programs running under control of screen. Now suppose you detach your screen session and resume it on a later point in time on a terminal that doesn't have this capability. What should happen when an application running under screen outputs ^[[5m to set the blinking attribute? The application still thinks this capability is supported, and there is, of course, no way for screen to change the value of $TERMCAP for a child process on the fly. -- Oliver Laumann net@tub.cs.tu-berlin.de net@tub.UUCP net@gnu.ai.mit.edu
clipper@det.csd.uwo.ca (Khun Yee Fung) (03/22/91)
>>>>> On 22 Mar 91 09:55:58 GMT, net@opal.cs.tu-berlin.de (Oliver >>>>> Laumann) said: Oliver> Suppose you start screen on a terminal that supports the Oliver> "blinking" attribute. In this case screen puts a capability Oliver> for "blinking" into the TERMCAP environment variable of the Oliver> programs running under control of screen. Oliver> Now suppose you detach your screen session and resume it on a later Oliver> point in time on a terminal that doesn't have this capability. Yes, I understand that. I wasn't thinking about a general solution. In fact, what I was thinking is a sort of approximation solution. That is, if the new terminal has fewer features than the old one, too bad, the features that it don't have will get mapped to other things. There will be problems, I know. But, for me, this is safer than to terminate a screen session without really knowing what I was running the last time I detached it. In any case, thank you very much for the program. It is the first program I run after logging in every day. It would be much harder for me to work at home if not for your program. Khun Yee -- ---- Name: Khun Yee Fung Email: clipper@csd.uwo.ca Paper Mail: Department of Computer Science Middlesex College The University of Western Ontario London, Ontario, N6A 5B7 CANADA
woods@eci386.uucp (Greg A. Woods) (03/25/91)
In article <2921@kraftbus.cs.tu-berlin.de> net@opal.cs.tu-berlin.de (Oliver Laumann) writes: > In article <1991Mar19.164204.21361@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes: > > Why do you say screen is less flexible when using terminfo? Why > > change the terminal definition on the fly? > > Because the capabilities of the virtual terminal that is emulated by > screen depend on the capabilities of the physical terminal on which > screen has been started. Example: screen cannot emulate the "blinking" > attribute if the physical terminal doesn't support this capability. Ah, now I see the dilema. I had assumed that screen wasn't actually trying to emulate some virtual terminal, but rather just providing windowing, and allowing curses to use the existing terminal definition. I can see the advantages of doing this, but it does seem to be overly complex, especially given that screen isn't (so far as I know) advertised as providing more intelligent virtual terminal emulation for really dumb terminals. On the other hand, for terminfo, instead of being able to dynamically define the terminal capabilities, why not logically break down the various categories of support such that a set of extended terminfo's can be built around a default minimum terminfo description. (Eg.: if "scrn" is the default, "scrn-noblink" could be the terminal type used when the physical terminal doesn't support blinking.) Of course the dynamic construction of the terminfo description will still work, but it requires writing the description out to a temporary file, then running 'tic' (with the environment variable TERMINFO set to some writable directory). -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA Political speech and writing are largely the defense of the indefensible-ORWELL
net@opal.cs.tu-berlin.de (Oliver Laumann) (03/25/91)
woods@eci386.UUCP (Greg A. Woods) writes: > Ah, now I see the dilema. I had assumed that screen wasn't actually > trying to emulate some virtual terminal, but rather just providing > windowing, and allowing curses to use the existing terminal definition. > > I can see the advantages of doing this, The main advantage of not making use of curses is that the application works. When I started development of screen I decided to not use curses because of its bugs. In the meantime I'm not sure if it had been possible at all to provide screen's entire functionality by means of (BSD-) curses (such as support for the ISO2022 multiple character set functions in each window). -- Oliver Laumann net@tub.cs.tu-berlin.de net@tub.UUCP net@gnu.ai.mit.edu
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (03/25/91)
In article <1991Mar24.200524.13960@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes: > I can see the advantages of doing this, but it does seem to be overly > complex, especially given that screen isn't (so far as I know) > advertised as providing more intelligent virtual terminal emulation > for really dumb terminals. Well, it doesn't work on *really* dumb terminals, but it does an excellent job of turning anything else into a VT compatible. > On the other hand, for terminfo, instead of being able to dynamically > define the terminal capabilities, why not logically break down the > various categories of support such that a set of extended terminfo's > can be built around a default minimum terminfo description. (Eg.: if > "scrn" is the default, "scrn-noblink" could be the terminal type used > when the physical terminal doesn't support blinking.) I've been working with a few other people on something like this. We reduced terminal features pretty quickly to ten basic categories, with three levels of support in each category. It doesn't seem to get any simpler than that: whenever we try to combine two categories or eliminate a level of support, we find some terminal that can handle one of the original categories but not the other. So I don't think your idea would work: terminfo's centralized setup simply cannot handle ten independent options as well as termcap's decentralized configuration. ---Dan
hyc@hanauma.jpl.nasa.gov (Howard Chu) (03/26/91)
Well, I think the original response discussion has settled... Is it just me, or has anyone else noticed problems with auto-wrap terminals and SunOS4.1x curses? Specifically, vi tends to emit an extra linefeed when drawing 80+ column lines, making the actual screen appearance different from what vi thinks is onscreen. When you cursor up and down it also tends to forget where line 1 is, and you can't move the cursor all the way to the physical line 1. This seems to happen regardless of whether I use screen or their built-in terminfo descriptions on a raw terminal. (vt220, vt320, all happens the same.) Damned annoying, and toggling auto-wrap on the terminal itself doesn't seem to help. -- -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA Disclaimer: How would I know, I just got here!
peter@ficc.ferranti.com (Peter da Silva) (03/27/91)
In article <1991Mar25.220138.5308@jato.jpl.nasa.gov> hyc@hanauma.jpl.nasa.gov (Howard Chu) writes: > Well, I think the original response discussion has settled... Is it just me, > or has anyone else noticed problems with auto-wrap terminals and SunOS4.1x > curses? Specifically, vi tends to emit an extra linefeed when drawing 80+ > column lines, making the actual screen appearance different from what vi > thinks is onscreen. When you cursor up and down it also tends to forget > where line 1 is, and you can't move the cursor all the way to the physical > line 1. The DEC vt100 has a very strange set of line-wrap behaviours, and attempts to properly emulate them or deal with them are a frequent cause of problems. I think you should set the terminal to "no wrap" and let screen handle the wrapping itself. Basically, if you have any options available as to what terminal to use or emulate, DON'T make it a DEC (or a Televideo/adm type, either). Emulate something based on ANSI X3.64, (with the ISO Latin-1 character set, if possible). -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (03/27/91)
As quoted from <CLIPPER.91Mar21181432@det.csd.uwo.ca> by clipper@det.csd.uwo.ca (Khun Yee Fung): +--------------- | Is it possible to do the following: I usually use screen on a VT100 | clone. One day of a week I will use a vc404. On that day, since I | never exit from screen, I have to restart up screen, with all the | VT100 escape sequences on the screen, terminate it, and then start a | new screen. Is there a way to tell screen on the fly that the physical | terminal has changed? +--------------- Well, under that oh-so-evil terminfo/curses, you can do this by doing a scrdump() to save the screen/window images to a file, endwin(), change $TERM, initscr(), and scrload(). I think it may be possible to do this without the save/restore as well (manuals are at work, I'm at home...). (SVR3.2 or later required, certainly SunOS4's terminfo/curses should do it). I can't see why the terminfo needs to be changed on the fly, anyway. So the terminal can't blink --- terminfo/curses will either simulate it with another attribute or ignore it. Use the standard terminfo entry. This is what I'm doing in a screen-oid program I'm writing for SCO UNIX. (Attribute-space terminals can be handled by some extra code to test for magic_cookie_glitch and not do attributes in that case; or, preferably, by replacing the terminal in question with something sane.) ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR/AA on 2m, 220, 440, 1200 Internet: allbery@NCoast.ORG (QRT on HF until local problems fixed) America OnLine: KB8JRR // Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH
net@opal.cs.tu-berlin.de (Oliver Laumann) (03/27/91)
In article <1991Mar27.004154.25200@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR/AA) writes: > I can't see why the terminfo needs to be changed on the fly, anyway. So the > terminal can't blink --- terminfo/curses will either simulate it with another > attribute or ignore it. "screen" doesn't change termcap or terminfo entries "on the fly"; I already said that in an earlier article. And it doesn't use "curses"; why don't you first read the entire article thread before posting a reply? By the way, I think it is better to give applications running under control of screen (or a similar program) a chance to decide for themselves how they handle certain unsupported capabilities (i.e. whether to ignore or simulate them) than to do that automatically in an intermediate layer.
net@opal.cs.tu-berlin.de (Oliver Laumann) (03/27/91)
In article <_X9A+8E@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > Emulate something based on ANSI X3.64 (with the ISO Latin-1 character set, if > possible). This is what screen does. It emulates the X3.64 terminals plus the ISO 2022 character set functions and some VT100-specific functions.