Re: Should a closure-in-a-string get the placeholder parameters from its surroundings?
HaloO,
Carl Mäsak wrote:
I expected this to DWIM today:
$ perl6 -e 'my $cl = { $^name upcased becomes {$^name.uc} }; say $cl(larry)'
...but it doesn't in Rakudo r32938:
too few arguments passed (0) - 1 params expected
...and for understandable (if not good) reasons: the closure inside
the string expects a parameter ($^name), which it isn't getting.
I just want to make sure that I got the problem right. Would
my $cl = { $^name upcased becomes {$^OUTER::name.uc} };
say $cl(larry)
work? The idea is that the embedded closure refers to the strings
$^name. And now the dwimmyness shall make that implicit, right?
Regards, TSa.
--
The unavoidable price of reliability is simplicity -- C.A.R. Hoare
Simplicity does not precede complexity, but follows it. -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
S16: chown, chmod
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.
Re: S16: chown, chmod
On Fri, Nov 21, 2008 at 08:44:51AM -0800, dpuu wrote: : 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. Please feel free to whack on the spec; it's in the pugs repo for that reason. (In fact, we're moving all the specs to the pugs repo so that people can fix things that need fixing without excess interaction with document owners.) Currently, it's called IO.pod, but it'll probably end up somewhere else in the dir structure with a more S16-io-ish name. Larry
Re: S16: chown, chmod
On Nov 21, 9:16 am, [EMAIL PROTECTED] (Larry Wall) wrote:
Please feel free to whack on the spec
OK, working on it.
Question: is it appropriate to P6 lookfeel to have methods on
functions?
The definition of Cchown includes the statement that it's not
available on most system unless you're superuser; and this can be
checked using a POSIX incantation. I was wondering if it would be
reasonable to provide this as a method on the chown function, so that
a user could say:
if chown.is_restricted {
...
}
else {
chown $user, $group == @files
}
Re: S16: chown, chmod
On Fri, Nov 21, 2008 at 09:57:30AM -0800, dpuu wrote:
: On Nov 21, 9:16 am, [EMAIL PROTECTED] (Larry Wall) wrote:
: Please feel free to whack on the spec
:
: OK, working on it.
:
: Question: is it appropriate to P6 lookfeel to have methods on
: functions?
:
: The definition of Cchown includes the statement that it's not
: available on most system unless you're superuser; and this can be
: checked using a POSIX incantation. I was wondering if it would be
: reasonable to provide this as a method on the chown function, so that
: a user could say:
:
: if chown.is_restricted {
: ...
: }
: else {
: chown $user, $group == @files
: }
On security issues where you often can't really determine in advance
whether something will work without trying it, I'd tend to lean more
towards throwing an exception and letting the user trap it, rather
than introducing more interface. But that's just a general guideline.
To answer your actual question, yes, there can certainly be methods
on code objects. But it's not clear to what extent this is a problem
for set theory to get involved with, unless the kernel knows your
set theory and agrees with you. :)
Another problem with the can I do this ask-in-advance approach
is that it opens you up to race conditions, though in this case
it's unlikely (but possible) that another thread would change your
superuser status in between.
Larry
Re: S16: chown, chmod
dpuu wrote:
Question: is it appropriate to P6 lookfeel to have methods on
functions?
I don't think that's such a good idea in this case. If a file is
chown'able is not a property of the chown function, but of the file.
The definition of Cchown includes the statement that it's not
available on most system unless you're superuser; and this can be
checked using a POSIX incantation. I was wondering if it would be
reasonable to provide this as a method on the chown function, so that
a user could say:
if chown.is_restricted {
...
}
else {
chown $user, $group == @files
}
I'd rather go with the try it and fail() if you can't approach, partly
because of race conditions, partly because it's much more reliable in
the presence of extended security models (think of SeLinux for example).
If 'use fatal' is in effect, that dies, if not, you can check the return
value.
For chmod() I could imagine an interface like this:
$file.chmod(:8540);
$file.chmod( :set, :user = :r :x, :group = :r)
# both same as 'chmod 540 $file'
$file.chmod( :modifiy, :other = :!x)
# same as 'chmod o-x $file'
Cheers,
Moritz
--
Moritz Lenz
http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: S16: chown, chmod
On Fri, Nov 21, 2008 at 07:30:08PM +0100, Moritz Lenz wrote: : For chmod() I could imagine an interface like this: : : $file.chmod(:8540); : $file.chmod( :set, :user = :r :x, :group = :r) :# both same as 'chmod 540 $file' : : $file.chmod( :modifiy, :other = :!x) :# same as 'chmod o-x $file' A pair on the left side of = could be construed as a design smell. And I wonder if the set/modify distinction can be better mapped onto assignops somehow... Larry
Re: S16: chown, chmod
Larry Wall wrote: On Fri, Nov 21, 2008 at 07:30:08PM +0100, Moritz Lenz wrote: : For chmod() I could imagine an interface like this: : : $file.chmod(:8540); : $file.chmod( :set, :user = :r :x, :group = :r) :# both same as 'chmod 540 $file' : : $file.chmod( :modifiy, :other = :!x) :# same as 'chmod o-x $file' A pair on the left side of = could be construed as a design smell. oops, I menat 'user = :r' instead of ':user = :r'. I should take the warning serious that 'sudo' prints out the first time you use it ;-) And I wonder if the set/modify distinction can be better mapped onto assignops somehow... maybe as hash slices? $file.permsuserr w x = 1, 0, 1; Still that would become clumsy if you want to change the rights for user, group and other at the same time... Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
multi return values
(Sorry if this dbl-posts, sent it from the wrong account the first time)
Hi all, what's wrong with this code:
use v6;
sub multireturn($x, $y)
{
my $a = $x * 2;
my $b = $y * 2;
return($a, $b);
}
my($a, $b) = multireturn(2, 3);
using:
This is Rakudo Perl 6, revision 32970 built on parrot 0.8.1-devel
for i486-linux-thread-multi.
I get:
Method 'lvalue' not found for invocant of class 'PAST;Stmts'
current instr.: 'parrot;PAST;Compiler;as_post' pc 2924
(src/PAST/Compiler.pir:742)
called from Sub 'parrot;PAST;Compiler;post_children' pc 1783
(src/PAST/Compiler.pir:368)
called from Sub 'parrot;PAST;Compiler;as_post' pc 2060
(src/PAST/Compiler.pir:500)
called from Sub 'parrot;PAST;Compiler;post_children' pc 1783
(src/PAST/Compiler.pir:368)
called from Sub 'parrot;PAST;Compiler;pirop' pc 3061
(src/PAST/Compiler.pir:796)
called from Sub 'parrot;PAST;Compiler;post_children' pc 1783
(src/PAST/Compiler.pir:368)
called from Sub 'parrot;PAST;Compiler;as_post' pc 2408
(src/PAST/Compiler.pir:614)
called from Sub 'parrot;PCT;HLLCompiler;compile' pc 434
(src/PCT/HLLCompiler.pir:303)
called from Sub 'parrot;PCT;HLLCompiler;eval' pc 868
(src/PCT/HLLCompiler.pir:502)
called from Sub 'parrot;PCT;HLLCompiler;evalfiles' pc 1233
(src/PCT/HLLCompiler.pir:676)
called from Sub 'parrot;PCT;HLLCompiler;command_line' pc 1412
(src/PCT/HLLCompiler.pir:765)
called from Sub 'parrot;Perl6;Compiler;main' pc 16160 (perl6.pir:168)
Re: multi return values
Andy Colson wrote:
(Sorry if this dbl-posts, sent it from the wrong account the first time)
Hi all, what's wrong with this code:
use v6;
sub multireturn($x, $y)
{
my $a = $x * 2;
my $b = $y * 2;
return($a, $b);
}
my($a, $b) = multireturn(2, 3);
There's (nearly) nothing wrong with your code, only with the compiler ;-)
Rakudo doesn't support list assignment yet (that's where the error
message comes from), and doesn't support returning values either.
A workaround for now is to use arrays instead.
(The thing that's still wrong with your code is that you need a
whitespace after the 'my', otherwise my(...) should be parsed as a
function call).
Cheers,
Moritz
--
Moritz Lenz
http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: multi return values
Moritz Lenz wrote:
Andy Colson wrote:
(Sorry if this dbl-posts, sent it from the wrong account the first time)
Hi all, what's wrong with this code:
use v6;
sub multireturn($x, $y)
{
my $a = $x * 2;
my $b = $y * 2;
return($a, $b);
}
my($a, $b) = multireturn(2, 3);
There's (nearly) nothing wrong with your code, only with the compiler ;-)
Rakudo doesn't support list assignment yet (that's where the error
message comes from), and doesn't support returning values either.
A workaround for now is to use arrays instead.
You mean like:
my @list = multireturn(2, 3);
That still doesn't work. But its not a big deal... I was just playing
around trying to learn the language.
(The thing that's still wrong with your code is that you need a
whitespace after the 'my', otherwise my(...) should be parsed as a
function call).
OH! Good call, I'd forgotten about that. That's going to take some
getting used to. I assume it'll error out and say method my not found?
Thanks all,
-Andy
Re: S16: chown, chmod
before I attempt to change the POD, would this wording be appropriate?
=item chown
our multi chown (Int $uid, Int $gid, Str|IO [EMAIL PROTECTED])
our multi chown (Str $user, Str $group, Str|IO [EMAIL PROTECTED])
Changes the owner (and/or group) of a list of files. The new
ownership can be specified either as integers or as strings.
If an argument is either a negative integer or undefined then
the ownership (or group membership) of the files will be
unchanged.
A True value will be returned if the operation succeeds,
otherwise the function will Cfail.
The list of files may contain strings and/or filehandles.
Strings are interpretted as filenames. On systems that don't
support Cfchown the use of file handles will result in
failure
When $user or $group are passed as strings, the implementation
will convert this name to the underlying uid/gid using a
function such as getpwnam.
On most systems, you are not allowed to change the ownership of
the file unless you?re the superuser, although you should be
able to change the group to any of your secondary groups. On
insecure systems, these restrictions may be relaxed, but this
is not a portable assumption. On POSIX systems, you can detect
this condition this way:
use POSIX qw(sysconf _PC_CHOWN_RESTRICTED);
$can_chown_giveaway = not sysconf(_PC_CHOWN_RESTRICTED);
=item chmod
our multi chmod( Int $mode, Str|IO [EMAIL PROTECTED] );
our multi chmod( PermissionModifier :$user?, PermissionModifier :
$group?, PermissionModifier :$other?, Str|IO [EMAIL PROTECTED] );
class PermissionModifier {
submethod BUILD ( Bool :$r, Bool :$w, Bool :$x );
...
};
Changes the permissions of a list of files. Returns a true value if
the operation is sucessful on all the files, otherwise Cfail.
The files to modify can be given either as Strings, or FileHandles.
The permissions can be provided as either a single integer,
corresponding
to the underlying Unix permissions mode value, or as named options
using PermissionModifier objects.
A PermissionModifier object is constructed using options similar
to filetest operators. :r, :w and :x (and their inverted forms).
If a given option is not included in the object that the corresponding
permission mode of the file(s) will not be changed.
Examples:
chmod 0o755, @executables;
$mode = '0644'; chmod $mode, 'foo';# !!! sets mode to --
wr-T
$mode = '0o644'; chmod $mode, 'foo'; # this is better
$mode = 0o644; chmod $mode, 'foo'; # this is best
@executables == chmod :user( :x ),# users can execute
these
:group( :x ), # as can group members
:other( :!x :!r :!w ); # but non-group members
cannot
Re: multi return values
Andy Colson wrote:
Moritz Lenz wrote:
Andy Colson wrote:
(Sorry if this dbl-posts, sent it from the wrong account the first time)
Hi all, what's wrong with this code:
use v6;
sub multireturn($x, $y)
{
my $a = $x * 2;
my $b = $y * 2;
return($a, $b);
}
my($a, $b) = multireturn(2, 3);
There's (nearly) nothing wrong with your code, only with the compiler ;-)
Rakudo doesn't support list assignment yet (that's where the error
message comes from), and doesn't support returning values either.
A workaround for now is to use arrays instead.
You mean like:
my @list = multireturn(2, 3);
That, and make multireturn return an array, not a list.
That still doesn't work. But its not a big deal... I was just playing
around trying to learn the language.
(The thing that's still wrong with your code is that you need a
whitespace after the 'my', otherwise my(...) should be parsed as a
function call).
OH! Good call, I'd forgotten about that. That's going to take some
getting used to. I assume it'll error out and say method my not found?
s/method/sub/, but apart from that: yes.
--
Moritz Lenz
http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: Should a closure-in-a-string get the placeholder parameters from its surroundings?
TSa ():
I just want to make sure that I got the problem right. Would
my $cl = { $^name upcased becomes {$^OUTER::name.uc} };
say $cl(larry)
work? The idea is that the embedded closure refers to the strings
$^name. And now the dwimmyness shall make that implicit, right?
I guess that should work. I'm not sure how OUTER:: works together with
the hat twigil, but it has all the hallmarks of avoiding the problem,
yes.
// Carl
Re: multi return values
On Fri, Nov 21, 2008 at 08:16:21PM +0100, Moritz Lenz wrote: Andy Colson wrote: (The thing that's still wrong with your code is that you need a whitespace after the 'my', otherwise my(...) should be parsed as a function call). Also this, I think: return($a, $b); -ryan
Re: Should a closure-in-a-string get the placeholder parameters from its surroundings?
On Fri, Nov 21, 2008 at 09:42:41AM +0100, TSa wrote:
HaloO,
Carl Mäsak wrote:
I expected this to DWIM today:
$ perl6 -e 'my $cl = { $^name upcased becomes {$^name.uc} }; say
$cl(larry)'
...but it doesn't in Rakudo r32938:
too few arguments passed (0) - 1 params expected
...and for understandable (if not good) reasons: the closure inside
the string expects a parameter ($^name), which it isn't getting.
I just want to make sure that I got the problem right. Would
my $cl = { $^name upcased becomes {$^OUTER::name.uc} };
say $cl(larry)
work? The idea is that the embedded closure refers to the strings
$^name. And now the dwimmyness shall make that implicit, right?
That seems a bit odd to me, but if $^name merely causes a signature
to be generated that declares $name as a (lexically scope) parameter,
then it's just:
my $cl = { $^name upcased becomes {$name.uc} };
But perhaps for clarity you would just write:
my $cl = { $^name upcased becomes $^name.uc() };
Larry
Re: multi return values
Ryan (), Moritz (), Andy (): (The thing that's still wrong with your code is that you need a whitespace after the 'my', otherwise my(...) should be parsed as a function call). Also this, I think: return($a, $b); ...except that that _is_ a function call. // Carl
Re: S16: chown, chmod
On Fri, Nov 21, 2008 at 11:46:48AM -0800, dpuu wrote:
: before I attempt to change the POD, would this wording be appropriate?
It's a good first whack, though we might want to think about making
it a little less P5ish/Unixish in changing a list of files, and rely
instead of one of P6's distribution mechanisms, such as hypers or maps:
my @status = @files».io».chmod($mode);
my @status = map { .io.chmod($mode) }, @files;
my @status = (for @files { .io.chmod($mode) });
The advantage of this approach is that you don't get complete failure
if only one of the files failed to change. Any you could even do it
in parallel:
my @status = hyper map { .io.chmod($mode) }, @files
though it's possible your sysadmin will complain about what you're
doing with the disk drive heads. :)
Of course, along with the methods we could also provide the old-fashioned
functions so that someone can write a FAQ telling people not to use them. :)
It's also possible that «*.c *.h».io.chmod($mode) should do something
dwimmy, given «...» is defined as shell quoting. And maybe IO
objects themselves can track multiple files, similar to how we can
turn @*ARGS into a single abstract file handle.
Larry
[svn:perl6-synopsis] r14608 - doc/trunk/design/syn
Author: larry Date: Fri Nov 21 15:40:52 2008 New Revision: 14608 Modified: doc/trunk/design/syn/S06.pod Log: typo Modified: doc/trunk/design/syn/S06.pod == --- doc/trunk/design/syn/S06.pod(original) +++ doc/trunk/design/syn/S06.podFri Nov 21 15:40:52 2008 @@ -1531,7 +1531,7 @@ Placeholders may also be used in method bodies that have no formal signature. Since the placeholder declares a parameter variable without the twigil, -the twigil is needed only on the first occurence of the variable within +the twigil is needed only on the first occurrence of the variable within the block. Subsequent mentions of that variable may omit the twigil. Within an internal nested block the twigil Imust be omitted, since it would wrongly attach to the inner block.
multi return values
Hi all, what's wrong with this code:
use v6;
sub multireturn($x, $y)
{
my $a = $x * 2;
my $b = $y * 2;
return($a, $b);
}
my($a, $b) = multireturn(2, 3);
using:
This is Rakudo Perl 6, revision 32970 built on parrot 0.8.1-devel
for i486-linux-thread-multi.
I get:
Method 'lvalue' not found for invocant of class 'PAST;Stmts'
current instr.: 'parrot;PAST;Compiler;as_post' pc 2924
(src/PAST/Compiler.pir:742)
called from Sub 'parrot;PAST;Compiler;post_children' pc 1783
(src/PAST/Compiler.pir:368)
called from Sub 'parrot;PAST;Compiler;as_post' pc 2060
(src/PAST/Compiler.pir:500)
called from Sub 'parrot;PAST;Compiler;post_children' pc 1783
(src/PAST/Compiler.pir:368)
called from Sub 'parrot;PAST;Compiler;pirop' pc 3061
(src/PAST/Compiler.pir:796)
called from Sub 'parrot;PAST;Compiler;post_children' pc 1783
(src/PAST/Compiler.pir:368)
called from Sub 'parrot;PAST;Compiler;as_post' pc 2408
(src/PAST/Compiler.pir:614)
called from Sub 'parrot;PCT;HLLCompiler;compile' pc 434
(src/PCT/HLLCompiler.pir:303)
called from Sub 'parrot;PCT;HLLCompiler;eval' pc 868
(src/PCT/HLLCompiler.pir:502)
called from Sub 'parrot;PCT;HLLCompiler;evalfiles' pc 1233
(src/PCT/HLLCompiler.pir:676)
called from Sub 'parrot;PCT;HLLCompiler;command_line' pc 1412
(src/PCT/HLLCompiler.pir:765)
called from Sub 'parrot;Perl6;Compiler;main' pc 16160 (perl6.pir:168)
Re: S16: chown, chmod
The restriction of chown to the superuser is a property of the OS, not the
files. The example from the pod is:
use POSIX qw(sysconf _PC_CHOWN_RESTRICTED);
my $can_chown_giveaway = not sysconf(_PC_CHOWN_RESTRICTED);
Thinking about it, perhaps that means that it's a method on $*OS.
The use of filetest operators as a way to specify the desired chmod modes
seems good, but I'm not sure how to specify the signature. I can imagine:
our multi chmod ( Int $mode, [EMAIL PROTECTED] );
our multi chmod ( PermissionModifier :$owner,
PermissionModifier :$group,
PermissionModifier :$other,
[EMAIL PROTECTED]);
but I'm not sure how to define that a PermissionModifer object can be created
as a chain of positive and negative options so that these would work:
@exe_files == chmod :owner( :x ), :group( :x ), :other( :!x );
@my_files == chmod :owner( :r :w ), :group( :r :!w ), :other( :!r :!w );
There would be a little less line-noise if these could be passed as:
@my_files == chmod :ownerr w :groupr !w :other!r !w;
From: Moritz Lenz [EMAIL PROTECTED]
To: dpuu [EMAIL PROTECTED]
Cc: perl6-language@perl.org
Sent: Friday, November 21, 2008 10:30:08 AM
Subject: Re: S16: chown, chmod
dpuu wrote:
Question: is it appropriate to P6 lookfeel to have methods on
functions?
I don't think that's such a good idea in this case. If a file is
chown'able is not a property of the chown function, but of the file.
The definition of Cchown includes the statement that it's not
available on most system unless you're superuser; and this can be
checked using a POSIX incantation. I was wondering if it would be
reasonable to provide this as a method on the chown function, so that
a user could say:
if chown.is_restricted {
...
}
else {
chown $user, $group == @files
}
I'd rather go with the try it and fail() if you can't approach, partly
because of race conditions, partly because it's much more reliable in
the presence of extended security models (think of SeLinux for example).
If 'use fatal' is in effect, that dies, if not, you can check the return
value.
For chmod() I could imagine an interface like this:
$file.chmod(:8540);
$file.chmod( :set, :user = :r :x, :group = :r)
# both same as 'chmod 540 $file'
$file.chmod( :modifiy, :other = :!x)
# same as 'chmod o-x $file'
Cheers,
Moritz
--
Moritz Lenz
http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: S16: chown, chmod
Larry Wall wrote: On Fri, Nov 21, 2008 at 11:46:48AM -0800, dpuu wrote: : before I attempt to change the POD, would this wording be appropriate? It's a good first whack, though we might want to think about making it a little less P5ish/Unixish in changing a list of files, and rely instead of one of P6's distribution mechanisms, such as hypers or maps: my @status = @files».io».chmod($mode); [...] I think that can be accomplished by adding corresponding methods to the IO class. I don't have write permissions for the pugs repository, so I've attached the file, including the addition of chmod and chown methods to the IO class. =encoding utf8 =head1 Title DRAFT: Synopsis 16: IPC / IO / Signals =head1 Version Author:Largely, the authors of the related Perl 5 docs. Maintainer:Larry Wall [EMAIL PROTECTED] Contributions: Mark Stosberg [EMAIL PROTECTED] Date: 12 Sep 2006 Last Modified: 1 May 2007 Version: 17 This is a draft document. Many of these functions will work as in Perl 5, except we're trying to rationalize everything into packages. For now you can assume most of the important functions will automatically be in the * namespace. However, with IO operations in particular, many of them are really methods on an IO handle, and if there is a corresponding global function, it's merely an exported version of the method. As a starting point, you can help by finding the official Perl 5 documentation for these functions and copying it here. =head1 Filehandles, files, and directories =over 4 =item IO ~~ :X X:rX:wX:xX:oX:RX:WX:XX:OX:eX:zX:sX:fX:dX:lX:p X:SX:bX:cX:tX:uX:gX:kX:TX:BX:MX:AX:C =item EXPR ~~ :X $file.:X $file ~~ :X A file test, where X is one of the letters listed below. This unary operator takes one argument, either a filename or a filehandle, and tests the associated file to see if something is true about it. A Pair used as a pattern is treated as a file test. :r File is readable by effective uid/gid. :w File is writable by effective uid/gid. :x File is executable by effective uid/gid. :o File is owned by effective uid. :R File is readable by real uid/gid. :W File is writable by real uid/gid. :X File is executable by real uid/gid. :O File is owned by real uid. :e File exists. :z File has zero size (is empty). :s File has nonzero size (returns size in bytes). :f File is a plain file. :d File is a directory. :l File is a symbolic link. :p File is a named pipe (FIFO), or Filehandle is a pipe. :S File is a socket. :b File is a block special file. :c File is a character special file. :t Filehandle is opened to a tty. :u File has setuid bit set. :g File has setgid bit set. :k File has sticky bit set. :T File is an ASCII text file (heuristic guess). :B File is a binary file (opposite of :T). :M Script start time minus file modification time, in days. :A Same for access time. :C Same for inode change time (Unix, may differ for other platforms) The interpretation of the file permission operators C:r, C:R, C:w, C:W, C:x, and C:X is by default based solely on the mode of the file and the uids and gids of the user. There may be other reasons you can't actually read, write, or execute the file. Such reasons may be for example network filesystem access controls, ACLs (access control lists), read-only filesystems, and unrecognized executable formats. Also note that, for the superuser on the local filesystems, the C:r, C:R, C:w, and C:W tests always return 1, and C:x and C:X return 1 if any execute bit is set in the mode. Scripts run by the superuser may thus need to do a stat() to determine the actual mode of the file, or temporarily set their effective uid to something else. If you are using ACLs, there is a pragma called Cfiletest that may produce more accurate results than the bare stat() mode bits. When under the Cuse filetest 'access' the above-mentioned filetests will test whether the permission can (not) be granted using the access() family of system calls. Also note that the C:x and C:X may under this pragma return true even if there are no execute permission bits set (nor any extra execute permission ACLs). This strangeness is due to the underlying system calls' definitions. Read the documentation for the Cfiletest pragma for more information. The C:T and C:B switches work as follows. The first block or so of the file is examined for odd characters such as strange control codes or characters with the high bit set. If too many strange characters (30%) are found, it's a C:B file; otherwise it's a C:T file. Also, any file containing null in the first block is considered a binary file. If C:T or C:B is used on a filehandle, the current IO buffer is examined rather than the first block. Both C:T and C:B return true on a null file, or a file at EOF when testing a filehandle. Because you have
