== The latest _xterm_ versions mangle _$SHELL_ in annoying ways

As of [[patch #301
http://invisible-island.net/xterm/xterm.log.html#xterm_301]] (and
with changes since then), the canonical version of _xterm_ has some
unfortunate behavior changes surrounding the _$SHELL_ environment
variable and how _xterm_ interacts with it.  The full details are
in [[the _xterm_ manpage
http://invisible-island.net/xterm/manpage/xterm.html#h2-OPTIONS]]
in the _OPTIONS_ section, but the summary is that _xterm_ now clears
or changes _$SHELL_ if the _$SHELL_ value is not in _/etc/shells_,
and sometimes even if it is. As far as I can tell, the decision
tree goes like this:

# if _xterm_ is (explicitly) running something that is in _/etc/shells_
  (as '_xterm /some/thing_', not '_xterm -e /some/thing_'), _$SHELL_ will
  be rewritten to that thing.

# if _xterm_ is running anything (including running _$SHELL_ itself via
  being invoked as just '_xterm_') and _$SHELL_ is not in _/etc/shells_
  but your login shell is, _$SHELL_ will be reset to your login shell.

# otherwise _$SHELL_ will be removed from the environment, resulting
  in a shell environment with _$SHELL_ unset. This happens even if
  you run plain '_xterm_' and so _xterm_ is running _$SHELL_.

It is difficult for me to summarize concisely how wrong this is and
how many ways it can cause problems. For a start, this is a misuse
of _/etc/shells_, per [[my entry on what it is and isn't EtcShellsUsage]];
_/etc/shells_ is in no way a complete list of all of the shells (or
all of the good shells) that are in use on the system. You cannot
validate the contents of _$SHELL_ against _/etc/shells_ because
that is not what _/etc/shells_ is there for.

This _xterm_ change causes significant problems for anyone with
their shell set to something that is not in _/etc/shells_, anyone
using [[an alternate personal shell UsingAlternateShell]] (which
is not in _/etc/shells_ for obvious reasons), any program that
assumes _$SHELL_ is always set (historically a safe assumption),
and any environment that assumes _$SHELL_ is not reset when set to
something non-standard such as a captive or special purpose 'shell'.

(Not all versions of _chsh_ restrict you to what's in _/etc/shells_,
for that matter; some will let you set other things if you really
ask them to.)

If you fall into one or more of these categories and you use _xterm_,
you're going to need to change your environment at some point.
Unfortunately it seems unlikely that this change will be reverted, so
if your version of Unix updates _xterm_ at all you're going to have it
sooner or later (so far only a few Linux distributions are recent enough
to have it).

PS: Perhaps this should be my cue to switch to _urxvt_. However my
almost-default configuration of it is still just enough different
from _xterm_ to be irritating for me, although maybe I could fix
that with enough customization work.  For example, I really want
its double-click selection behavior to exactly match _xterm_ because
that's what my reflexes expect and demand by now. [[See also
XTermWants]].

PPS: Yes, I do get quite irritated at abrupt incompatible changes
in the behavior of long-standing Unix programs, [[at least when they
affect me https://twitter.com/thatcks/status/555124907630002177]].