I know that bitwise and logical assignment-or are different, but it
seems to me that logical is what's wanted in this context anyway.
Ed
I don't get that here. I get Syntax OK with perl v5.8.0 on Debian.
>test.pl syntax OK
>$ cat -n test.pl | sed -e '1,25d'
> 26 sub wanted {
> 27 my ($dev,$ino,$mode,$nlink,$uid,$gid);
> 28
> 29 (($dev,$ino,$mode,$nlink,$uid,$gid) = lstat($_)) &&
> 30 !($File::Find::prune |= ($dev != $File::Find::topdev)) &&
> 31 print("$name\n");
> 32 }
> 33
>$ perl -pi -e 's#prune \|#prune ||#' test.pl
>$ perl -c test.pl
>test.pl syntax OK
>
>I know that bitwise and logical assignment-or are different, but it
>seems to me that logical is what's wanted in this context anyway.
I disagree - $File::Find::prune may need to be updated with the result
of ($dev != $File::Find::topdev) which is what |= will do whereas ||
will not affect $File::Find::prune.
The !($File::Find::prune |= ($dev != $File::Find::topdev)) section
will only return true if $File::Find::prune is False which means that
the subbracket must be False too. So,
(($dev,$ino,$mode,$nlink,$uid,$gid) = lstat($_)); should always
succeed assuming that $_ is valid for lstat,
!($File::Find::prune |= ($dev != $File::Find::topdev)); can be
re-written as:
$File::Find::prune |= ($dev != $File::Find::topdev);
if (!$File::Find::prune) {...
and print("$name\n"); should always succeed but due to the ordering
of the conjunction, will only be executed if nothing before it has
gone False. So you should be able to rewrite it:
if (($dev,$ino,$mode,$nlink,$uid,$gid) = lstat($_)) {
$File::Find::prune |= ($dev != $File::Find::topdev);
if (!$File::Find::prune) {
print ("$name\n");
}
}
}
That should work out to be the same and I can't see there being
problems with that, though tbh, I can't see why the perl interpreter
had a problem with the original.
Matthew
--
Matthew Sackman
Imperial College
Ignore the above. I totally agree that it should be ||= and not |= - I
really should be less asleep when posting. Sorry!
Matthew
This warning is new for 5.8.1, so I suspect the subject is wrong.
>>I know that bitwise and logical assignment-or are different, but it
>>seems to me that logical is what's wanted in this context anyway.
>
>I disagree - $File::Find::prune may need to be updated with the result
>of ($dev != $File::Find::topdev) which is what |= will do whereas ||
>will not affect $File::Find::prune.
In this case, I think |= and ||= are functionally equivalent.
>I can't see why the perl interpreter
>had a problem with the original.
It was a bug (having the warning for |=, &= and ^= instead of only |,
^, and &). The warning should only have been given for |, &, or ^
where one of the operands was an unparenthesized numeric compare (<,
<=, ==, >=, >, !=, <=>). It was fixed shortly after RC2.
No, I'm using the "5.8.0" from Redhat 9 (I compiled the RH9 source rpm
under RH7.3). RH may have backported unreleased code from the 5.8.1
tree.
>>I can't see why the perl interpreter had a problem with the
>>original.
>
> It was a bug (having the warning for |=, &= and ^= instead of only |,
> ^, and &). The warning should only have been given for |, &, or ^
> where one of the operands was an unparenthesized numeric compare (<,
> <=, ==, >=, >, !=, <=>). It was fixed shortly after RC2.
OK, good. I've changed the few scripts that used find2perl output to
use the logical or assignment, since it's functionaly equivalent and
doesn't generate the warning, and since the 5.8.1 release will have
the fix, I guess that's that.
Thanks.
Ed