# Common Issue: accessing binaries like /bin/bash
**URL:** https://discourse.nixos.org/t/common-issue-accessing-binaries-like-bin-bash/63312
**Category:** Guides
**Created:** [April 21, 2025, 6:40pm UTC](https://discourse.nixos.org/t/common-issue-accessing-binaries-like-bin-bash/63312 "2025-04-21T18:40:01Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@BoredSquirrel](https://discourse.nixos.org/u/BoredSquirrel)
#### Post date: [April 21, 2025, 6:40pm UTC](https://discourse.nixos.org/t/common-issue-accessing-binaries-like-bin-bash/63312/1 "2025-04-21T18:40:01Z")
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
```auto
$ 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.
```auto
/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
```auto
!/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](https://discourse.nixos.org/t/63312/9).
Read below on options how to use nix instead
---
### Author:  [@mightyiam](https://discourse.nixos.org/u/mightyiam)
#### Post date: [April 22, 2025, 12:19am UTC](https://discourse.nixos.org/t/common-issue-accessing-binaries-like-bin-bash/63312/2 "2025-04-22T00:19:49Z")
“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.
---
### Author:  [@BoredSquirrel](https://discourse.nixos.org/u/BoredSquirrel)
#### Post date: [April 22, 2025, 4:35pm UTC](https://discourse.nixos.org/t/common-issue-accessing-binaries-like-bin-bash/63312/3 "2025-04-22T16:35:43Z")
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
---
### Author:  [@bme](https://discourse.nixos.org/u/bme)
#### Post date: [April 22, 2025, 4:52pm UTC](https://discourse.nixos.org/t/common-issue-accessing-binaries-like-bin-bash/63312/4 "2025-04-22T16:52:14Z")
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](https://youtu.be/-6BsiVyC1kM?t=243&feature=shared)!
---
### Author:  [@waffle8946](https://discourse.nixos.org/u/waffle8946)
#### Post date: [April 22, 2025, 6:35pm UTC](https://discourse.nixos.org/t/common-issue-accessing-binaries-like-bin-bash/63312/5 "2025-04-22T18:35:33Z")
Use nix to write or at least package the script, because that’s the only way to guarantee that the dependent binaries exist.
---
### Author:  [@BoredSquirrel](https://discourse.nixos.org/u/BoredSquirrel)
#### Post date: [April 22, 2025, 7:20pm UTC](https://discourse.nixos.org/t/common-issue-accessing-binaries-like-bin-bash/63312/6 "2025-04-22T19:20:43Z")
Wow this is totally new to me, I will learn it for sure 😉
---
### Author:  [@BoredSquirrel](https://discourse.nixos.org/u/BoredSquirrel)
#### Post date: [June 28, 2026, 4:06pm UTC](https://discourse.nixos.org/t/common-issue-accessing-binaries-like-bin-bash/63312/7 "2026-06-28T16:06:41Z")
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
---
### Author:  [@tejing](https://discourse.nixos.org/u/tejing)
#### Post date: [June 28, 2026, 4:13pm UTC](https://discourse.nixos.org/t/common-issue-accessing-binaries-like-bin-bash/63312/8 "2026-06-28T16:13:12Z")
> [@BoredSquirrel](#):
>
> I write scripts and I want to use scripts, they are not part of my nixos config and will never be
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`](https://github.com/Mic92/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`.
---
### Author:  [@Kaukov](https://discourse.nixos.org/u/Kaukov)
#### Post date: [June 28, 2026, 4:40pm UTC](https://discourse.nixos.org/t/common-issue-accessing-binaries-like-bin-bash/63312/9 "2026-06-28T16:40:17Z")
> [@BoredSquirrel](#):
>
> I write scripts and I want to use scripts, they are not part of my nixos config and will never be
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](https://search.nixos.org/options?channel=26.05&query=envfs#show=option%253Aservices.envfs.enable)) is great, but keep in mind that if you’re using [Impermanence](https://github.com/nix-community/impermanence) you won’t be able to boot, so instead the following hack in your config will do the trick:
```nix
system.activationScripts.binbash = ''
mkdir -p /bin
chmod 0755 /bin
ln -sfn ${pkgs.bash}/bin/bash /bin/.bash.tmp
mv /bin/.bash.tmp /bin/bash
'';
```
---
### Author:  [@waffle8946](https://discourse.nixos.org/u/waffle8946)
#### Post date: [June 29, 2026, 3:23am UTC](https://discourse.nixos.org/t/common-issue-accessing-binaries-like-bin-bash/63312/10 "2026-06-29T03:23:59Z")
> [@tejing](#):
>
> If you write them, just use `#! /usr/bin/env bash`.
On your own systems, do whatever, but assuming that `/usr/bin/env` exists is a mistake for public scripts.
---
### Author:  [@NobbZ](https://discourse.nixos.org/u/NobbZ)
#### Post date: [June 29, 2026, 8:49am UTC](https://discourse.nixos.org/t/common-issue-accessing-binaries-like-bin-bash/63312/11 "2026-06-29T08:49:55Z")
In my experience `/usr/bin/env` is much more reliable than either of `/bin/bash`/`/usr/bin/bash`
---
### Author:  [@waffle8946](https://discourse.nixos.org/u/waffle8946)
#### Post date: [June 29, 2026, 1:55pm UTC](https://discourse.nixos.org/t/common-issue-accessing-binaries-like-bin-bash/63312/12 "2026-06-29T13:55:20Z")
I mean all of those aren’t guaranteed to exist, is my point 🙂 For _public_ scripts all of those are wrong.
---
### Author:  [@NobbZ](https://discourse.nixos.org/u/NobbZ)
#### Post date: [June 29, 2026, 2:04pm UTC](https://discourse.nixos.org/t/common-issue-accessing-binaries-like-bin-bash/63312/13 "2026-06-29T14:04:11Z")
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…
---
### Author:  [@BoredSquirrel](https://discourse.nixos.org/u/BoredSquirrel)
#### Post date: [July 7, 2026, 8:24pm UTC](https://discourse.nixos.org/t/common-issue-accessing-binaries-like-bin-bash/63312/14 "2026-07-07T20:24:54Z")
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
---
### Author:  [@BoredSquirrel](https://discourse.nixos.org/u/BoredSquirrel)
#### Post date: [July 7, 2026, 8:27pm UTC](https://discourse.nixos.org/t/common-issue-accessing-binaries-like-bin-bash/63312/15 "2026-07-07T20:27:48Z")
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?
---
### Author:  [@Kaukov](https://discourse.nixos.org/u/Kaukov)
#### Post date: [July 7, 2026, 8:49pm UTC](https://discourse.nixos.org/t/common-issue-accessing-binaries-like-bin-bash/63312/16 "2026-07-07T20:49:40Z")
> [@BoredSquirrel](#):
>
> Is there a reason why you link it to the tempfile first and then move it? Do you want to avoid overwriting the file?
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.
---
### Author:  [@TLATER](https://discourse.nixos.org/u/TLATER)
#### Post date: [July 8, 2026, 8:40pm UTC](https://discourse.nixos.org/t/common-issue-accessing-binaries-like-bin-bash/63312/17 "2026-07-08T20:40:10Z")
> [@Kaukov](#):
>
> It ensures that nothing accesses a partially initialized symlink before it’s fully written.
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](https://github.com/nix-community/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.
---
### Author:  [@Kaukov](https://discourse.nixos.org/u/Kaukov)
#### Post date: [July 8, 2026, 8:55pm UTC](https://discourse.nixos.org/t/common-issue-accessing-binaries-like-bin-bash/63312/18 "2026-07-08T20:55:50Z")
> [@TLATER](#):
>
> Use [preservation](https://github.com/nix-community/preservation) instead of impermanence to avoid activation scripts completely and get sane unit ordering while you’re at it.
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!
> [@TLATER](#):
>
> 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.
Simple and straight to the point. Nice, thank you!
---
### Author:  [@crertel](https://discourse.nixos.org/u/crertel)
#### Post date: [July 9, 2026, 7:12am UTC](https://discourse.nixos.org/t/common-issue-accessing-binaries-like-bin-bash/63312/19 "2026-07-09T07:12:23Z")
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](https://github.com/koalaman/shellcheck) and perhaps something like [shfmt](https://github.com/patrickvane/shfmt).
---
### Author:  [@TLATER](https://discourse.nixos.org/u/TLATER)
#### Post date: [July 9, 2026, 7:26am UTC](https://discourse.nixos.org/t/common-issue-accessing-binaries-like-bin-bash/63312/20 "2026-07-09T07:26:06Z")
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.
[Next page](https://discourse.nixos.org/t/common-issue-accessing-binaries-like-bin-bash/63312.md?page=2)