[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problems with handicapped 'bash' from glibc package
From: |
Mark H Weaver |
Subject: |
Re: Problems with handicapped 'bash' from glibc package |
Date: |
Wed, 12 Feb 2014 17:39:35 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
address@hidden (Ludovic Courtès) writes:
> Mark H Weaver <address@hidden> skribis:
>
>> The 'bash' in the glibc package is handicapped in at least two ways:
>>
>> * It can't set the locale, because it looks for locales in
>> /nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-intermediate-2.18-locales
>>
>> * It can't look up anything from NSS, such as passwd data, because it
>> tries to load the modules from
>> /nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-intermediate-2.18
>>
>> There are two problems that need to be addressed, I think:
>>
>> * Users could easily end up with this handicapped 'bash' as their
>> primary bash, if they installed (or upgraded?) 'glibc' since the last
>> time I installed 'bash'. This happened to me, for example.
>>
>> * Some (most?) programs in Guix that launch subprocesses with the shell
>> use this handicapped one. For example, every time I run 'w3m', it
>> prints two warnings about 'sh' being unable to set the locale.
>>
>> Any suggestions about how we should address these problems?
>
> Indeed, that’s a problem.
>
> For the record, the handicaped bash comes from the removal of /bin/sh
> [0]. It is used by ‘system’ and ‘popen’.
>
> Looks like solving this would require either rewriting glibc references
> in the static bash binary (tricky, especially since the glibc directory
> names have different lengths currently), or building Bash directly in
> the glibc-final derivation so that it refers to the right libc with all
> its bells and whistles.
>
> The latter sounds best, but it would require to sort of duplicate the
> build recipe of Bash internally.
FWIW, I think this latter option is the least bad of the ones you
suggested, and I can't think of a better solution.
While we're on the subject of 'bash', should we be applying the patches
in http://ftp.gnu.org/gnu/bash/bash-4.2-patches/ ?
Mark