For installed packages, you can use readlink:
$ readlink $(type -P reboot)
/nix/store/axx9bvf0dmah41f39ds9xdkds1lsz6z9-systemd-261/bin/reboot
The NixOS search can also search for binaries. It seems that busybox also provides a reboot which I guess might be useful for weird systemd-less deployments?
If you want to search for any file across all packages, there's also nix-index, which scrapes Hydra for output files and builds a database which you can then query with nix-locate.
Just
/run/current-system/sw/bin/rebootactually would work, although it relies on your system closure containing arebootbinary. That's a reasonably safe assumption to make on a NixOS system, but you might not want to do this with other packages.The reason that doesn't work is that the structure of packages and the structure of a NixOS fiile system are different. Consider this:
So the systemd package in the nix store has a
binsubdirectory containing its binaries. However:NixOS doesn't, at least not really (
/bin/shmust exist because thesystemsyscall uses it). Instead binaries for "installed" packages (the technical term would be "packages which are part of the system closure") are symlinked to/run/current-system/sw/bin:More accurately, building a NixOS system creates a sort of meta-package that contains a link farm to all installed binaries in the
sw/bindirectory, and that meta-package is symlinked to/run/current-systemat activation/boot. (Not all package contents are symlinked into this meta-package, also see the NixOS optionenvironment.pathsToLink.)Putting that together with what string interpolation of packages does... well, you kinda just have to look at/know the contents of the package you are referring to:
One of these paths exists, the other doesn't.
Side note: You're looking at the old and mostly abandoned wiki, don't use that. There's an official wiki which is better. This particular article happens to be the same in both, but the old wiki also has tons of outdated and terrible articles like For Beginners or NixOS Woke Invasion.