* Gabor Szabo ([EMAIL PROTECTED]) [060325 09:58]:
> So we had chmod in Perl5, I would like to make sure it works in
> Perl6 as well with slight modifications.
> LIST = chmod MODE, LIST
My feeling is that this function design is a bit of a mistake. Usually,
one perl function maps on one operating-system function, but in this case
it doesn't: it simulated the common chmod(1) user command.
User commands have a different purpose and application than program
calls. If chmod complains to a used about "no permission", the used
can understand that, filter out the files and handle accordingly.
However, applications should have a thorough error-handling.
> 1) In list context it would return the names of the files successfully
> changed .
> In scalar context it should be the number of files successfully changed
> as it is in Perl5
Perl's chmod can better simulate chmod(2) than chmod(1), and see the latter
as something derived. If anything is returned, it should be an
error-object, not the file name.
So, the "real" core chmod is sub chmod($mode, $file)
Of course, besides that you may implement a version which accepts a list,
but that is certainly not needed except for perl5 compatibility...
> 2) In addition to the octet representation it would also be ready to receive
> the unix style mode representation which is string
> one or more of the letters ugoa,
> one of the symbols +-=
> one or more of the letters rwxXstugo
would be nice... but platform independent?
> 3) While some of the modes are UNIX specific, it would be nice to find similar
> modes in other operating system and do the right thing there too.
> e.g. "all" in UNIX would map to "Everyone" in Windows/NTFS
Then we come into the dangerous dungeons of File::Spec. It would be so
nice to redesign that:
my Dir $top .= new($root);
my Dir $etc = $top.cd('etc');
my Stat $s = $etc.file('passwd').stat;
for $cwd.glob('*.c') -> .chmod('a+w');
my File $f .= unix('/etc/passwd');
When it is easy to manupulate dirs and files as objects, than we can hide
all these OS-specific calls about directories, paths, modes and stuff
in the objects, outside the core language.
> 4) "filename".chmod(MODE) should also work and I guess
> <file1 file2 file3>.chmod(MODE) should also work on those 3 files
Should all methods which accept a string as argument have an alternative method
in the string class? Why then in this case?
Mark Overmeer MSc MARKOV Solutions
[EMAIL PROTECTED] [EMAIL PROTECTED]