[lmi] When chsh doesn't work [Was: RHEL userid puzzlement]

[Greg Chicares]

On 2019-09-17 23:31, Greg Chicares wrote:
> On 2019-09-11 13:03, Vadim Zeitlin wrote:

[...'chsh' has no effect, and this command:
   sudo grep `whoami` /etc/passwd
prints nothing...]

>>  This depends on the system configuration, /etc/passwd is just one of the
>> possible sources of the user database and I guess this system uses
>> something different, e.g. an LDAP or a NIS server.
> 
> Indeed.

I also tried
  chsh -s /bin/zsh `whoami`
but, after typing my password, it said
  chsh: user [REDACTED] does not exist.

The really weird thing is that 'chsh' lets me change the
shell for the root user, although even as root I can't do
that for my normal user.

>>  Otherwise, I can only recommend putting "exec zsh" (preferably after
>> verifying that it's available!) in your ~/.bash_login, e.g. something like
>> this:
>> 
>>      if hash zsh 2> /dev/null; then
>>              exec zsh -l
>>      fi
> 
> Yup. That's the only convenient way. Others have had this
> problem, and that's the answer that works:
>   
> https://stackoverflow.com/questions/33292541/how-do-i-change-my-default-shell-in-ubuntu-when-not-in-etc-passwd/33292612#33292612

Okay, there's no ~/.bash_login file, so I modified
the existing ~/.bash_profile by adding
  exec /bin/zsh -l
as its first line. That seems to work well enough.
But I still get lots of environment variables that
I don't want, including a full-page definition of
$LS_COLORS, which seems to come from
  /etc/profile.d/colorls.sh
How do I prevent those from being defined?

I tried
  exec -c /bin/zsh
but that leads to
  WARNING: terminal is not fully functional
yet
  export TERM=xterm
seems to fix that problem. However, 'env|less' still
shows an empty
  LS_COLORS=
and other unwanted variables like
  MANPATH=:/opt/puppetlabs/puppet/share/man
  QT_GRAPHICSSYSTEM_CHECKED=1  
How did those get there? I've added
  unsetopt GLOBAL_RCS
to ~/.zshrc, so no global zsh startup files
should be read, except for
  /etc/zshenv
which contains only comment lines.

To thank you for reading this far, I'll tell an amusing
story. I spent half an hour trying to figure out why
  sudo sh
started /bin/sh even though I had changed root's default
shell to zsh using chsh. (SPOILER a few lines below,
in case it's not obvious.)

I figured that I must have started zsh, because:
  echo $SHELL
  /bin/zsh
and I was puzzled that this command:
  ps -p $$
insisted that I had actually run 'sh'.

It turns out that I had memorized 'sudo sh' as the closest
approximation to 'su' that I'm permitted to do on this
server, so I thought I was in effect executing 'su'.
Eventually I realized that I needed to add a 'z' in
  sudo sh
if I wanted to start zsh as root.

So now the Delete key no longer means "change case"
in a root shell, which sounds like a small thing but
actually makes me much more productive.