4 ms·

I really want to love Nix and have installed it multiple times. It's non-standard file layout gets me every time though. Something as simple as `#!/bin/bash` no

I really want to love Nix and have installed it multiple times. It's non-standard file layout gets me every time though. Something as simple as `#!/bin/bash` not working is problematic for me. I also find that trying to install anything not included in the Nix package manager is pretty much impossible (building from source...). Please correct me if I'm Nix-ing wrong.

tathougies 9y ago
You shouldn't be using /bin/bash anyway. The proper she-bang is '#!/usr/bin/env bash', which works on nix. The location of bash in /bin/ is actually not standard at all, despite some linux distributions doing that. In particular, the BSDs also do not have bash in /bin. This is why using '/usr/bin/env bash' is more portable
- wereHamster 9y ago
  But is `/usr/bin/env` standard?
- satbyy 9y ago
  Conversely, Python's PEP394 explicitly discourages `/usr/bin/env python`, so there's that. (I know why the PEP says so, just pointing out that it differs from Nix style)
  - adamtulinius 9y ago
    The PEP doesn't even mention /usr/bin/env. Look for yourself: https://www.python.org/dev/peps/pep-0394/ https://www.python.org/dev/peps/pep-0394/
- muxator 9y ago
  I've always mechanically written '#!/bin/bash' as my shebang for bash script, while I normally use '#!/usr/bin/env python' for python scripts. In retrospect, that sounds obviously incoherent. I would like to know if there is some common practice/standard around using '/usr/bin/env' in shebangs. Could you please elaborate more?
- eikenberry 9y ago
  > /usr/bin/env That won't work everywhere either as the location of 'env' is not a fixed standard either. Eg. In some *nix's its at /bin/env.
  - pxc 9y ago
    What modern/surviving Unix-likes don't have even a symlink in `/usr/bin/env`? I'm not 100% sure on all of these, but every one of the dozens of Linux distros I've used has `/usr/bin/env`. macOS has it, and it looks like FreeBSD does, too, and so does NetBSD. Who are the oddballs? Does it include any of the free Unices?
    - pxc 9y ago
      (I'm not trying to be shitty; I'd really like to know. I spent some time Googling about conventions for the `env` command, and examples of incompatible systems. The only ones I found were two old, proprietary Unices. I got tired of searching and was hoping someone who knows a few examples offhand could help me out.)
- eridius 9y ago
  Incidentally, macOS, whose CLI is derived from BSD, does in fact have /bin/bash.
jbboehr 9y ago
There is a `/bin/sh` and `/usr/bin/env` provided - so you can use `/usr/bin/env bash`. There is also this function which may be necessary for certain software: https://nixos.org/nixpkgs/manual/#sec-fhs-environments https://nixos.org/nixpkgs/manual/#sec-fhs-environments You can compile some software manually in place using, for example, `nix-shell -p libssh2 -p zlib` without having to write a derivation. However, without writing a derivation, it may cease to function after a garbage collection or an upgrade. Writing a derivation isn't too bad, here's one for one of my repos: https://github.com/jbboehr/handlebars.c/blob/master/derivation.nix https://github.com/jbboehr/handlebars.c/blob/master/derivati...
vertex-four 9y ago
Sure - you're Nixing wrong. Not to worry, it actually takes ages to figure out how to Nix right - there's not enough documentation on the matter. The correct way to get almost anything installed is to write a Nix package, and install that. This is actually remarkably easy in comparison to other package managers - you write the package definition in a single file, normally just having to set the source code location and list its dependencies, and you can make it available to install with nix-env by adding it to a packageOverrides declaration in ~/.config/nixpkgs/config.nix. The "stdenv" build system that nixpkgs uses will automatically install anything that can be configured via "./configure && make && make install" - cmake is supported just by listing that as a build dependency. Stuff written in scripting languages is more fiddly, but the nixpkgs documentation usually has examples. The downside is that a significant amount of the time, libraries written in scripting languages aren't packaged either, and you wind up packaging half a dozen libraries just to get some tool working. The <X>2nix tools can be useful in these cases to generate a package definition.
- malvosenior 9y ago
  Thank you for the awesome reply (and everyone else). This is precisely the issue I have though: > The downside is that a significant amount of the time, libraries written in scripting languages aren't packaged either, and you wind up packaging half a dozen libraries just to get some tool working. I've gone down this path a few times and days later when I still don't have the original thing I wanted working installed, then I sort of give up. I realize there are many benefits to Nix and I really enjoy them but I've switched to using Arch for practical reasons. I really, really miss the declarative reproducible style though.
  - vertex-four 9y ago
    What I wind up doing while developing is just creating a nix-shell with my native dependencies, and using pip/cargo/whatever inside that. It's not the "proper" way of doing things - you wouldn't want to install a tool long-term that way - but it's useful for one-off things or while you're playing around. I've used npm2nix and cargo2nix a couple of times with success - they generate package sets from the relevant sources.
zimbatm 9y ago
Please don't down-vote criticism. This is a real feedback which I am sure applies to a lot of new-comers.

tathougies 9y ago

You shouldn't be using /bin/bash anyway. The proper she-bang is '#!/usr/bin/env bash', which works on nix. The location of bash in /bin/ is actually not standard at all, despite some linux distributions doing that. In particular, the BSDs also do not have bash in /bin. This is why using '/usr/bin/env bash' is more portable

wereHamster 9y ago
But is `/usr/bin/env` standard?
satbyy 9y ago
Conversely, Python's PEP394 explicitly discourages `/usr/bin/env python`, so there's that. (I know why the PEP says so, just pointing out that it differs from Nix style)
- adamtulinius 9y ago
  The PEP doesn't even mention /usr/bin/env. Look for yourself: https://www.python.org/dev/peps/pep-0394/ https://www.python.org/dev/peps/pep-0394/
muxator 9y ago
I've always mechanically written '#!/bin/bash' as my shebang for bash script, while I normally use '#!/usr/bin/env python' for python scripts. In retrospect, that sounds obviously incoherent. I would like to know if there is some common practice/standard around using '/usr/bin/env' in shebangs. Could you please elaborate more?
eikenberry 9y ago
> /usr/bin/env That won't work everywhere either as the location of 'env' is not a fixed standard either. Eg. In some *nix's its at /bin/env.
- pxc 9y ago
  What modern/surviving Unix-likes don't have even a symlink in `/usr/bin/env`? I'm not 100% sure on all of these, but every one of the dozens of Linux distros I've used has `/usr/bin/env`. macOS has it, and it looks like FreeBSD does, too, and so does NetBSD. Who are the oddballs? Does it include any of the free Unices?
  - pxc 9y ago
    (I'm not trying to be shitty; I'd really like to know. I spent some time Googling about conventions for the `env` command, and examples of incompatible systems. The only ones I found were two old, proprietary Unices. I got tired of searching and was hoping someone who knows a few examples offhand could help me out.)
eridius 9y ago
Incidentally, macOS, whose CLI is derived from BSD, does in fact have /bin/bash.

jbboehr 9y ago

There is a `/bin/sh` and `/usr/bin/env` provided - so you can use `/usr/bin/env bash`. There is also this function which may be necessary for certain software: https://nixos.org/nixpkgs/manual/#sec-fhs-environments https://nixos.org/nixpkgs/manual/#sec-fhs-environments You can compile some software manually in place using, for example, `nix-shell -p libssh2 -p zlib` without having to write a derivation. However, without writing a derivation, it may cease to function after a garbage collection or an upgrade. Writing a derivation isn't too bad, here's one for one of my repos: https://github.com/jbboehr/handlebars.c/blob/master/derivation.nix https://github.com/jbboehr/handlebars.c/blob/master/derivati...

vertex-four 9y ago

Sure - you're Nixing wrong. Not to worry, it actually takes ages to figure out how to Nix right - there's not enough documentation on the matter. The correct way to get almost anything installed is to write a Nix package, and install that. This is actually remarkably easy in comparison to other package managers - you write the package definition in a single file, normally just having to set the source code location and list its dependencies, and you can make it available to install with nix-env by adding it to a packageOverrides declaration in ~/.config/nixpkgs/config.nix. The "stdenv" build system that nixpkgs uses will automatically install anything that can be configured via "./configure && make && make install" - cmake is supported just by listing that as a build dependency. Stuff written in scripting languages is more fiddly, but the nixpkgs documentation usually has examples. The downside is that a significant amount of the time, libraries written in scripting languages aren't packaged either, and you wind up packaging half a dozen libraries just to get some tool working. The <X>2nix tools can be useful in these cases to generate a package definition.

malvosenior 9y ago
Thank you for the awesome reply (and everyone else). This is precisely the issue I have though: > The downside is that a significant amount of the time, libraries written in scripting languages aren't packaged either, and you wind up packaging half a dozen libraries just to get some tool working. I've gone down this path a few times and days later when I still don't have the original thing I wanted working installed, then I sort of give up. I realize there are many benefits to Nix and I really enjoy them but I've switched to using Arch for practical reasons. I really, really miss the declarative reproducible style though.
- vertex-four 9y ago
  What I wind up doing while developing is just creating a nix-shell with my native dependencies, and using pip/cargo/whatever inside that. It's not the "proper" way of doing things - you wouldn't want to install a tool long-term that way - but it's useful for one-off things or while you're playing around. I've used npm2nix and cargo2nix a couple of times with success - they generate package sets from the relevant sources.

zimbatm 9y ago

Please don't down-vote criticism. This is a real feedback which I am sure applies to a lot of new-comers.