gpvos@cs.vu.nl (Vos G P) (02/23/90)
A short question: How do i get characters >127 in the termcap strings?
--
------------------------------------------------------------------------------
Gerben Vos | Aconet: {BBCBBS,BIGBEN}!Gerben Vos
| UUCP: gpvos@cs.vu.nl
These are not opinions; these are facts | mcsun!botter!gpvosmartin@mwtech.UUCP (Martin Weitzel) (02/24/90)
In article <5658@star.cs.vu.nl> gpvos@cs.vu.nl (Vos G P) writes: >A short question: How do i get characters >127 in the termcap strings? You may be able to get them 'in' using octal escape sequences, but many applications don't get them 'out' to the terminal device, because it's a common technique to strip the 8th bit on output. Why? Because older hardware didn't make use of the 8th bit (or used it as parity), there developed the convention to write '\200' in the termcap string whenever a '\0' Byte had to appear in the output. -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
gwyn@smoke.BRL.MIL (Doug Gwyn) (02/25/90)
In article <5658@star.cs.vu.nl> gpvos@cs.vu.nl (Vos G P) writes: >A short question: How do i get characters >127 in the termcap strings? Encode them as octal escapes, e.g. \377. However, it is quite probable that the high bit will get cleared somewhere along the way before it reaches the terminal. There are several opportunities for this to occur...
gpvos@cs.vu.nl (Vos G P) (03/01/90)
I wrote: >A short question: How do i get characters >127 in the termcap strings? martin@mwtech.UUCP (Martin Weitzel) writes: >You may be able to get them 'in' using octal escape sequences, >but many applications don't get them 'out' to the terminal device, >because it's a common technique to strip the 8th bit on output. I knew most of this already from the man pages, but thought there would be a workaround for it. However, i have made a few tests, and discovered that on our system _no_ bits are stripped, so the workaround is not necessary. This introduces another problem, though. Now i can't get a \0 in my strings! Can someone help me with that? As no high bits are stripped, \200 gives me a neat \200, instead of the \0 the man pages say. -- ------------------------------------------------------------------------------ Gerben Vos | Aconet: {BBCBBS,BIGBEN}!Gerben Vos | UUCP: gpvos@cs.vu.nl These are not opinions; these are facts | mcsun!botter!gpvos
martin@mwtech.UUCP (Martin Weitzel) (03/01/90)
In article <5708@star.cs.vu.nl> gpvos@cs.vu.nl (Vos G P) writes: [first part deleted] > >This introduces another problem, though. Now i can't get a \0 in my strings! >Can someone help me with that? As no high bits are stripped, \200 gives me >a neat \200, instead of the \0 the man pages say. If your application does *not* strip the high order bit from the termcap strings on output, IMHO(%) there's only one chance to output a \0-Byte, and that chance depends on your system: Modern TTY-Drivers often support "output translate tables" which let the driver translate any character to any other character (or sometimes even to a string) immediatly, before this character is sent to the port. So, use one character you don't ever need and translate it to \0 in the output translate tables. (%): There is a small design flaw in termcap: The strings you read with "tgetstr" are stored \0-terminated, as usual in C and you only have the adress of the first character, so you can not distinguish an 'embedded' \0 from the terminating \0. Of course, if you are willing to write (parts of) the termcap library functions new, you may correct this by adding a length-count ... Another question is, why do you *need* \0-Bytes on output? I don't know of any hardware, which requires them for a particular function other than 'padding' and - sometimes - cursor positioning to the left/top column/row. Padding - if required - is done by some other mechanism in termcap and "tgoto" avoids outputing a \0-Byte by positioning to column/row 1 and back-/upspace. -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
gwyn@smoke.BRL.MIL (Doug Gwyn) (03/02/90)
In article <5708@star.cs.vu.nl> gpvos@cs.vu.nl (Vos G P) writes: >This introduces another problem, though. Now i can't get a \0 in my strings! >Can someone help me with that? As no high bits are stripped, \200 gives me >a neat \200, instead of the \0 the man pages say. I hope \200 will serve your terminal's needs, because you cannot embed a constant \000 in termcap strings; they're handled by programs as C null-terminated strings and thus cannot contain a 0-valued byte. A 0 byte can be output via termcap/libtermlib only as the result of parameter substitution (or, of course, as a padding character). I'm curious as to the kind of terminal you have that requires a 0 byte for some non-padding function. I've never encountered this myself..
gpvos@cs.vu.nl (Vos G P) (03/02/90)
gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >I hope \200 will serve your terminal's needs, because you cannot embed >a constant \000 in termcap strings; they're handled by programs as C I was afraid of this, but it's not a very important terminal function anyway for which i need it. Still, it seems a limitation to me. >I'm curious as to the kind of terminal you have that requires a 0 byte >for some non-padding function. I've never encountered this myself.. Ah, it's my home computer, an Acorn Electron - i use it sometimes with a modem to connect to the university, and just for fun i'm trying to write a termcap entry for it. It's VDU functions are driven by ASCII codes 1..31, and the parameters for some of them may become zero or above 127; e.g. the sequence <17> <0> (decimal) means "foreground colour 0", or black, and <17> <135> means "white background". I needed this for the reverse video function, or "standout mode" (so). -- ------------------------------------------------------------------------------ Gerben Vos | Aconet: {BBCBBS,BIGBEN}!Gerben Vos | UUCP: gpvos@cs.vu.nl These are not opinions; these are facts | mcsun!botter!gpvos
meissner@osf.org (Michael Meissner) (03/02/90)
In article <12264@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: | I'm curious as to the kind of terminal you have that requires a 0 byte | for some non-padding function. I've never encountered this myself.. DG terminals in DG mode (as opposed to ANSI mode) cursor positioning code is a \020 followed by the row and column in absolute binary. If you wanted to go directly to the upper left hand corner of the screen, the terminal would want: \020\000\000 Most of the earlier terminals did mask out the 8th bit, so \200 would work. Some of the newer terminals, when you enable 8-bit mode, don't strip the 8th bit in reading binary. Fortunately, any terminal with 8-bit mode also has ANSI support (which works better under UNIX anyway, since in DG mode, the terminal wants ^Y to backspace, and not ^H). -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA Catproof is an oxymoron, Childproof is nearly so
peter@ficc.uu.net (Peter da Silva) (03/03/90)
In article <12264@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: > I'm curious as to the kind of terminal you have that requires a 0 byte > for some non-padding function. I've never encountered this myself.. The Televideo line of terminals (notable for the magic cookie glitch) use a 3-byte sequence for programming the cursor keys. Null bytes in this sequence are not transmitted, and so can be used to terminate it much as they do in C. A pity the usages conflict. -- _--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'
gwyn@smoke.BRL.MIL (Doug Gwyn) (03/03/90)
In article <MEISSNER.90Mar2105523@curley.osf.org> meissner@osf.org (Michael Meissner) writes: -In article <12264@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: -| I'm curious as to the kind of terminal you have that requires a 0 byte -| for some non-padding function. I've never encountered this myself.. -DG terminals in DG mode (as opposed to ANSI mode) cursor positioning -code is a \020 followed by the row and column in absolute binary. If -you wanted to go directly to the upper left hand corner of the screen, -the terminal would want: - \020\000\000 That shouldn't cause problems in termcap, though, because this is one of the supported tgoto() parameter modes. One does have to omit an explicit "ho" capability if that's the only way to achieve it, but any termcap-using software ought to be smart enough to use "cm" to accomplish an "ho" effect when the former is given but not the latter.
russ@bbx.UUCP (Russ Kepler) (03/09/90)
In article <680@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: > >(%): There is a small design flaw in termcap: The strings you >read with "tgetstr" are stored \0-terminated, as usual in C >and you only have the adress of the first character, so you can >not distinguish an 'embedded' \0 from the terminating \0. Of >course, if you are willing to write (parts of) the termcap library >functions new, you may correct this by adding a length-count ... Ignoring the output side (tputs) you actually can (and will) get nulls from tgetstr. The strings tgetstr returns are null terminated *but* you did provide a char ** for tgetstr's use. The difference of the ending value and the starting value will provide the null containing strings' length. I had to use this for a terminal that send nulls in the function key strings. -- Russ Kepler - Basis International SNAILMAIL: 5901 Jefferson NE, Albuquerque, NM 87109 UUCP: {backboneishsite}!unmvax!bbx!russ PHONE: 505-345-5232
DHH102@psuvm.psu.edu (03/19/91)
Does anybody have a termcap for a dm5 dm5a or dm5b terminal??
(We have some ancient Harris 8685 and 8686's that suggest that they
that is what they need)
thanks
____ Bitnet: dhh102@psuvm doug@psueclc
( / ) _ _, Inet: dhh102@psuvm.psu.edu doug@ecl.psu.edu
\_/__/ <_>_/_/_<_> "Time flies like an arrow."
<_> "Fruit flies like a banana."