-
-
Notifications
You must be signed in to change notification settings - Fork 14k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chroot environments have no /usr/bin/env
?
#6227
Comments
It's always been that way. Use patchShebangs. On Sun, Feb 8, 2015 at 1:50 PM, Peter Simons [email protected]
NixOS Linux http://nixos.org |
IMHO it's silly that a perfectly portable shell script needs patching to run on NixOS. Especially considering the fact that the NixOS system does provide |
/usr/bin/env in nixos is solely for the user daily convenience, not for On Sun, Feb 8, 2015 at 1:55 PM, Peter Simons [email protected]
NixOS Linux http://nixos.org |
Providing |
It's not inconsistent, it's counter-intuitive maybe. Tell people to enable chroot builds and that's it. For me this issue can be closed, unless you want better docs in the nix manual. |
@peti patchShebangs works fast and fine and removes all doubt about what a script runs while debugging builds. |
Do you have any rational reasoning for that position, or is this argument valid simply by means of stamping your foot on the ground real hard? |
@peti perhaps you have a reasoning of why it's inconsistent, or it's just because you were surprised by this behavior and maybe need some time thinking. |
@wmertens, I feel it's important that well-written portable scripts can run in a Nix build environment without the need for patching. The path Another problem is that people use the |
@peti I'm not 100% sure I follow, you want to run scripts from your homedir Could you post a simple step-by-step illustrating why not having env is a On Sun Feb 08 2015 at 2:21:38 PM Peter Simons [email protected]
|
|
utdemir/handsy#5 is a concrete example that illustrates this kind of failure. The code assumes that |
Ok, so in these particular cases, ${stdenv.shell} should have been used In fact you don't even need to give the shebang for bash scripts, if The only thing I can think of where it would be nice to have env is when After all, when the build completes and there are still calls to env So I'm still not convinced. On Sun Feb 08 2015 at 2:49:31 PM Peter Simons [email protected]
|
@wmertens: I think that was just an example. If the code is written in nix to begin with, I agree, use ${stdenv.shell}. But what if the code came from an upstream project? patchShebangs doesn't automatically solve all problems. It cannot handle scripts that are generated and run in the middle of a build. If an /usr/bin/env script is placed in $out, fixupPhase will rewrite the shebang. So I don't think having /usr/bin/env shebangs in builders changes the hash-based dependency in any way. |
So basically we're trying to fix a hypothetical upstream project that uses I'm not convinced... I'd rather fix that problem if and when it appears. I think it would be much nicer to remove /bin/sh as well... On Sun, Feb 8, 2015, 5:10 PM Bjørn Forsman [email protected] wrote:
|
@wmertens, what makes you say that this is issue is hypothetical? |
Well point me to an actual package with this problem then? On Sun Feb 08 2015 at 6:39:10 PM Peter Simons [email protected]
|
@wmertens, #6227 (comment) maybe? |
@peti would you be more okay with this if we were getting rid of I ask because I too am striving to get rid of |
@copumpkin, I don't know how I'd prefer to remedy this issue, I haven't formed an opinion yet. So far, the options we are aware of are:
Are there any alternative suggestions? Further pros or cons that I missed? |
Pro: weird LD_LIBRARY_PATH-related failures on glibc updates go away. These are chrooted Nix-on-NixOS build failures.
|
@7c6f434c, I'm not aware of any LD_LIBRARY_PATH-related failures. When do these occur? |
@peti hmm I missed the fact that handsy was not in nixpkgs. So indeed it does happen, although the fix is generally simple. Once #1424 is solved it's no longer a factor for or against this issue. So now it's weighing the trouble of fixing builds that need sh or env vs the trouble of using packages that use /bin/sh or /usr/bin/env. Perhaps there should be a warning/error when a finished build still contains references to either after fixupPhase, and then allow both in the chroot? |
@7c6f434c, that issue is important, but is it related to the problem we're discussing here? The build failure in #1424 was caused by the fact that |
@wmertens, based on what empirical data do you assert that "the fix is generally simple"? I don't believe that generalization is valid, because the fix for EDIT: Also, please note that the problems we've had with |
@peti Given that we're generally talking about scripts, just patching the On Mon Feb 09 2015 at 10:57:24 AM Peter Simons [email protected]
|
@wmertens, okay. This is probably not going anywhere. Let us agree to disagree. |
Anything using /bin/sh while LD_LIBRARY_PATH is set would trigger that |
@peti don't know what that code does exactly, however it reads the contents of /bin/sh for doing a couple of tests, not even executing it. Why not replace that /bin/bin string with |
@7c6f434c, okay, I see your point. Any attempt to execute |
Having Of course, it's probably best to avoid any |
As a data point, I've had actual failures in my pure-Darwin work as a result of it using the global shell
|
@copumpkin, "global shell" means "Darwin's |
Yeah, sorry On Monday, February 9, 2015, Peter Simons [email protected] wrote:
|
Closing this issue because it seems unlikely that a consensus for action in any direction can be reached, so let's leave everything as is. It's working good enough anyway. |
A very related question: I want to patch some scripts to pick up the interpreter from The reason is that I want to share about a gigabyte of paths among all platforms and stdenvs (by putting them into fixed-output derivations). |
Can't you simply let the shell pick up the path with a wrapper? On Wed, Aug 26, 2015 at 2:36 PM Vladimír Čunát [email protected]
Wout. |
Hmm, |
@peti I am on your side with this one (not that anyone is counting). |
This works around NixOS/nixpkgs#6227 It looks like I can’t run the “portable script” that I am creating in order to ship it in my own nix-build :-(
I understand |
I've been bitten by this issue, due to webpack CLI's
|
Workaround: { pkgs ? import <nixpkgs> {}
}:
pkgs.runCommand "example" {} ''
# Ensure that /usr/bin/env exists in our build sandbox
mkdir -m 0755 -p /usr/bin && ln -sfn "${pkgs.coreutils}/bin/env" /usr/bin/env
# Perform whatever build steps you want here
mkdir -p $out && cd $out
${./some-script-that-uses-usr-bin-env.sh}
'' This allows you to run scripts that use This could also be turned into a hook: { pkgs ? import <nixpkgs> {}
}:
let
usrBinEnvHook = pkgs.makeSetupHook { name = "usr-bin-env-hook"; } (pkgs.writeText "create-usr-bin-env.sh" ''
mkdir -m 0755 -p /usr/bin
ln -sfn "${pkgs.coreutils}/bin/env" /usr/bin/env
'');
in
pkgs.runCommand "example" { buildInputs = [ usrBinEnvHook ]; } ''
mkdir -p $out && cd $out
${./some-script-that-uses-usr-bin-env.sh}
'' So I guess a relevant question here is whether we would want this hook to be part of nixpkgs (for example pkgs.usrBinEnvHook). |
FWIW I'm running into this issue as well while packaging cppyy, with scripts generated during the build assuming that
This does not work, but the error did not cause the drv build to fail due to the use of
PS: Quoting my reply to the (non-functional?)
|
This may be a stupid question, but I just realized that Nix chroot environments (as configured by NixOS) have no
/usr/bin/env
path. This comes as a surprise to me. Has this always been this way? How are scripts supposed to specify a portable shebang to, saybash
, without having a reliable path toenv
?The text was updated successfully, but these errors were encountered: