command-not-found gives wrong suggestion for dig

[Kreyren]

Dig is currently packaged as a part of bind package which is not available:

[kreyren@leonid:~]$ dig
The program 'dig' is not in your PATH. You can make it available in an
ephemeral shell by typing:
  nix-shell -p bind

[kreyren@leonid:~]$ nix-shell -p bind

[nix-shell:~]$ dig
The program 'dig' is not in your PATH. You can make it available in an
ephemeral shell by typing:
  nix-shell -p bind

Having it packaged as a part of bind is also unexpected as it's used to check DNS records on systems that doesn't have bind running.

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

[kreyren@leonid:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.10.43, NixOS, 21.05.961.1f91fd10406 (Okapi)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.12`
 - channels(root): `"nixos-21.05.961.1f91fd10406"`
 - channels(kreyren): `"home-manager-21.05, master, nixos-21.05.1226.f77036342e2"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos

[Kreyren]

CC @peti @globin

[7c6f434c]

***@***.***:~]$ nix-shell -p bind

[nix-shell:~]$ dig The program 'dig' is not in your PATH. You can make it available in an ephemeral shell by typing: nix-shell -p bind

That's actually a bug with command-not-found handler. Actually the bind package is a multiple-output package, and bind.dnsutils is the output containing dig (so « nix-shell -p bind.dnsutils » is what you need).

Having it packaged as a part of bind is also unexpected as it's used to check DNS records on systems without bind running.

It is completely expected as dig is shipped as a part of bind source distribution. You do not need bind _running_ locally for dig, though. Moreover, you can indeed download the dnsutils output of the bind package from the binary cache without downloading the main output with the bind server binary.

[roberth]

Regarding command-not-found:

We do have aliases dig and dnsutils, but perhaps the problem is:

nix-repl> dig.meta.name 
"bind-9.16.16"

Maybe we could overrideAttrs to change the meta.name, but if dig uses meta.name in the first place, that'd be the root cause. It should use the attribute. All I could find just now is that it uses programs.sqlite from the channel, for which I haven't found docs yet. Considering that it relates to the channels feature, it's probably quite broken.

We could also switch to nix-index if that solves the problem. #39789

[Kreyren]

You do not need bind running locally for dig @7c6f434c

I am aware of that, but the concern is storage space on a system with limited memory like the one i use.

[roberth]

The dnsutils output (which is what the dig attribute points to) does reference the default output.

$ nix why-depends /nix/store/h1f78bsfigsfi4d3w2wlgir4nsl5dp3x-bind-9.16.16-dnsutils /nix/store/2i1w0fhbfvjdvs0rgzycal6sbvpzhpfz-bind-9.16.16
/nix/store/h1f78bsfigsfi4d3w2wlgir4nsl5dp3x-bind-9.16.16-dnsutils
└───bin/delv: …an be specified....../nix/store/2i1w0fhbfvjdvs0rgzycal6sbvpzhpfz-bind-9.16.16/etc/bind.keys..Inv…
    → /nix/store/2i1w0fhbfvjdvs0rgzycal6sbvpzhpfz-bind-9.16.16

$ strings /nix/store/h1f78bsfigsfi4d3w2wlgir4nsl5dp3x-bind-9.16.16-dnsutils/bin/delv | grep 2i1w0fh 
/nix/store/2i1w0fhbfvjdvs0rgzycal6sbvpzhpfz-bind-9.16.16/etc/bind.keys

So it seems to be a matter of avoiding or removing that reference. Or placing it in its own output I guess.

[asbachb]

I'm falling in that trap quite often as well.

[7c6f434c]

delv into its own output sounds good to me

[SuperSandro2000]

I think the dig top-level alias should have solved this problem

[cyounkins]

The problematic behavior described in the OP of the command-not-found handler suggesting nix-shell -p bind when dig is not installed, and that command not installing dig, is still present today on unstable:

craig@nixos-unstable ~> dig
The program 'dig' is not in your PATH. You can make it available in an
ephemeral shell by typing:
  nix-shell -p bind
craig@nixos-unstable ~ [127]> nix-shell -p bind
...
[nix-shell:~]$ dig
The program 'dig' is not in your PATH. You can make it available in an
ephemeral shell by typing:
  nix-shell -p bind

I frankly don't follow the discussion above about multi-outputs. Maybe this issue should be moved/refiled? This issue's name could be improved, maybe "command-not-found gives wrong suggestion for dig". I suggest re-opening the issue.

If anyone finds this via search, you can use nix-shell -p dig (not bind) to get dig.

[roberth]

I agree with @cyounkins.
Regarding multi-outputs, dig depends on bind, but bind is only 1.3MB. If someone considers this a problem, please open an issue or PR.

command-not-found suggests installing bind instead of dig. This seems to be a bigger problem.

[binarydigitz01]

I have a similar problem, but with gitk. Gitk reports to install git-doc, but it's in gitFull.

[YellowOnion]

Still broken, command-not-found is pretty shit script it has some hard coded stuff that break it on non-standard systems, which is annoying.

[SuperSandro2000]

No surprise to me since no one fixed it.

command-not-found is pretty shit script it has some hard coded stuff that break it on non-standard systems, which is annoying.

That's the curse of a none standard system: Things might break because they where not being considered. Without more information that is the most useful answer I can give you to your problem.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/confusing-errors-suggestions/29473/2