guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] gnu: xterm: Accept $SHELL even if not in /etc/shells


From: Mark H Weaver
Subject: Re: [PATCH] gnu: xterm: Accept $SHELL even if not in /etc/shells
Date: Thu, 13 Feb 2014 03:47:54 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

John Darrington <address@hidden> 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

[Prev in Thread] Current Thread [Next in Thread]