[5099] in Athena Bugs
x11r4 (and r3, i think) xterm & $TERMCAP
daemon@ATHENA.MIT.EDU (Jonathan I. Kamens)
Wed Jun 6 21:13:01 1990
Date: Wed, 6 Jun 90 21:12:38 -0400
From: "Jonathan I. Kamens" <jik@pit-manager.MIT.EDU>
To: Raeburn@MIT.Edu
Cc: bugs@ATHENA.MIT.EDU
In-Reply-To: bugs[4940]
Date: Thu, 17 May 90 02:59:44 -0400
From: Ken Raeburn <Raeburn@MIT.Edu>
The process started by xterm appears to always have TERMCAP set in its
environment. Given that the kernel has the information also, and most
programs for which this matters do check the terminal driver, this
seems superfluous. Considering the limit of environment size for `ps'
to be able to display arguments, and that some of us use the AFS
pathnames for some directories, it's downright annoying. It should at
least be optional.
I'm afraid you're going to have to explain this a bit more clearly,
because I can't duplicate it as you've describe it.
I wrote a program (call it "ptermcap") to do nothing but print the
TERMCAP environment variable or "TERMCAP is unset." if it isn't unset,
and then sleep for 5 seconds. I then did this:
unsetenv TERMCAP
xterm -e ptermcap
and what I got was "TERMCAP is unset."
Either you're complaining that xterm passes on an already set
TERMCAP to the processes it creates, or you're complaining that
/bin/csh processes started up by an xterm that doesn't have TERMCAP
set termcap themselves.
If the former, then I would submit that there's no bug; xterm
shouldn't be mucking with the environment it gets handed. If the
latter, then you're talking about a csh bug, not an xterm bug, and you
should clarify your bug report to point this out.
Also, I don't understand what you mean when you say "that the kernel
has this infomration also." As far as I know, the kernel doesn't
store TERMCAP entries. Am I wrong?
jik
