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