TERM env.var. in Unix: Why can't I modify it ?

[Leo de Wit]

In article <1990Jul3.094811.4684 at diku.dk> nomann at rimfaxe.diku.dk (Ole Nomann Thomsen) writes:
|Recently I posted this question in comp.unix.questions, but got only one
|answer. (This was to "look in /etc/TIMEZONE", which was useful, although 
|not sufficient. Thanks to the answerer, sorry I mislaid you name).
|
|Now, I have collected some more data on the problem, which enables me to
|describe it more thoroughly (I hope :-).
|
|The system is unix rel. 3.2 vers. 2.1 machine: i386, and I use a csh.
|
|The problem is this:
|
|When I log in from a network-terminal, I get an env. variable, TERM,
|that is set to unknown. I cannot change this value to something sensible
|since "setenv" doesn't overwrite the existing TERM, but rather creates a
|new one, so that I now have two "TERM" env.var.s (and all the applications
|can only see the wrong one, surprise surprise).

I think I know the reason of your problem, and I've got a solution too.
I created a program that adds an extra TERM variable to the environment
(through execve()). It has the same peculiarities you mention, that is:
env only shows the last one, but printenv (BSD) prints both. The AT&T
universe on this Pyramid uses the last one, the UCB universe the first.

|
|The problem stems from the program /bin/netlogin. I know this, because I
|patched this binary to set an env.var. call "LERM" instead of "TERM". This
|results in that I have an immortal env.var.: LERM=unknown, which I can live
|with, although it still bothers me (not a pain but an itch).
|
|My questions are:
|
|1. Why (and how) does /bin/netlogin set an immortal env.var., and is it
|   harmful to remove it like I did. ?

/bin/netlogin just added an extra TERM variable to your environment,
without removing the original one. Subsequent setenvs will set the
first entry, not the second; env will use the last entry found, and
getenv() behaves differently in System V and BSD (the former using the
last, the latter using the first entry if I may believe some simple
tests).

An easy fix without resorting to binary patching is to just unsetenv
TERM, then setenv TERM. This will first reduce the number of TERM
variable entries to one, and then set that one entry.

|
|2. Why can't csh overwrite the TERM=unknown env., (with setenv) when Bourne-
|   shell can (with export) ?
|

Csh does nothing special to the environment, while a Bourne shell first
cleans up its environment (printing out its environment shows it is
sorted and uniqued).  The reason for this probably lays in the fact
that shell variables and environment variables are treated differently
in both shells (there is no such thing as export in the csh, which puts
a shell variable in the environment).

    Leo.