Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

find2perl output causes warnings on 5.8.0

9 views
Skip to first unread message

Ed Blackman

unread,
Jul 27, 2003, 2:43:04 PM7/27/03
to
$ find2perl /etc -xdev -print > test.pl
$ perl -c test.pl
Possible precedence problem on bitwise | operator at test.pl line 30.
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.

Ed

Matthew Sackman

unread,
Jul 27, 2003, 7:01:54 PM7/27/03
to
On Sun, 27 Jul 2003 14:43:04 -0400, Ed Blackman wrote:
>$ find2perl /etc -xdev -print > test.pl
>$ perl -c test.pl
>Possible precedence problem on bitwise | operator at test.pl line 30.

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

Matthew Sackman

unread,
Jul 28, 2003, 2:10:15 AM7/28/03
to
On Sun, 27 Jul 2003 23:01:54 +0000 (UTC), Matthew Sackman wrote:
>On Sun, 27 Jul 2003 14:43:04 -0400, Ed Blackman wrote:
>>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.

Ignore the above. I totally agree that it should be ||= and not |= - I
really should be less asleep when posting. Sorry!

Matthew

Yitzchak Scott-Thoennes

unread,
Jul 28, 2003, 4:17:37 AM7/28/03
to
On Sun, 27 Jul 2003 23:01:54 +0000 (UTC), ms...@doc.ic.ac.uk wrote:
>On Sun, 27 Jul 2003 14:43:04 -0400, Ed Blackman wrote:
>>$ find2perl /etc -xdev -print > test.pl
>>$ perl -c test.pl
>>Possible precedence problem on bitwise | operator at test.pl line 30.
>
>I don't get that here. I get Syntax OK with perl v5.8.0 on Debian.

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.

Ed Blackman

unread,
Jul 28, 2003, 1:10:51 PM7/28/03
to
In article <hwNJ/gzkgyS...@efn.org>, Yitzchak Scott-Thoennes wrote:
> On Sun, 27 Jul 2003 23:01:54 +0000 (UTC), ms...@doc.ic.ac.uk wrote:
>>On Sun, 27 Jul 2003 14:43:04 -0400, Ed Blackman wrote:
>>>Possible precedence problem on bitwise | operator at test.pl line 30.
>>
>>I don't get that here. I get Syntax OK with perl v5.8.0 on Debian.
>
> This warning is new for 5.8.1, so I suspect the subject is wrong.

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

0 new messages