* 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');
  $etc.chmod('g+w');
  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?
-- 
Regards,

               MarkOv

------------------------------------------------------------------------
       Mark Overmeer MSc                                MARKOV Solutions
       [EMAIL PROTECTED]                          [EMAIL PROTECTED]
http://Mark.Overmeer.net                   http://solutions.overmeer.net

Reply via email to