Re: Problems with handicapped 'bash' from glibc package

[Mark H Weaver <mhw@netris.org>]

ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> 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