On Thu, Mar 06, 2014 at 07:47:51PM +0100, Sven Joachim wrote: > > hmm - I see that I still overlooked documenting the /etc/shells tie-in > > in the manpage. It's in the changelog, of course, ...however, Thorsten's report is against a regression due to a late change that I made (incorrectly) based on a Coverity report pointing out a possible null-pointer dereference in one of the paths. At the moment I'm validating a different fix. > I cannot deduce from the changelog that xterm actually _clears_ the > SHELL variable if it does not point to a shell in /etc/shells. Besides > that, the comment you added in front of the validShell function is also > rather misleading: I spent some time tonight and documented the unset in the manpage. (I meant to do this in #302, but overlooked it in the details for the discussion of the optional parameter). > --8<---------------cut here---------------start------------->8--- > --- a/main.c > +++ b/main.c > @@ -3145,6 +3151,7 @@ find_utmp(struct UTMP_STR *tofind) > > /* > * Only set $SHELL for paths found in the standard location. > + * ...or if $SHELL happens to give an absolute pathname to an executable. I'll remove that, then. It was leftover from changes I made before factoring out validProgram(). > */ > static Boolean > validShell(const char *pathname) > --8<---------------cut here---------------end--------------->8--- > > > So - to the point: is /bin/mksh in /etc/shells? If not, adding it > > there is the way to get your intended behavior. > > Almost everybody can set SHELL to their liking, but they might not be > allowed to change /etc/shells. sure - but not all values of SHELL are usable, and at least two paths through this maze can lead to failure if SHELL happens to not be a regular shell - hence my changes to how SHELL is set (or reset). /etc/shells has a better list than I can get elsewhere - so I chose that. -- Thomas E. Dickey <dickey@invisible-island.net> http://invisible-island.net ftp://invisible-island.net
Attachment:
signature.asc
Description: Digital signature