[5608] in Athena Bugs
Re: 7.0: /usr/athena/lib/init/login: DEF_TERM
daemon@ATHENA.MIT.EDU (raeburn@MIT.EDU)
Wed Jul 25 16:55:51 1990
From: raeburn@MIT.EDU
To: "Jonathan I. Kamens" <jik@PIT-MANAGER.MIT.EDU>
Cc: bugs@ATHENA.MIT.EDU
In-Reply-To: Your message of Wed, 25 Jul 90 10:47:53 -0400.
Date: Wed, 25 Jul 90 16:55:24 EDT
>> From: "Jonathan I. Kamens" <jik@PIT-MANAGER.MIT.EDU>
>> It is not silly, because we do not guarantee that the implementation
>> of the standard login files will always use DEF_TERM in the same shell
>> in which it was created. Since it is possible that in the future we
>> will want to change the implementation in a way that will require
>> DEF_TERM to be defined in a subshell, it must be an environment
>> variable, or we'll have to tell users to change their config files
>> based on changes they shouldn't even have to know about.
The only case I see where simple argument-passing wouldn't work is if
you have some other program invoke yet another shell script. This is
certainly reasonable in some cases, but for dealing with setting the
terminal type it seems unlikely.
And it's already required that several parts of the startup sequence
do happen in the same shell (assuming that we ignore the possibility
of using argument lists), such as checking for skip_* shell variables.
>> A side note: This was a conscious design decision in the original
>> design of the standard login files. If you want it changed, you're
>> going to have to go through the same design process, and convince all
>> the people that thought it was right that it's now wrong. If you
>> really want to do this, mail to athena-ws expressing your opinion on
>> this is usually a good way to start.
Hmph. I've tried that route before, for different problems.
What is the step after that?
>> Another side-note: If you're concerned about environment clutter, than
>> do what I do -- create a file called ~/.unsets in your home directory,
>> and source it first in your .startup.X and .startup.tty files (or in
>> your .cshrc.mine file, if you want to be really drastic), and have it
>> unset the variables that you only want to be set during login.
I would put it in my .startup.all, but the .unsets solution would be
useless from .startup.X (though DEF_TERM in particular isn't a
problem), because it's in a subshell. Besides, the window manager,
which is how many people start up other programs, is started before
.startup.X is run.
Why couldn't the appropriate "unsetenv" commands be run as part of the
standard login startup? It seems to be that $DEF_TERM is all but
useless after it's finished.
