l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver <m...@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