populate: cope with unusual names and paths

Names and paths with characters that mean something to shells, to find,
or in URLs get handled as what they are, or refused:

- Pruning, and removing state that sources don't need anymore, list
  entries with find instead of a loop reading names, which strips blanks
  at the ends of names and splits names at newlines.  So an entry named
  "trail " gets pruned instead of reported as pruned and left.
- Pruning doesn't make entries writable before removing them, which
  would change the mode of files elsewhere that are hard links to files
  therein.
- Source names are portable file names: letters, digits, and ._-, not
  starting with -.  nixpkgs' writers accept nothing else in the names of
  the scripts populating the sources, which contain the source names, and
  fail with an assertion that doesn't mention the source.
- Paths get percent-encoded where they go into URLs for Nix, which
  refuses blanks there and takes ? and # for delimiters.
- rsync gets the target path protected from the target's shell
  (--protect-args), which expands wildcards in it otherwise: a file source
  delivered to /var/src/a?c ends up in /var/src/abc if that exists.

A safety scenario deploys every kind of state to a target path with a
blank, wildcards, #, and %.  An edge case prunes entries with blanks at
the ends of their names, with a newline, and with wildcards, and the
scenario pruning links also prunes hard links to a read-only file
outside, and lists what's left in the C locale, where ls sorts .populate
first.  The scenario with unusual source names also draws inputs from a
source named self.

0 files changed, 0 insertions, 0 deletions