lib.showOption doesn't quote attributes with periods

[lilyball]

Describe the bug

lib.showOption doesn't quote attributes containing periods, so the output is identical for e.g. [ "a.b" ] and [ "a" "b" ].

Steps To Reproduce

Steps to reproduce the behavior:

1. lib.showOption [ "a" "b.c" "d" ]

Expected behavior

It should return ''a."b.c".d''. Instead it returns ''a.b.c.d''.

Additional context

It also doesn't include quotes for components containing other non-attribute-valid chars such as spaces. This is more of an aesthetic issue as a.b c.d is unambiguous, though it bothers me. Not quoting components containing periods is a correctness issue.

Right now it calls lib.strings.escapeNixString and checks if the output is identical to "${part}". It does have comments explaining that it allows options starting with digits, as well as placeholders like * and <name>. This means it can't just use lib.strings.escapeNixIdentifier. But it could still be a bit smarter about this, inlining lib.strings.escapeNixIdentifier and then modifying the regex to allow these additional values.

My suggestion for such a regex is something like "([^[:punct:][:space:]]|['_<>*-])+". This way most punctuation and all whitespace will cause quoting but it will still allow * and <name>. Alternatively it could be more conservative and only quote for spaces and periods, but it seems more reasonable to me to quote for arbitrary punctuation as well.

Notify maintainers

@jtojnar @grahamc @LnL7 @infinisil

Metadata

❯ nix run nixpkgs#nix-info -- -m
 - system: `"aarch64-darwin"`
 - host os: `Darwin 21.2.0, macOS 12.1`
 - multi-user?: `yes`
 - sandbox: `relaxed`
 - version: `nix-env (Nix) 2.5.1`
 - channels(lily): `"darwin, home-manager"`
 - channels(root): `"nixpkgs-21.11pre330171.92204897f3d"`
 - nixpkgs: `/etc/nix/inputs/nixpkgs`

[lilyball]

Note that my suggested regex takes advantage of the fact that builtins.match doesn't seem to be unicode-aware, in that builtins.match "[^[:punct:]]+" "«" succeeds. This seems like a bug, so if Nix ever gains unicode support here, this might have to be modified to explicitly allow either common placeholder chars or just all non-ASCII chars.

[infinisil]

This relates to #82461 (comment) and #85241