From owner-freebsd-hackers Tue Sep 12 16:08:47 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA10192 for hackers-outgoing; Tue, 12 Sep 1995 16:08:47 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA10045 for ; Tue, 12 Sep 1995 16:08:36 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA03742; Tue, 12 Sep 1995 16:07:16 -0700 From: Terry Lambert Message-Id: <199509122307.QAA03742@phaeton.artisoft.com> Subject: Re: xterm and status-line To: mbarkah@hemi.com (Ade Barkah) Date: Tue, 12 Sep 1995 16:07:15 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <199509122223.QAA11426@hemi.com> from "Ade Barkah" at Sep 12, 95 04:23:49 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2724 Sender: hackers-owner@FreeBSD.ORG Precedence: bulk > I'm running FreeBSD 2.0.5 and xfree86. The included xterm > advertises that it has a status-line, but I haven't been > able to figure it out (enable it or write to it.) > > I've tried the following code (fragment) so I can write > to the status line: > > if (tgetflag ("hs")) { > pEnterSL=tgetstr ("ts", &_capptr); > tputs (pEnterSL, 1, outfn); > ... > > I get garbage in the current cursor position. Currently I have > a function which simply emulates a status line but I'd like > to get the hardware stuff to work. Typically, a status line on an ANSI escape sequence terminal is implemented using a scrolling region. This works on VMS because escape sequences are always written atomically. The Status line is updated by an escape sequence to get to the line, a data dump, and an escapesequence to end the dump. This is the same problem as transparent print, where an escape sequence, print data, and another escape sequence must occur atomically. The problem you will find in the UNIX case is that since not everyone uses atomically correct escape sequences from TERMCAP, you may in fact interrupt your application with your data, or interrupt your data with your application as writes are interleaved. Basically, all escape sequences must be transmitted in their entirety with the terminal (or emulator) in the ground state for the transmission to be successful. Several multiport board manufacturer's include transparent print devices as part of their board drivers. These operate by having an escape sequence automaton in the driver for the terminal type attached to the device; the atomicity of state 0 initiated sequence seta from one device or another are arbitrated in the kernel to ensure ground state for the mode switch. This is also ho DECServer's implement multisession on VT330/340's. This type of thing is also why VMS shells do not echo queued characters while an application is running. To ensure proper behaviour, you would have to guarantee the atomicity of the escape sequences in the tput() code in the termcap, and you would have to guarantee that everyone abided by this rule by using the library instead of doing their own I/O. That means no more apps that do 'puts("\033[2J");" to clear the screen, etc. (use of standard I/O could break the writes up such that an interleaved I/O from another application was not atomic). If you could guarantee atomicity like this (VMS does it by expressly supporting a subset of all terminal types), then it's a short way to transparent printing, status lines, and VMS style "broadcast" alerts. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.