Re: UNIX commands: chmod
* 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
> .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 MScMARKOV Solutions
[EMAIL PROTECTED] [EMAIL PROTECTED]
http://Mark.Overmeer.net http://solutions.overmeer.net
Re: UNIX commands: chmod
On 3/26/06, Mark Overmeer <[EMAIL PROTECTED]> wrote: > > 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. [...] > Of course, besides that you may implement a version which accepts a list, > but that is certainly not needed except for perl5 compatibility... If we look at Perl just as a high-level language than you might be right, and I really liked the object being returned idea, but I think Perl should also keep serving the system administrators with much simpler needs. Perl was quite a good replacement to shell scripting but there are several places where writing shell commands is sill much simpler. It would be nice if the this end of the programming spectrum - writing one liners and small scripts - would be also further strengthened. Gabor
Re: UNIX commands: chmod
* Gabor Szabo ([EMAIL PROTECTED]) [060326 19:26]: > On 3/26/06, Mark Overmeer <[EMAIL PROTECTED]> wrote: > > > 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. > > If we look at Perl just as a high-level language than you might be right, > and I really liked the object being returned idea, but I think Perl should > also keep serving the system administrators with much simpler needs. "Simple tasks must be simple, and complex ones must be possible" Once upon a time, handling file(name)s was simple. But not anymore: os-specifics and character-sets are a pain. One of Perl's targets is to be platform independent: with only a few letters more you can achieve that wrt file- and directory handling. -- MarkOv [EMAIL PROTECTED] [EMAIL PROTECTED] http://Mark.Overmeer.net http://solutions.overmeer.net
Re: UNIX commands: chmod
On Sat, Mar 25, 2006 at 01:22:18PM +0200, Gabor Szabo wrote:
: On 3/25/06, Nicholas Clark <[EMAIL PROTECTED]> wrote:
: > On Sat, Mar 25, 2006 at 12:58:30PM +0200, Gabor Szabo wrote:
: > > 4) "filename".chmod(MODE) should also work and I guess
: > > .chmod(MODE) should also work on those 3 files
: >
: > That seems to be implying a chmod method on all strings, and all lists.
: > Assuming chmod doesn't get special favours, how many methods would it need
: > to implement all the existing builtins like this?
:
: Not that I understand the problem here but "filename".slurp seems to work.
: Did it get special favour?
I suspect that can work simply by failing-over from SMD to MMD.
On the original question, I see it more as a junctional issue.
Assuming we have only chmod($,$), this sould autothread:
unless chmod MODE, all(@files) -> $oops {
???;
profit();
}
Larry
Re: UNIX commands: chmod
On Sun, Mar 26, 2006 at 02:40:03PM -0800, Larry Wall wrote:
: On the original question, I see it more as a junctional issue.
: Assuming we have only chmod($,$), this sould autothread:
:
: unless chmod MODE, all(@files) -> $oops {
: ???;
: profit();
: }
Except that junctional logic is allowed to fail as soon as it can be
falsified, so if some set of file is not chmodable, you'd randomly
get an error message for one of them. You really need something that
drives it to completion, like hyperop, or a pipe, or a list operator.
(Which is sort of what we already have, but the return status of such a
list operator should probably be a list, or something that does list.)
On the other hand, if it's only the boolean context that wants
to short-circuit a junction, maybe binding to $oops drives the
autothreading to completion somehow. (Or asking for a list value
from $oops, more likely).
Larry
Re: UNIX commands: chmod
* Larry Wall ([EMAIL PROTECTED]) [060327 01:07]:
> On Sun, Mar 26, 2006 at 02:40:03PM -0800, Larry Wall wrote:
> : On the original question, I see it more as a junctional issue.
> : Assuming we have only chmod($,$), this sould autothread:
> :
> : unless chmod MODE, all(@files) -> $oops {
> : ???;
> : profit();
> : }
>
> Except that junctional logic is allowed to fail as soon as it can be
> falsified,
$oops being the filename or the error? To produce a good error
report, you need both.
To be compatible with Perl5, the order of the @files must be preserved.
Is it really worth it to design a new syntax to avoid the use of 'for'
with chmod? In more characters as well?
--
MarkOv
Mark Overmeer MScMARKOV Solutions
[EMAIL PROTECTED] [EMAIL PROTECTED]
http://Mark.Overmeer.net http://solutions.overmeer.net
Re: UNIX commands: chmod
Mark Overmeer wrote:
> * Larry Wall ([EMAIL PROTECTED]) [060327 01:07]:
> > On Sun, Mar 26, 2006 at 02:40:03PM -0800, Larry Wall wrote:
> > : On the original question, I see it more as a junctional issue.
> > : Assuming we have only chmod($,$), this sould autothread:
> > :
> > : unless chmod MODE, all(@files) -> $oops {
> > : ???;
> > : profit();
> > : }
> >
> > Except that junctional logic is allowed to fail as soon as it can be
> > falsified,
>
> $oops being the filename or the error? To produce a good error
> report, you need both.
>
> To be compatible with Perl5, the order of the @files must be preserved.
>
> Is it really worth it to design a new syntax to avoid the use of 'for'
> with chmod? In more characters as well?
What about this:
unless all(chmod MODE, [EMAIL PROTECTED]) -> $oops {
???;
profit();
}
Hyperoperate on the list in order to convert a "($$) returns $"
signature into a de facto "($@) returns @" signature, then feed the
resulting list into a junctive function to collapse it into a single
truth value.
--
Jonathan "Dataweaver" Lang
