[Nix-dev] Dealing with non-Bash /bin/sh on non-NixOS

Shea Levy shea at shealevy.com
Fri Nov 9 19:13:31 CET 2012


On 11/09/2012 01:06 PM, Eelco Dolstra wrote:
> Hi Peter,
>
> On 09/11/12 18:57, Peter Simons wrote:
>
>>   >> we should link /bin/sh to Dash instead of Bash. That would catch any
>>   >> implicit dependencies on non-POSIX shell features,
>>   >
>>   > What's the point of that? Breaking zillions of existing scripts for
>>   > very little gain doesn't sound like a good idea to me.
>>
>> now I am confused. In the very posting I was responding to, you said:
>>
>>   | Yes, fix builders not to rely on /bin/sh (or at least not to assume
>>   | it's Bash).
>>
>> Apparently, we consider builders broken that assume /bin/sh to be Bash.
>> So why don't you see the benefit of using a non-Bash shell for /bin/sh
>> to expose those broken builders?
> What I meant was that in Nixpkgs you shouldn't assume that /bin/sh is Bash,
> because we obviously don't control that on non-NixOS systems.  So builders
> should *not* use /bin/sh, but ${pkgs.bash}/bin/sh (or whatever shell they want),
> i.e. make the shell dependency explicit.  And then there is no problem in using
> shell-specific features.
>
> Ideally we wouldn't have /bin/sh in Nix chroots, but that's not realistic given
> that functions like system() require /bin/sh.

FWIW, there are ways around this. A relatively straightforward way is to 
have all uses of sh in glibc (there are not many, I've checked this in 
the past) use exec*p* versions, i.e. look for sh in $PATH. Then there's 
a more complex way involving hash-rewriting that I'm so sure you won't 
like that I won't even try to make a case for it :)

>> Besides, everyone who is running Nix on a host system other than NixOS
>> potentially *has* a non-Bash /bin/sh. (Which is why this thread was
>> started.) So it doesn't feel right to say that changing /bin/sh to a
>> non-Bash shell would "break scripts". That change would just expose
>> scripts that are broken already.
> No, that's completely wrong.  Backwards compatibility is important, much more
> than POSIX compatibility: you can't just quietly change /bin/sh and then say
> that those scripts were "already broken".  They worked just fine :-)
>



More information about the nix-dev mailing list