Common Issue: accessing binaries like /bin/bash

Guides
1

Coming from other systems, you may be used to locating binaries like /bin/bash.

On NixOS, the currently used binaries are in an always changing location of the nix store

$ whereis bash
bash: /nix/store/ggl4fqsvvlyf1y3rl6mk72nf0dc8c8hr-system-path/bin/bash

Instead you can use this directory, where the binaries are linked to. Note that there is no guarantee that the binaries are there.

/run/current-system/sw/bin/

It should also be in your PATH, so you can run the binaries directly, also in .desktop files and scripts.

A better solution is to use

!/usr/bin/env bash

which works on all normal desktop Linux systems and thus does not make your scripts nix-specific.

A “hack” to make bash available at the expected location is here.

Read below on options how to use nix instead

2 Likes
2

“their path always changes” can be better thought of as “there are multiple paths”.

And those paths–those store paths–are obtained via usage of the Nix language. For example, lib.getExe pkgs.gnugrep.

I don’t remember ever explicitly addressing /run/current-system/sw/bin/. When an executable is in your path it hopefully reached there via idiomatic usage of Nix code such as the above or the NixOS environment.systemPackages or the Home Manager home.packages options or similar.

For use in a script, you have for example the runtimeInputs of pkgs.writeShellApplication or an inline lib.getExe or lib.getExe'.

Such usages attempt to guarantee the existence of the expected executable at a certain Nixpkgs revision and configuration in the store. Referring to /run/current-system/sw/bin provides no such guarantees.

4 Likes
3

What if you want to find binaries without using Nix? Like in a bash script?

Normally binaries should be in your PATH so this is a pretty rare situation I guess

but it is essential for shebangs in scripts and a few other things

1 Like
4

Right: the pattern is to link store paths to well known locations or add store paths to well known environment variables. A big truth though of why you don’t want to reference is /run/current-system/sw/bin/ imo is that you aren’t actually creating a stable reference under gc. To wit: lets say I write a script that depends on git and to it in the following way pkgs.writeShellScriptBin "rev-parse" "/run/current-system/sw/bin/git rev-parse HEAD". There is no guarantee that git isn’t going to be removed from environment.systemPackages. Alternatively pkgs.writeShellScriptBin "rev-parse" "${lib.getExe pkgs.git} rev-parse HEAD" is a script that doesn’t care about the globally installed packages, it guarantees its own dependencies are available. Same for desktop files: always interpolate the derivation into the file, now your desktop files install the software they depend on to be valid if they themselves are referenced. This is imo the true zen of nix. Say no to plop!

2 Likes
5

Use nix to write or at least package the script, because that’s the only way to guarantee that the dependent binaries exist.

3 Likes
6

Wow this is totally new to me, I will learn it for sure :wink:

1 Like
7

On the same topic, is there a good way to “just” get /bin/bash to work?

I write scripts and I want to use scripts, they are not part of my nixos config and will never be

8

If you write them, just use #! /usr/bin/env bash. It’s more portable, and thus good practice for linux in general. If you want to use scripts that aren’t written that portably without modification or packaging, there’s envfs (which is already built into nixpkgs, so you don’t need an external repo). It creates a FUSE filesystem you mount on /bin and /usr/bin which just looks up the command name in the calling processes PATH.

8 Likes
9

I agree many third parties write bad non-POSIX shebangs and sometimes auto-updates will overwrite the fixes you apply, or you won’t be able to modify the scripts at all.

@tejing’s solution with envfs (services.envfs) is great, but keep in mind that if you’re using Impermanence you won’t be able to boot, so instead the following hack in your config will do the trick:

    system.activationScripts.binbash = ''
      mkdir -p /bin
      chmod 0755 /bin
      ln -sfn ${pkgs.bash}/bin/bash /bin/.bash.tmp
      mv /bin/.bash.tmp /bin/bash
    '';
1 Like
10

On your own systems, do whatever, but assuming that /usr/bin/env exists is a mistake for public scripts.

11

In my experience /usr/bin/env is much more reliable than either of /bin/bash//usr/bin/bash

8 Likes
12

I mean all of those aren’t guaranteed to exist, is my point :slight_smile: For public scripts all of those are wrong.

13

In this case, you have to tell us what you do, and what would be “right”. Because, if there is no “right”, then there is no “wrong”, there is only “this is the most reliably working one across several devices”.

Of course, If I know in advance, I will only deploy my scripts to windows, I will respect that in the absent of a shebang and using .bat ending, but hey, that is wrong as well, as it wont work on Linux…

4 Likes
14

thanks, /usr/bin/env bash worked, I didnt test that.

And for my use cases I assume that every linux system has bash preinstalled. that is simply the case for regular desktop operating systems. Bash-compatible shells would hopefully add a symlink or alias to bash

15

I like that hack and I dont think it is that hacky

It just makes the nixos system a bit more normal.

Is there a reason why you link it to the tempfile first and then move it? Do you want to avoid overwriting the file?

16

It ensures that nothing accesses a partially initialized symlink before it’s fully written. And the move operation is (in 99% of filesystems) atomic so it doesn’t cost anything.

Sadly I can’t remember when and where I got the idea from, but it’s been a life-savior many times.

17

GNU coreutils’ ln is atomic, which it achieves by doing exactly what you do, so this is unnecessary in the context of a NixOS activation script. You’re just duplicating ln’s internal logic in bash.

I’m unsure about busybox, but POSIX in general isn’t atomic, so sure, in other contexts this can make sense. Just not for Linux desktops, or frankly in any context where your shebang is explicitly calling for bash.

You probably also shouldn’t use an activation script, as there is work in progress to deprecate them. Ordering a systemd unit so it triggers at the right time (maybe even in stage 1) is almost definitely doable. Use preservation instead of impermanence to avoid activation scripts completely and get sane unit ordering while you’re at it.

This also lets you use systemd-tmpfile to create the symlink instead, eliminating an early interpreter use and consolidating it all into the general-purpose file creation process.

4 Likes
18

Now that’s something I’ve missed. I also looked at the write-up to remove activation scripts and to remove interpreters altogether. Thank you as always, will do some more reading!

Simple and straight to the point. Nice, thank you!

1 Like
19

As yet another voice in agreement:

#!/usr/bin/env bash has been standard practice for near decades now. Just use it.

There are a few exceptions to when you might want it, but if you’re special enough to need them you’re special enough to have read the manual to figure out if that’s you.

Similarly, if you must add more Bash to the world, consider set -euo pipefail at the top after the shebang. It’s slightly less universal, but again, is a good starting point.

Regardless, always use shellcheck and perhaps something like shfmt.

4 Likes
20

Are we the distro trying to fix dependency resolution or not? This is like advocating for dynamic linking to paths in /usr.

Of course you can do it, and we have been doing that for 40 years now, but NixOS is explictly the distro that avoids these standards because we think they’re harmful.

Use a shebang like that if you have a good reason to, and integration with non-NixOS environments can be a good reason, but if you use it in a NixOS context you’re kinda defying the purpose of the distro. It will work, but not for the right reasons.

Obviously it’s a judgement call and as an engineer you need to consider the trade-offs in your situation, but unless you’re just here for the hype using NixOS probably means that your situation values things that make this shebang a bad idea.

3 Likes