On Wed, Oct 29, 2014 at 09:52:14PM +0100, k...@shike2.com wrote: > I read this sentence as 'SHELL variable must hold always the value of > the user preferred command in the /etc/passwd file, and any program > that create a session must be aware of setting it from /etc/passwd'. > The sentence doesn't say that the user's preferred command language > interpreter is the value of SHELL instead of the value of /etc/passwd. > > > such, st should check for its presence when deciding what shell to > > use; just as HOME can be defined to override one's passwd-defined home > > directory, a user should also be able to override their passwd-defined > > shell using the SHELL environment variable. > > HOME must hold the value of the user's home directory, if this > value is not the value of /etc/passwd then you have an error > in your configuration. The same can be said about SHELL. You > can change your shell selection using chsh.
I don't agree with your interpretation of the POSIX verbiage, but regardless, in my experience, the vast majority of applications check for $HOME before checking a user's passwd entry and the same applies with shells. Going with the principal of least surprise, this patch makes perfect sense. Even if you ignore that. I think SHELL could be a considered a special case -- a user may not have control of their system shell, and their only option for overriding it is updating SHELL after logging in. Eric
