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

This patch makes xterm honor $SHELL (or the shell in the user's password entry) even if it's not in /etc/shells. WDYT? Mark >From 15d59a2d31794ffa6049bbcf878d568593099dc5 Mon Sep 17 00:00:00 2001 From: Mark H Weaver Date: Thu, 13 Feb 2014 02:00:39 -0500 Subject: [PATCH] gnu: xterm: Accept

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

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

Re: Guix under GNU???s umbrella for GSoC?

pjotr.publi...@thebird.nl skribis: > How good is user space support for Guix? Guix is a purely user-space thing: a package manager, and a distribution of user-space programs. It requires to have the daemon running as root (see

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

John Darrington 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

Re: [PATCH] gnu: ratpoison: Patch to use $SHELL instead of /bin/sh

On Thu, Feb 13, 2014 at 01:28:25AM -0500, Mark H Weaver wrote: > I'm not entirely sure this will be wanted, but it bugged me that > ratpoison has /bin/sh hardcoded in its source code. WDYT? Should it be replaced by the user $SHELL or by (which "bash")? Andreas

Re: Problems with handicapped 'bash' from glibc package

On Wed, Feb 12, 2014 at 09:33:16PM +, Mark H Weaver wrote: > The patches are bug fixes. Things like: > I don't want to run a shell with known bugs. > I want these fixes on my system. > > What do you think? I think you should try to gently prod the bash maintainers to prepare a new release; t

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

On Thu, Feb 13, 2014 at 03:47:54AM -0500, Mark H Weaver wrote: John Darrington 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/

Re: [PATCH] gnu: ratpoison: Patch to use $SHELL instead of /bin/sh

Andreas Enge skribis: > On Thu, Feb 13, 2014 at 01:28:25AM -0500, Mark H Weaver wrote: >> I'm not entirely sure this will be wanted, but it bugged me that >> ratpoison has /bin/sh hardcoded in its source code. WDYT? > > Should it be replaced by the user $SHELL or by (which "bash")? I think it’s

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

Mark H Weaver skribis: > IMO, it's not reasonable to have to add > /home///bin/ for every combination of , > , and to /etc/shells, in order to prevent 'xterm' from > overriding your $SHELL setting. On NixOS, /etc/shells contains this: --8<---cut here---start

Re: Guix under GNU???s umbrella for GSoC?

How good is user space support for Guix? I haven't gotten down to trying yet, but that is on my list. If that works I could think of many applications (Python/Ruby modules, vim modules, etc.). Or are we forced to have a server running? Recompilation is not a problem. Pj. On Wed, Feb 12, 2014 at

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

l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> IMO, it's not reasonable to have to add >> /home///bin/ for every combination of , >> , and to /etc/shells, in order to prevent 'xterm' from >> overriding your $SHELL setting. > > On NixOS, /etc/shells contains this: > > /run/c

[gnu.org #881181] Package synopses and blurbs translation

> [karl - Sat Jan 11 18:34:38 2014]: > > > What would you prefer? > > I prefer plain text, but I don't feel that strongly about it, as such. > > > about not introducing HTML markup in the translated text? > > If the "translation" you're referring to is the home-pkgblurbs.html file > which the w