John Darrington <[email protected]> writes:
> On Thu, Feb 13, 2014 at 03:00:29AM -0500, Mark H Weaver wrote:
> This patch makes xterm honor $SHELL (or the shell in the user's password
> entry) even if it's not in /etc/shells. WDYT?
>
>
> It sounds like a good idea to me. /etc/shells is supposed to be only a
> whitelist of
> those shells which may be used for login. Not an exhaustive list of shells
> which
> may be used at all.
>
> However, I'm wondering if we are forking too many upstream packages. We
> should
> only patch software in order to allow it to build/install.
Really? Just enough to build/install? Not enough to work properly? I
agree that we should stay as close as we reasonably can to upstream, but
sometimes things have to be fixed to work with Guix, which after all is
a rather unusual distro.
FYI, xterm doesn't merely ignore your $SHELL setting if it's not in
/etc/shells, it also *sets* $SHELL to "/bin/sh" for you in that case,
and then proceeds runs it.
IMO, it's not reasonable to have to add
/home/<USER>/<PROFILE>/bin/<SHELL> for every combination of <USER>,
<PROFILE>, and <SHELL> to /etc/shells, in order to prevent 'xterm' from
overriding your $SHELL setting.
> If we want to change the behaviour like here, that should be sent to
> upstream for their next release.
Well, I agree that it would be good to try this, however:
> If they refuse the patch, then of course you can start your own
> weavershell fork...
Fork it to change two lines?
Mark
