Re: RFC 52 (v2) List context return from filesystem functions
At 01:26 AM 9/10/00 -0400, Chaim Frenkel wrote: >Would returning the array of status be sufficient? > > @foo = chmod 755, "bar", "baz", "quux"; > # @foo == (0, 2, 0); > >How to convert them to error messages would be a challenge. >Unless passing them through $! would do the trick. > >Hmm, perl -wle '$!=3; print $!' >No such process > >Yup, works. But you still can't say @foo = chmod 755, "bar", "baz", "quux" or die ... because the function will now always return true in a list context. This is only slightly better than returning false iff the function failed. > > > > "PS" == Peter Scott <[EMAIL PROTECTED]> writes: > >PS> At 06:40 AM 8/30/00 -0600, Tom Christiansen wrote: > >> >>My worry is that it seems like this would return > >> >>an empty list on success, so: > >> >> > >> >> @foo = chmod 755, "bar", "baz", "quux" > >> >> or die "Whoops, died on success!"; > >> >> > >> >> > >> >>This seems to me to go contrary to the way perl tends to work... are > >> >>there any other functions (beside system) that do this? Am I > >> >>misunderstanding this? > >> > >> >No, you've hit on the biggest flaw of the RFC. I am less enamored of it > >> >now than I once was. I'd still like to get those individual failure > >> >reasons but I am beginning to think it is not worth the cost. Anyone > got a > >> >brainwave on how to have the cake and eat it too? > >> > >> I'm also concerned about all the separate errnos for each of those > failures. > >PS> where PerlLIO_chmod is defined as chmod on most righteous systems. So it >PS> would be a matter of squirreling away the errno for each bad result. > >PS> I just can't get over the result in the successful case being an empty >PS> list, though. And conversely. Maybe this isn't itching enough to be >worth >PS> scratching this hard, but it seemed like a good direction :-( Anyone got >PS> any brilliant ideas before I withdraw it? > >-- >Chaim FrenkelNonlinear Knowledge, Inc. >[EMAIL PROTECTED] >+1-718-236-0183 -- Peter Scott Pacific Systems Design Technologies
Re: RFC 52 (v2) List context return from filesystem functions
Would returning the array of status be sufficient? @foo = chmod 755, "bar", "baz", "quux"; # @foo == (0, 2, 0); How to convert them to error messages would be a challenge. Unless passing them through $! would do the trick. Hmm, perl -wle '$!=3; print $!' No such process Yup, works. > "PS" == Peter Scott <[EMAIL PROTECTED]> writes: PS> At 06:40 AM 8/30/00 -0600, Tom Christiansen wrote: >> >>My worry is that it seems like this would return >> >>an empty list on success, so: >> >> >> >> @foo = chmod 755, "bar", "baz", "quux" >> >> or die "Whoops, died on success!"; >> >> >> >> >> >>This seems to me to go contrary to the way perl tends to work... are >> >>there any other functions (beside system) that do this? Am I >> >>misunderstanding this? >> >> >No, you've hit on the biggest flaw of the RFC. I am less enamored of it >> >now than I once was. I'd still like to get those individual failure >> >reasons but I am beginning to think it is not worth the cost. Anyone got a >> >brainwave on how to have the cake and eat it too? >> >> I'm also concerned about all the separate errnos for each of those failures. PS> where PerlLIO_chmod is defined as chmod on most righteous systems. So it PS> would be a matter of squirreling away the errno for each bad result. PS> I just can't get over the result in the successful case being an empty PS> list, though. And conversely. Maybe this isn't itching enough to be worth PS> scratching this hard, but it seemed like a good direction :-( Anyone got PS> any brilliant ideas before I withdraw it? -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 52 (v2) List context return from filesystem functions
At 03:35 PM 8/30/00 -0600, Tom Christiansen wrote: > >=head2 Hash Context > > >When the result is assigned to a hash, the list returned could be the names > >of the unsuccessfully modified files and their corresponding C<$!> errors. > >Um, but we don't have hash context. :-( We will :-) RFC 21: >=item 'HASH' > >The subroutine was called in a context where its return value is >assigned to (or treated as???) a hash: > > %hash = func(); > @keys = keys func();# ??? -- Peter Scott Pacific Systems Design Technologies
Re: RFC 52 (v2) List context return from filesystem functions
>=head2 Hash Context >When the result is assigned to a hash, the list returned could be the names >of the unsuccessfully modified files and their corresponding C<$!> errors. Um, but we don't have hash context. :-( --tom
Re: RFC 52 (v2) List context return from filesystem functions
At 06:40 AM 8/30/00 -0600, Tom Christiansen wrote: > >>My worry is that it seems like this would return > >>an empty list on success, so: > >> > >> @foo = chmod 755, "bar", "baz", "quux" > >> or die "Whoops, died on success!"; > >> > >> > >>This seems to me to go contrary to the way perl tends to work... are > >>there any other functions (beside system) that do this? Am I > >>misunderstanding this? > > >No, you've hit on the biggest flaw of the RFC. I am less enamored of it > >now than I once was. I'd still like to get those individual failure > >reasons but I am beginning to think it is not worth the cost. Anyone got a > >brainwave on how to have the cake and eat it too? > >I'm also concerned about all the separate errnos for each of those failures. Me too, which is why RFC 52 says =head2 Hash Context When the result is assigned to a hash, the list returned could be the names of the unsuccessfully modified files and their corresponding C<$!> errors. Currently these functions look like this internally: if (PerlLIO_chmod(name, val)) tot--; where PerlLIO_chmod is defined as chmod on most righteous systems. So it would be a matter of squirreling away the errno for each bad result. I just can't get over the result in the successful case being an empty list, though. And conversely. Maybe this isn't itching enough to be worth scratching this hard, but it seemed like a good direction :-( Anyone got any brilliant ideas before I withdraw it? -- Peter Scott Pacific Systems Design Technologies
Re: RFC 52 (v2) List context return from filesystem functions
>>My worry is that it seems like this would return >>an empty list on success, so: >> >> @foo = chmod 755, "bar", "baz", "quux" >> or die "Whoops, died on success!"; >> >> >>This seems to me to go contrary to the way perl tends to work... are >>there any other functions (beside system) that do this? Am I >>misunderstanding this? >No, you've hit on the biggest flaw of the RFC. I am less enamored of it >now than I once was. I'd still like to get those individual failure >reasons but I am beginning to think it is not worth the cost. Anyone got a >brainwave on how to have the cake and eat it too? I'm also concerned about all the separate errnos for each of those failures. --tom
Re: RFC 52 (v2) List context return from filesystem functions
At 07:39 PM 8/29/00 -0700, Dirk Myers wrote: >Tonight, the role of "Peter Scott" will be read by Perl RFC Librarian : > > > =head1 DESCRIPTION > > > > In a scalar context, the result should remain the same as it is now. It is > > very tempting to make the list context return be the I > > altered files, which is far more intuitive given the scalar context > > behavior; but that is almost certainly not the list the user will be > > interested in and they'd just end up doing the C suggested in the > > docs (Camel III) anyway, which calls the filesystem function once for each > > file. > > >My worry is that it seems like this would return >an empty list on success, so: > > @foo = chmod 755, "bar", "baz", "quux" > or die "Whoops, died on success!"; > > >This seems to me to go contrary to the way perl tends to work... are >there any other functions (beside system) that do this? Am I >misunderstanding this? No, you've hit on the biggest flaw of the RFC. I am less enamored of it now than I once was. I'd still like to get those individual failure reasons but I am beginning to think it is not worth the cost. Anyone got a brainwave on how to have the cake and eat it too? -- Peter Scott Pacific Systems Design Technologies
RFC 52 (v2) List context return from filesystem functions
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
List context return from filesystem functions
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 6 Aug 2000
Last Modified: 29 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 52
Status: Frozen
=head1 ABSTRACT
C, C, and C return the I of successfully
affected files. I suggest that in a list context, they return the I
of the I affected files. Add C to that list as
well, since although it currently only takes one directory name as input,
there is no reason it shouldn't take a list.
=head1 DESCRIPTION
In a scalar context, the result should remain the same as it is now. It is
very tempting to make the list context return be the I
altered files, which is far more intuitive given the scalar context
behavior; but that is almost certainly not the list the user will be
interested in and they'd just end up doing the C suggested in the
docs (Camel III) anyway, which calls the filesystem function once for each
file.
=head2 Hash Context
When the result is assigned to a hash, the list returned could be the names
of the unsuccessfully modified files and their corresponding C<$!> errors.
=head1 IMPLEMENTATION
Examples of use:
# Current behavior: scalar context
chmod 755, grep -d, glob '*' or die "Couldn't chmod dirs"
# List context behavior
warn "Unable to modify $_" for chown $uid, $gid, @files;
# Hash context behavior
%error = rmdir grep -d, glob '*';
warn "Couldn't remove $_: $error{$_}" for keys %error;
It would be nice to include C in this list as well, but there
appears to be no way of doing that without radically changing its
interface, or forcing the I argument to be included, or interpreting
an initial argument that looks like a I to be one. None of those appeal.
=head1 REFERENCES
L
Camel III function list (the entry for C is different from the one
in perl-current at the moment).
