With Nix, how does the shell search for an executable?
It searches PATH for the right executable.
What dirs does it find them in?
In the `nix store', which is /nix/<HASH>-<PACKAGE>/bin; each program
is linked against the library it was compiled against which is located
in the `nix store'. So for example, GNU hello 1.0 might look like
Where the lines mean ELF shared dependencies (i.e. hello is linked
against libhello.so and libc.so).
Is it true that /bin does
not exist as we are used to?
That is correct, the only thing in /bin is /bin/sh for backward
If it's true, how is it different
I tried to write a condensed description, but it wasn't very good so
I've quoted part of the description from Nix instead.
| Nix is a purely functional package manager. This means that it treats
| packages like values in purely functional programming languages such
| as Haskell â they are built by functions that donât have side-effects,
| and they never change after they have been built. Nix stores packages
| in the Nix store, usually the directory /nix/store, where each package
| has its own unique subdirectory such as
| where r8vvq9kqâ¦ is a unique identifier for the package that captures
| all its dependencies (itâs a cryptographic hash of the packageâs build
| dependency graph). This enables many powerful features.
| * Multiple versions
| You can have multiple versions or variants of a package installed at
| the same time. This is especially important when different
| applications have dependencies on different versions of the same
| package â it prevents the âDLL hellâ. Because of the hashing scheme,
| different versions of a package end up in different paths in the Nix
| store, so they donât interfere with each other.
| An important consequence is that operations like upgrading or
| uninstalling an application cannot break other applications, since
| these operations never âdestructivelyâ update or delete files that are
| used by other packages.
| * Complete dependencies
| Nix helps you make sure that package dependency specifications are
| complete. In general, when youâre making a package for a package
| management system like RPM, you have to specify for each package what
| its dependencies are, but there are no guarantees that this
| specification is complete. If you forget a dependency, then the
| component will build and work correctly on your machine if you have
| the dependency installed, but not on the end user's machine if it's
| not there.
| Since Nix on the other hand doesnât install packages in âglobalâ
| locations like /usr/bin but in package-specific directories, the risk
| of incomplete dependencies is greatly reduced. This is because tools
| such as compilers donât search in per-packages directories such as
| /nix/store/5lbfaxb722zpâ¦-openssl-0.9.8d/include, so if a package
| builds correctly on your system, this is because you specified the
| dependency explicitly.
| Runtime dependencies are found by scanning binaries for the hash parts
| of Nix store paths (such as r8vvq9kqâ¦). This sounds risky, but it
| works extremely well.