|
Home > Archive > Unix administration > January 2004 > termcap and DISPLAY weirdness
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
termcap and DISPLAY weirdness
|
|
| John Santore 2004-01-23, 4:54 pm |
|
I'm on an AIX box running 4.3.3, ML9
Recently upgraded from 4.3.2. I don't think
it's AIX specific, though.
We've encountered the following error and I
was wondering if anyone out there had any ideas.
Using a X emulator (Kea.X), we can log into the
machine and spawn an xterm. When we try to run
a particular application we get the following
problems:
1) TERM is set to vt220, however function keys
and other vt220 specific issues aren't working
2) The application is basically a green screen
type app, but it uses several solid line type
characters. Unfortunately, within the xterm
the border lines look like a's with umlauts and
miniature 3s, and the formatting is all munged up.
If, however, from within that xterm, I telnet back to the
machine, both the function keys and the application lines
look and work just fine. Unfortunately, I need to spawn
various xview type windows so a straight telnet isn't a
sufficient solution. I've tried setting DISPLAY and
xhosting and the like, but upon setting DISPLAY, even the
telnet session app no longer works (both screen draw and
function keys)
Additional piece. If I telnet to the machine using a
non X windows emulator (CRT), lines and function keys
work ok. If, however, I set DISPLAY to a machine
with the Xwindows emulator, my lines and function keys
cease to work.
Any ideas?
-John
| |
| Thomas Dickey 2004-01-23, 4:54 pm |
| John Santore <john@santore.com> wrote:
quote:
> I'm on an AIX box running 4.3.3, ML9
> Recently upgraded from 4.3.2. I don't think
> it's AIX specific, though.
it's probably not termcap, either (more likely terminfo)
quote:
> We've encountered the following error and I
> was wondering if anyone out there had any ideas.
quote:
> Using a X emulator (Kea.X), we can log into the
> machine and spawn an xterm. When we try to run
> a particular application we get the following
> problems:
> 1) TERM is set to vt220, however function keys
> and other vt220 specific issues aren't working
> 2) The application is basically a green screen
> type app, but it uses several solid line type
> characters. Unfortunately, within the xterm
> the border lines look like a's with umlauts and
> miniature 3s, and the formatting is all munged up.
quote:
> If, however, from within that xterm, I telnet back to the
> machine, both the function keys and the application lines
> look and work just fine. Unfortunately, I need to spawn
is $TERM set to vt220 there as well? (perhaps not).
quote:
> various xview type windows so a straight telnet isn't a
> sufficient solution. I've tried setting DISPLAY and
> xhosting and the like, but upon setting DISPLAY, even the
> telnet session app no longer works (both screen draw and
> function keys)
quote:
> Additional piece. If I telnet to the machine using a
> non X windows emulator (CRT), lines and function keys
> work ok. If, however, I set DISPLAY to a machine
> with the Xwindows emulator, my lines and function keys
> cease to work.
then it might be a font problem - but the comment about telnet'ing back
appears to be missing some detail.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
| |
| John Santore 2004-01-23, 4:54 pm |
| Thomas Dickey <dickey@saltmine.radix.net> wrote in
news:bp85c1$ma4$1@news1.radix.net:
quote:
> John Santore <john@santore.com> wrote:
>
>
> it's probably not termcap, either (more likely terminfo)
I looked into the terminfo stuff some, but basically
I think all I want out of vt220 is the function keys.
quote:
>
>
>
> is $TERM set to vt220 there as well? (perhaps not).
It is set to vt220 at all times. Both within the xterm,
as well as when I telnet.
quote:
>
>
> then it might be a font problem - but the comment about telnet'ing back
> appears to be missing some detail.
I don't believe it to be a font issue because:
1) when I telnet from within the xterm back to localhost, I'm
still within that xterm, and things are correctly drawn.
I'd assume that if it were a font issue, it'd be screwed up
both times.
2) the change seems solely related as to whether a DISPLAY
environment variable is set. (unfortunately, I need the
DISPLAY to spawn the xviews and what not)
To summarize, it appears that both the function key issue (term setting)
and the screen draws (font?) are affected by the display env variable.
-John
| |
| Bill Marcum 2004-01-23, 4:54 pm |
| On Sun, 16 Nov 2003 02:48:26 GMT, John Santore
<john@santore.com> wrote:quote:
>
> I'm on an AIX box running 4.3.3, ML9
> Recently upgraded from 4.3.2. I don't think
> it's AIX specific, though.
>
> We've encountered the following error and I
> was wondering if anyone out there had any ideas.
>
> Using a X emulator (Kea.X), we can log into the
> machine and spawn an xterm. When we try to run
> a particular application we get the following
> problems:
> 1) TERM is set to vt220, however function keys
> and other vt220 specific issues aren't working
> 2) The application is basically a green screen
> type app, but it uses several solid line type
> characters. Unfortunately, within the xterm
> the border lines look like a's with umlauts and
> miniature 3s, and the formatting is all munged up.
>
That could be a locale problem. What is the value of LANG?
--
You can go anywhere you want if you look serious and carry a clipboard.
| |
| Chuck Dillon 2004-01-23, 4:54 pm |
| John Santore wrote:quote:
>
> Additional piece. If I telnet to the machine using a
> non X windows emulator (CRT), lines and function keys
> work ok. If, however, I set DISPLAY to a machine
> with the Xwindows emulator, my lines and function keys
> cease to work.
>
> Any ideas?
It appears that the application is doing something different when it
thinks it is running in a X environment.
Does the opposite hold? If you log in via X, bring up an xterm, unset
DISPLAY and then run the application does it work properly?
-- ced
--
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.
| |
| Joe Durusau 2004-01-23, 4:54 pm |
| Chuck Dillon wrote:quote:
>
> John Santore wrote:
>
> It appears that the application is doing something different when it
> thinks it is running in a X environment.
>
> Does the opposite hold? If you log in via X, bring up an xterm, unset
> DISPLAY and then run the application does it work properly?
>
> -- ced
>
> --
> Chuck Dillon
> Senior Software Engineer
> NimbleGen Systems Inc.
It appears that the O.P. is trying to run software that "thinks" it
is operating a VT220, while it is really operating an Xterm. The
two are not compatible. It is possible that setting the TERM env.
variable to Xterm (or something similar, depending on the system),
might work. The bootom line is that VT220 line graphics are not
avialable
in an Xterm window, at least not on systems I have used.
Speaking only for myself,
Joe Durusau
| |
| Chuck Dillon 2004-01-23, 4:54 pm |
| Joe Durusau wrote:quote:
>
> It appears that the O.P. is trying to run software that "thinks" it
> is operating a VT220, while it is really operating an Xterm. The
> two are not compatible. It is possible that setting the TERM env.
> variable to Xterm (or something similar, depending on the system),
> might work. The bootom line is that VT220 line graphics are not
> avialable
> in an Xterm window, at least not on systems I have used.
The latest xterm supports VT220 according to the manpage on linux for
example. Given that Thomas Dickey, one of the authors of xterm and I
believe the current maintainer, responded in the thread and didn't
raise this issue seems to confirm that.
Not to mention that the OP indicates that the xterm does emulate the
VT220 when telnet is in the loop.
-- ced
quote:
>
> Speaking only for myself,
>
> Joe Durusau
--
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.
| |
| Thomas Dickey 2004-01-23, 4:54 pm |
| Joe Durusau <joe.durusau@lmco.com> wrote:
quote:
> It appears that the O.P. is trying to run software that "thinks" it
> is operating a VT220, while it is really operating an Xterm. The
> two are not compatible. It is possible that setting the TERM env.
> variable to Xterm (or something similar, depending on the system),
> might work. The bootom line is that VT220 line graphics are not
> avialable
> in an Xterm window, at least not on systems I have used.
vt220 line graphics are the same as vt100 line graphics (xterm in fact
does that - given a correct font). The comment about a's with umlauts
sounds more like OP is using a terminal description which is neither -
e.g., linux console.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
| |
| John Santore 2004-01-23, 4:54 pm |
| I thank everyone for their input on this.
What it wound up being, and I'm kind of frustrated by
this actually... is the application had some
behind the scenes TERM/DISPLAY checking.
If DISPLAY was not set, then it'd set it
correctly. If it was set, it didn't change
it to the correct value.
Since I didn't realize the env variables were
changing within the app, I couldn't track
down the problem.
Once again, thanks.
-John
| |
| Thomas Dickey 2004-01-23, 4:54 pm |
| Chuck Dillon <cdillon@nimblegen.com> wrote:quote:
> Joe Durusau wrote:
[QUOTE][color=darkred]
> The latest xterm supports VT220 according to the manpage on linux for
> example. Given that Thomas Dickey, one of the authors of xterm and I
> believe the current maintainer, responded in the thread and didn't
> raise this issue seems to confirm that.
he appears to be using AIX - hence I'd assume he's using X11R5 or X11R6
xterm. But the area that he's talking about should behave the same in
any of those flavors. It's possible that he's using aixterm rather than
xterm - I haven't used that recently enough to recall pitfalls in setting
up line-drawing.
quote:
> Not to mention that the OP indicates that the xterm does emulate the
> VT220 when telnet is in the loop.
....which leads me to suspect that he's not got $TERM set as he states.
vt100/vt220 line-drawing maps characters using this string:
acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvw
wxxyyzz{{||}}~~,
(it's pairs of characters - you see that they're identical since it's the
reference). In xterm's vt100 (or whatever) emulation, the glyphs shown
are from the font's 1-31 positions (normally nonprinting characters).
linux console (and a few related terminals) use this:
acsc=+^P\,^Q-^X. ^Y0\333`^Da\261f\370g\361h\260i\316j\331
k\277l\332m\300n\305o~p\304q\304r\304s_t
\303u\264v\301w\302x\263y\363z\362{\343|
\330}\234~\376,
The odd \333, etc., are codes in the range 160-255. If the font is something
like ISO-8859-1 (common), some of those will be the a's with umlauts, etc.
Since I'm familiar with fonts that show characters like this, and none that
have similar characters in positions 1-31, it seems that the application is
trying to use a mapping such as the latter - which isn't what a vt220 or vt100
would do.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
| |
| Ian Wilson 2004-01-23, 4:55 pm |
| Thomas Dickey wrote:
quote:
> Joe Durusau <joe.durusau@lmco.com> wrote:
>
>
>
>
> vt220 line graphics are the same as vt100 line graphics (xterm in fact
> does that - given a correct font). The comment about a's with umlauts
> sounds more like OP is using a terminal description which is neither -
> e.g., linux console.
>
Since vt100 line-draw graphics are limited to corners and lines, it may
be that the app is relying on IBM CodePage 437 characters to display
more complex line-drawings (tees, crosses, double-lines etc).
A-umlaut is at code-point 196 (0xC4) in ISO-8859-1. A horizontal line
glyph appears at that code-point in CodePage 437.
In which case, switching from ISO-8859-1 to CodePage 437 would be
appropriate.
|
|
|
|
|