snicat: installs generic binary name (sc)

[eclairevoyant]

Describe the bug

sc is a generic binary name likely to cause collisions in $out/bin

Steps To Reproduce

n/a

Expected behavior

Leave binary named as snicat

Notify maintainers

@felixalbrigtsen

---

Add a 👍 reaction to issues you find important.

[felixalbrigtsen]

I am not really sure how this type of "collission" is usually handled in nixpkgs, but have some thoughts, in descending order of importance:

• The snicat README consistently uses sc
• The go release configuration specifies the binary name sc
• No other application in nixpkgs seem to supply an executable called sc, from checking nix-locate --regex bin/sc$
• Snicat approximates nc from the netcat-openbsd-package, and the goal is to be as quick and frictionless as possible, for example when solving a CTF challenge.

Is there one or more specific (potential) packages you have in mind, that might collide with sc?
If so, I can absolutely agree with you on the basis that this is a pretty obscure package and something else might be more important, but if not, I don't see a reason to take the canonical name of sc and arbitrarily change it to something less convenient, just out of principle.

[eclairevoyant]

I saw the mv command in snicat's source and assumed it was renamed in nixpkgs:

nixpkgs/pkgs/by-name/sn/snicat/package.nix

Line 31 in 971ea0a

mv $out/bin/snicat $out/bin/sc

but you're right, it's sc in the upstream docs, not just a nixpkgs thing.

Here's my take: I created this issue because a two-letter name is pretty highly likely for collision, and I found an example too - I just reviewed #320821 (unmerged) which also has the binary sc. If a user puts both packages into the same package set, they would presumably collide, and one of the packages becomes unusable.

I don't think it makes sense to say either is more popular and has "rights" to the name. If anything, smartcat is pretty obscure too; both projects have <100 stars and <10 forks. I made my original suggestion in the interest of avoiding some future confusion for the end users, and my original assumption that we were renaming snicat just for nixpkgs.

If it's primarily a convenience naming, people can use security.wrappers (on NixOS) or use one of the trivial builders (on any system) to effectively rename one of the binaries. Or maybe we just leave it as is, and users use lib.hiPrio on the package that should "win" out, or use lib.getExe pkgname in scripts. Hopefully this issue is a decent signpost if we go with the latter option.