Reading S16, I was struck by the lack of abstraction over the
underlying Unix API for chown and chmod. Nothing wrong with having the
existing functions lying about in a module that people can "use Unix"
for; but I do feel that the variants in the global namespace should be
more user-friendly.
chown, for example, accepts uid and gid only as integers, -1 meaning
"don't change". To my mind, perl6 should have a variant of chown
strings for uid and gid (and lookup the integers automatically). And
it should accept "undef" as a synonym for "-1".
BTW, the Synopsis fails to define the return value of chown (except
that it's an integer). The underlying Unix API returns success/error
status: The p6 wrapper should be defined to return the appropriate
Failure object (so that { use fatal } will work).
A similar situation exists for "chmod", except it is harder to fix.
The fact that it needs a discussion of "don't say 0644" has a pungent
aroma. A list of integers might solve that. Or perhaps something with
named args: { chmod :u(6), :g(4), :o(4) <== @files }.
But this still isn't as flexible (nor readable) as a Unix command
line. The command line allows you to say "add execute permission"
without specifying any of the other bits. A bunch of methods might the
the right approach, but that would fall foul of the same issue that
filetest operators have: Do we really want to add all these methods to
the Str class?
The return value of chmod is defined, in the synopsis, as the number
of files modified. The underlying Unix API returns success/fail. As
with chown, I feel that we should return a Failure object to represent
failures.
One final point is that not all systems use the Unix security model.
The primary P6 abstraction should probably reflect that fact. The
synopsis does make brief mention of "use filetest" from P5 for
interacting with ACLs, but then punts to the P5 definition/
implementation.
