John Darrington <j...@darrington.wattle.id.au> 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

Reply via email to