Builders should use ${stdenv.shell} instead of /bin/sh about nixpkgs HOT 15 CLOSED

I think that there are requirements in other places that /bin/sh has to be bash, currently. Some builds fail if not so.

from nixpkgs.

Agree with @peti, it's good to get rid of /bin/sh references.

from nixpkgs.

There might be much more offenders. Some build-scripts just have hard-coded paths in them (like /usr/bin/perl). Is there any preConfigure script which fixes these automatically? If not, I think we should create one, it's the problem of many packages.

from nixpkgs.

I have a patch somewhere that runs patchShebangs on the source tree before configurePhase (as suggested by @civodul a while back). I'll add it after the next stdenv merge.

from nixpkgs.

I didn't only mean sheBangs, also insides of the scripts... but maybe that would be better reported upstream, I don't know.

from nixpkgs.

@edolstra you seem to have forgottten to commit your patch

from nixpkgs.

+1 for the patch

from nixpkgs.

@edolstra Do you still have the patchShebangs patch around? Would be good to have.

As for this issue... Should we keep this open or just try to fix this incrementally and document that it's the proper best practice?

from nixpkgs.

After doing #8881 it seems that the following are false positives in the list above:

pkgs/shells/dash/default.nix
pkgs/tools/misc/qjoypad/default.nix
pkgs/tools/compression/gzip/default.nix
pkgs/development/tools/misc/libtool/libtool2.nix
development/tools/misc/libtool/default.nix
pkgs/development/tools/misc/automake/automake-1.10.x.nix
pkgs/development/tools/misc/automake/automake-1.11.x.nix
pkgs/development/tools/misc/automake/automake-1.12.x.nix
pkgs/development/tools/misc/automake/automake-1.13.x.nix
pkgs/development/tools/misc/automake/automake-1.14.x.nix
pkgs/development/tools/misc/automake/automake-1.15.x.nix
pkgs/development/tools/misc/autoconf/2.13.nix
pkgs/development/tools/misc/autoconf/default.nix
pkgs/development/libraries/cloog-ppl/default.nix
pkgs/development/libraries/pango/default.nix
pkgs/development/libraries/libgpg-error/default.nix
pkgs/development/libraries/nss/default.nix
pkgs/development/libraries/cloog/0.18.0.nix
pkgs/development/libraries/cloog/default.nix
pkgs/development/libraries/glibc/common.nix
pkgs/development/r-modules/default.nix
pkgs/stdenv/nix/default.nix
pkgs/stdenv/linux/default.nix
pkgs/applications/graphics/shotwell/default.nix
pkgs/applications/networking/cluster/mesos/default.nix
pkgs/applications/editors/music/tuxguitar/default.nix
pkgs/applications/video/shotcut/default.nix
pkgs/build-support/builder-defs/builder-defs.nix

and the following are done:

development/libraries/icu/default.nix

from nixpkgs.

(triage) There’s still a lot of /bin/bash. Maybe an easy task for a beginning contributor? (Is there a tag for that?)

from nixpkgs.

I want to be able distinguish between using sh and bash. If ${stdenv.shell} can be assumed to be bash compatible (also which Bash?), then I would also like to have a ${stdenv.posix_shell} which is just plain old /bin/sh. /bin/sh is a part of POSIX, so it seems weird if that doesn't work or is considered to be "wrong", but perhaps this is related to allow cross builds to work.

The motivation for getting rid of /bin/sh seems to be lacking. So, while there might be a motivation, this ticket doesn't contain one and I am not in favor of "fixing" this, until there is a motivation in the ticket.

from nixpkgs.

Using /bin/sh breaks purity, and there are a few realistic scenarios where it does create annoying problems. POSIX is not relevant here — we provide /bin/sh on NixOS because of POSIX, but it is still a good idea not to use it inside builds. #1424 is a problem with system() using /bin/sh, but any use can trigger a similar problem.

from nixpkgs.

there is also a second major fault in /bin/sh and sandboxes, if you need to build a missing output of the glibc /bin/sh uses, the entire glibc has to be rebuilt, so ${glibc.lib} is omitted from the sandbox, and now /bin/sh is broken

99% of the time, the binary cache will have you covered, but if you aren't getting glibc from the cache for whatever reason, and you nix-collect-garbage one of glibc's outputs, your screwed

only way out is to make sure the build uses a different glibc from /bin/sh (so sh has to be held behind a mass-rebuild)

from nixpkgs.

Over long term, I'd prefer if /bin/sh in builds were taken from stdenv.shell, to improve purity. That would side-step this problem of trying to rebuild (part of) bash's glibc.

from nixpkgs.

I think we can close this one.

from nixpkgs.