[29279] in Perl-Users-Digest
Perl-Users Digest, Issue: 523 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Jun 16 09:09:52 2007
Date: Sat, 16 Jun 2007 06:09:08 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 16 Jun 2007 Volume: 11 Number: 523
Today's topics:
Re: Best error handling mechanism? <njus@larshaugseth.com>
Re: perl and php <bik.mido@tiscalinet.it>
Re: Perl Bug??? <bik.mido@tiscalinet.it>
Re: Perl Bug??? <bik.mido@tiscalinet.it>
Re: Perl Bug??? <bik.mido@tiscalinet.it>
Re: Perl script to identify corrupt mbox messages? <rvtol+news@isolution.nl>
Re: Perl script to identify corrupt mbox messages? <tuxedo@mailinator.net>
Re: Perl script to identify corrupt mbox messages? <tuxedo@mailinator.net>
Re: Perl script to identify corrupt mbox messages? <hjp-usenet2@hjp.at>
Re: Perl script to identify corrupt mbox messages? <tuxedo@mailinator.net>
Re: perl vs C for CGI <hjp-usenet2@hjp.at>
Re: perl vs C for CGI <hjp-usenet2@hjp.at>
Re: Useless use of array element in void context <bik.mido@tiscalinet.it>
Re: Useless use of array element in void context <bik.mido@tiscalinet.it>
Re: Useless use of array element in void context <bik.mido@tiscalinet.it>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 16 Jun 2007 11:35:26 +0200
From: Lars Haugseth <njus@larshaugseth.com>
Subject: Re: Best error handling mechanism?
Message-Id: <878xaks0m9.fsf@unreal.larshaugseth.com>
* Michele Dondi <bik.mido@tiscalinet.it> wrote:
>
> On Mon, 4 Jun 2007 20:13:12 -0500, Rob Hoelz <hoelz@wisc.edu> wrote:
>
>>clear conclusion yet: What form of error handling is best in Perl?
>
> The best way is not to make errors at all. Corporate policies should
> always include a clause to that effect.
assert($USER_IS_INFALLIBLE, 'Go away!');
--
Lars Haugseth
"If anyone disagrees with anything I say, I am quite prepared not only to
retract it, but also to deny under oath that I ever said it." -Tom Lehrer
------------------------------
Date: Sat, 16 Jun 2007 14:57:50 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: perl and php
Message-Id: <2in773lj8gl07sj1vhoon9857862i7tmfm@4ax.com>
On Thu, 14 Jun 2007 13:36:12 -0700, krakle@visto.com wrote:
>towards beginners. They are wrong. PHP was created with the internet
>in mind where as Perl wasn't. In my opinion there's only one way to
The internet or the web?
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Sat, 16 Jun 2007 15:00:44 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Perl Bug???
Message-Id: <kmn7739k1hidoskebcn7s0hdh2r7jf2tt3@4ax.com>
On Thu, 14 Jun 2007 10:33:03 -0700, Paul Lalli <mritty@gmail.com>
wrote:
>While you're correct that the OP's assumption was wrong, this example
>does not demonstrate that. Here, you're only printing $_ within the
>loop. If the OP had been correct and $_ was in fact a copy of the
>values of @a, the output would be the same. The example you meant to
>type was:
>perl -le'@a=qw/foo bar/; $_ x= 2 for @a; print for @a;'
(or
perl -le'@a=qw/foo bar/; $_ x= 2 for @a; print "@a"'
)
You're right of course.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Sat, 16 Jun 2007 15:03:52 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Perl Bug???
Message-Id: <kqn773t2vc1f19u2g1hmhnoskuu96t9t9c@4ax.com>
On Fri, 15 Jun 2007 08:15:21 -0700, krakle@visto.com wrote:
>> I asked
>> whether it's more likely that there's a new bug THAT THE OP JUST
>> HAPPENED TO FIND or that the OP made a mistake. I did not ANYWHERE
>> say it was unlikely there was a bug in Perl.
>
>By your 20 year example you imply (perhaps not intentionally) that
>it's unlikely to find a bug in Perl because it's been around for 20
>years. I only pointed out there has been several releases with in that
>time span all having their own bugs unique to the previous versions...
>It's an evolving languaging.. Bugs are expected Paul.
Oh, C'mon, you're *very partially* right: what he wrote *may* have
been misunderstood. Not a good reason to whine about it. I, for one,
understood the original text the way he later stated it was meant.
Let's go on to more interesting stuff, please!
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Sat, 16 Jun 2007 15:06:33 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Perl Bug???
Message-Id: <svn773tob5bsau4vpcor9sgni6hugjubki@4ax.com>
On Fri, 15 Jun 2007 17:25:00 GMT, Bart Lateur <bart.lateur@pandora.be>
wrote:
>>POSSIBLE, yes. LIKELY, for a newbie to Perl? No.
>
>Uh, why not?
>
>Whenever my 2 year old is at the keyboard of my computer, he almost
>immediately succeeds in making it do stuff I didn't know it could do
>(like putting my computer in standby mode), just by hitting a few
>unexpected keys.
Hehe, my girlfriend recently told me she had a five years old or so
kid thumping at her portable pc and he managed to change the wireless
settings, which she had been unable to! Isn't this terrific?
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Sat, 16 Jun 2007 11:57:00 +0200
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: Perl script to identify corrupt mbox messages?
Message-Id: <f50jiu.110.1@news.isolution.nl>
Tuxedo schreef:
> Dr.Ruud:
>> Use formail to repair the file, is why I suggested it.
>
> This interesting utility is indeed is on my Linux system. But
> having neither a remote idea what error(s) the original mailbox may
> contain, nor being familiar with formail, it is a bit complicated to
> guess how to best process it. Nevertheless, I tried the following
> examples:
>
> formail -ds <my_crappy_mbox >>reinvigorated_mbox
>
> ... this certainly made some changes, in fact, 10 or so additional
> messages appear in the Mozilla index which did not show up earlier,
> including a couple without a valid sender which are now listed by
> Mozilla as from foo@bar, but which appear to be file fragments, i.e.
> not real mail.
I assume that you want to find out at which message the problem starts
and at which line in the mbox file that is, and start fixing from there.
Be careful not to introduce extra problemes with the move of the mbox
file from the Windows to the Linux system (maybe you should do a
dos2unix on the file, and then maybe you shouldn't, formail will DWIM).
You can use formail together with procmail to convert from mbox to
maildir format (the one file per message in new/ cur/ tmp/ structure)
like this:
formail -defYz \
-s procmail -m VERBOSE=yes DEFAULT="test_maildir/" /dev/null <
crappy.mbx
(the "test_maildir/" will be created in the user's $HOME, include
MAILDIR="/some/path" to redirect)
The "-defYz" just lists all interesting options for this case, change at
will, see man formail.
From the maildir structure you should be able to find out at which
message the split up breaks.
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: Sat, 16 Jun 2007 13:01:01 +0200
From: Tuxedo <tuxedo@mailinator.net>
Subject: Re: Perl script to identify corrupt mbox messages?
Message-Id: <f50ftd$93v$01$1@news.t-online.com>
Mumia W. wrote:
> On 06/16/2007 02:24 AM, Tuxedo wrote:
> > [...]
> > formail -ds <my_crappy_mbox >>reinvigorated_mbox
> >
> > .... this certainly made some changes, in fact, 10 or so additional
> > messages appear in the Mozilla index which did not show up earlier,
> > including a couple without a valid sender which are now listed by
> > Mozilla as from foo@bar, but which appear to be file fragments, i.e. not
> > real mail.
> >
> > Most of the 3000+ messages, however, still do not show up in Mozilla.
> >
> > So I tried: ...
> > formail -zds <my_crappy_mbox >>reinvigorated_mbox
> > ... but this made the file no more readable in Mozilla than the previous
> > try.
> >
> > and ...
> > formail -rds <my_crappy_mbox >>reinvigorated_mbox
> > ... but with the same result as the former try.
> >
> > Naturally I removed the generated (.msf) index files as well as
> > terminated the Mozilla application between the tries, in case something
> > would get cached otherwise.
> >
> > The Mozilla application simply appears to be choking on the mbox while
> > building the index. The progress bar is helplessly trying to move
> > forward, but then falls back, then forward a bit, and then back again,
> > until it finally gives up. In other words, the graphical indicator at
> > the bottom right of the application, which is meant to indicate the
> > progress of building the index, never reaches its maximum.
> >
> > Perhaps the mbox contains some very odd characters, maybe part of some
> > attachment, which causes Mozilla but not other mail clients to choke.
> > Perhaps it is the result of some malformatted mail circulating via
> > zoombie machines, Outlook and whatever, that affects Mozilla on multiple
> > platforms.
> >
>
> Research the problem with the help of this website:
> http://kb.mozillazine.org/
>
> In particular, this article may (or may not) be of help:
> http://kb.mozillazine.org/Inbox_stays_blank
>
> Here is a script that, might improve things a little bit:
>
> use strict;
> use warnings;
> require FileHandle;
> require Email::Folder;
> require Date::Parse;
> require POSIX;
> Date::Parse->import('str2time');
> POSIX->import('ctime');
>
> my $file = glob('~/tmp/mozmail/OldTests');
> my $outfile = 'output.mbox';
>
> my $fh = FileHandle->new($outfile, '>') or die("Stop: $!");
> my $folder = Email::Folder->new($file);
>
> my $count = 0;
> while (my $msg = $folder->next_message) {
> my $date = $msg->header('Date');
> $date = ctime(str2time($date)); chomp $date;
> $fh->print("From - $date\n");
> $fh->print($msg->as_string() . "\n");
> $count++;
> }
> print "There are $count messages in the folder.\n";
>
> $fh->close;
>
> Email::Folder and Date::Parse are modules you can download from CPAN.
> The other modules are standard parts of Perl. You should change $file
> and $outfile as appropriate. You shouldn't modify the original mailbox
> file.
>
> Probably, you'll not need the script. Things should improve after you've
> deleted the .msf (index) file and closed an reopened Mozilla.
>
> (Followups set to alt.fan.mozilla)
>
Excellent! However, the problem does not want to be so easily solved. It
was no problem getting the above script running with the 2 up-to-date and
non-standard modules, and after having saved the script, as fixbox.pl, I
sucessfully tested it on a small mbox file containing only 3 messages.
However, with the real file, and when using a 2GH notebook with 512MB
memory and Perl 5.8.7, munching through the approximately 150MB mbox, the
above script (or the shell) returned: "Out of Memory!". The resulting
'output.mbox' file remained empty.
Personally, I'm not a fan of Mozilla mail, and looking a bit closer, I
could not find a solution to this particular issue on kb.mozillazine.org,
either. The problematic mailbox is someone's else. I'm seriously
contemplating telling them to: 1) abandon Windows, 2) Mozilla mail.
------------------------------
Date: Sat, 16 Jun 2007 13:38:05 +0200
From: Tuxedo <tuxedo@mailinator.net>
Subject: Re: Perl script to identify corrupt mbox messages?
Message-Id: <f50i2t$2i3$02$1@news.t-online.com>
Dr.Ruud wrote:
> Tuxedo schreef:
> > Dr.Ruud:
>
> >> Use formail to repair the file, is why I suggested it.
> >
> > This interesting utility is indeed is on my Linux system. But
> > having neither a remote idea what error(s) the original mailbox may
> > contain, nor being familiar with formail, it is a bit complicated to
> > guess how to best process it. Nevertheless, I tried the following
> > examples:
> >
> > formail -ds <my_crappy_mbox >>reinvigorated_mbox
> >
> > ... this certainly made some changes, in fact, 10 or so additional
> > messages appear in the Mozilla index which did not show up earlier,
> > including a couple without a valid sender which are now listed by
> > Mozilla as from foo@bar, but which appear to be file fragments, i.e.
> > not real mail.
>
> I assume that you want to find out at which message the problem starts
> and at which line in the mbox file that is, and start fixing from there.
Yes. If I only knew. I tried to split it up, delete sections and so on,
only to find the problem appearing in many sections, but not knowing
exactly where. The file is just too big to locate the error manually.
>
> Be careful not to introduce extra problemes with the move of the mbox
> file from the Windows to the Linux system (maybe you should do a
> dos2unix on the file, and then maybe you shouldn't, formail will DWIM).
>
> You can use formail together with procmail to convert from mbox to
> maildir format (the one file per message in new/ cur/ tmp/ structure)
> like this:
>
> formail -defYz \
> -s procmail -m VERBOSE=yes DEFAULT="test_maildir/" /dev/null <
> crappy.mbx
>
> (the "test_maildir/" will be created in the user's $HOME, include
> MAILDIR="/some/path" to redirect)
>
> The "-defYz" just lists all interesting options for this case, change at
> will, see man formail.
>
> From the maildir structure you should be able to find out at which
> message the split up breaks.
>
Many thanks for all the tips, especially about formail. However, in this
particular case, I will leave the problematic mbox to rest, because it is
my ambition not to deal with anything from the Windows user space. In
realising it is probably a 99% Mozilla bug, my solution became to simply
transfer the file to a good old BSD mail server and let the file owner
access it's content via Neomail - an exceptional perl program which handles
mbox pop-mail via a no-frills web interface. I just tested that and the
full mbox was read, as fine as it was in MUTT or another native *nix mailer.
Sooner or later Mozilla developers will likely fix the bug, whatever it is.
------------------------------
Date: Sat, 16 Jun 2007 13:53:30 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Perl script to identify corrupt mbox messages?
Message-Id: <slrnf77jpq.223.hjp-usenet2@zeno.hjp.at>
On 2007-06-16 09:57, Tuxedo <tuxedo@mailinator.net> wrote:
> Peter J. Holzer wrote:
>
>> On 2007-06-14 14:06, Tuxedo <tuxedo@mailinator.net> wrote:
>> > I'm trying to repair a gigantic mbox file that appears to have been
>> > corrupted in that it displays only 17 of the most recent and total 3087
>> > messages contained in the actual file.
>> >
>> > The mail application used is Mozilla on Windows.
>> [...]
>> > The same mbox works entirely when viewed in for example MUTT or the
>> > standard KDE mail client, Kmail.
>>
>> Have you tried copying all messages to a new mbox file with mutt or
>> kmail and then reading the new mbox file with Mozilla?
>
> Yes that was the first thing I tried, but it didn't work :-(
>
> I assume therefore that that some crummy characters are contained within
> one or more messages, or/and in headers, which somehow cause the Mozilla to
> choke, and so whatever conversion is done is simply carried forward.
That sounds likely. I think the best way to identify the message(s) with
the crummy characters is to split your big mail boy into a small number
(at most 10 or so) of smaller mboxes. You can do that with formail or a
perl (or awk) script or any text editor you find convenient. Then try to open
each mbox. For each mbox which Mozilla cannot open, split it again,
until you little mboxes with one bad message in each. Then you can check
what they have in common.
> The file, coming from Windows appeared to have been in DOS format. I've
> un-DOS'ed it, awk-splitted each individual message, re-combed with the
> proper empty line, followed by a ^From occurance, but without luck.
>
> The file is around 150 MB and I wish I could post the entire mbox here, but
> its not mine to distribute, and it surely contains much private
> communication. Maybe there is a way to encode the entire content into
> Mozilla safe characters as this is obviously a Mozilla bug.
Parsing each message with MIME::Parser and then printing it out again
may help. But I would hate to do that for a whole folder of 3000
messages. It may or may not work and you still don't know the problem
afterwards. Try to find the bad message(s) and convert only these. Then
you also have a test case for bugreport for mozilla.
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
------------------------------
Date: Sat, 16 Jun 2007 14:32:06 +0200
From: Tuxedo <tuxedo@mailinator.net>
Subject: Re: Perl script to identify corrupt mbox messages?
Message-Id: <f50l86$9g5$02$1@news.t-online.com>
Peter J. Holzer wrote:
> On 2007-06-16 09:57, Tuxedo <tuxedo@mailinator.net> wrote:
> > Peter J. Holzer wrote:
> >
> >> On 2007-06-14 14:06, Tuxedo <tuxedo@mailinator.net> wrote:
> >> > I'm trying to repair a gigantic mbox file that appears to have been
> >> > corrupted in that it displays only 17 of the most recent and total
> >> > 3087 messages contained in the actual file.
> >> >
> >> > The mail application used is Mozilla on Windows.
> >> [...]
> >> > The same mbox works entirely when viewed in for example MUTT or the
> >> > standard KDE mail client, Kmail.
> >>
> >> Have you tried copying all messages to a new mbox file with mutt or
> >> kmail and then reading the new mbox file with Mozilla?
> >
> > Yes that was the first thing I tried, but it didn't work :-(
> >
> > I assume therefore that that some crummy characters are contained within
> > one or more messages, or/and in headers, which somehow cause the Mozilla
> > to choke, and so whatever conversion is done is simply carried forward.
>
> That sounds likely. I think the best way to identify the message(s) with
> the crummy characters is to split your big mail boy into a small number
> (at most 10 or so) of smaller mboxes. You can do that with formail or a
> perl (or awk) script or any text editor you find convenient. Then try to
> open each mbox. For each mbox which Mozilla cannot open, split it again,
> until you little mboxes with one bad message in each. Then you can check
> what they have in common.
>
>
> > The file, coming from Windows appeared to have been in DOS format. I've
> > un-DOS'ed it, awk-splitted each individual message, re-combed with the
> > proper empty line, followed by a ^From occurance, but without luck.
> >
> > The file is around 150 MB and I wish I could post the entire mbox here,
> > but its not mine to distribute, and it surely contains much private
> > communication. Maybe there is a way to encode the entire content into
> > Mozilla safe characters as this is obviously a Mozilla bug.
>
> Parsing each message with MIME::Parser and then printing it out again
> may help. But I would hate to do that for a whole folder of 3000
> messages. It may or may not work and you still don't know the problem
> afterwards. Try to find the bad message(s) and convert only these. Then
> you also have a test case for bugreport for mozilla.
That is certainly the best solution, but unfortunately it would set back to
much time. I would however consider submitting the entire file, given
permission by the file owner and without making it public, to someone who
could identify, bugreport and potentially fix the problem.
------------------------------
Date: Sat, 16 Jun 2007 13:23:16 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: perl vs C for CGI
Message-Id: <slrnf77i14.223.hjp-usenet2@zeno.hjp.at>
On 2007-06-15 20:36, Dr.Ruud <rvtol+news@isolution.nl> wrote:
> Peter J. Holzer schreef:
>> A string written as a here document always
>> contains simple "\n" characters as line endings regardless of whether
>> the source file contained CRLFs or LF and whether it's executed on
>> Windows or Unix.
>
>
> And so it should.
I concede that may sometimes be convenient. I'm less convinced that it
*should* do that. On unix, line endings are indicated by a single byte
0x0A. There is little reason to expect that the sequence of bytes
0000000 $ s = < < E O S ; \r \n L i n
0000020 e 1 \r \n L i n e 2 \r \n E O S
0000040 \r \n
in the *source code* of a script should be parsed into
$s = "Line 1\nLine 2\n";
on Unix. Why are the \r characters suppressed? Perl doesn't suppress
other control characters in string literals.
> That \n is a metacharacter (line separator) that,
> depending on platform and binmode, can become CR+LF again when written
> out.
Right. But it it does that regardless of platform (and of course
binmode) while compiling the script. So on Unix, if you explicitely
include literal CRLFs in your string literals (which you shouldn't,
imho), they are silently converted to LFs.
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
------------------------------
Date: Sat, 16 Jun 2007 13:34:16 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: perl vs C for CGI
Message-Id: <slrnf77ilo.223.hjp-usenet2@zeno.hjp.at>
On 2007-06-15 23:31, Tad McClellan <tadmc@seesig.invalid> wrote:
> Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
>> On 2007-06-14 17:11, Michele Dondi <bik.mido@tiscalinet.it> wrote:
>>> On Wed, 13 Jun 2007 14:35:50 +0200, "Peter J. Holzer"
>>><hjp-usenet2@hjp.at> wrote:
>>>>If you don't convert the *script* (as opposed to print statements within
>>>>the script), apache probably can't even start the script because the
>>>>linux kernel will try to invoke "/usr/bin/perl\r" which doesn't exist.
>>>
>>> BTW: I've always wondered... how 'bout HERE docs? Are they portable
>>> across platforms or is the line ending deemed to be that of the
>>> script.
>>
>> To my surprise they are portable at least between Unix and Windows. Perl
>> seems to automatically detect the line endings
No, I was mistaken. It doesn't detect anything, it just ignores CR if it
is immediately followed by LF. So you can have a script where some lines
are terminated by LF and some by CRLF and perl won't care.
>> and convert them to \x{0A} at compile time. A string written as a
>> here document always contains simple "\n" characters as line endings
>> regardless of whether the source file contained CRLFs or LF and
>> whether it's executed on Windows or Unix.
>
>
> See the "PERLIO" section in perlrun.pod:
>
> On Win32 the default in this release is "unix crlf".
I wasn't surprised about the way perl works on windows, I was surprised
about how it works on Unix. And I was talking about the way perl is
reading/parsing source code, not about any I/O a script performs. (The
implicit crlf layer for reading source has existed long before the IO
layers: I've tested that with perl 5.005_03 on Linux).
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
------------------------------
Date: Sat, 16 Jun 2007 14:31:21 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Useless use of array element in void context
Message-Id: <1rl77397buplqu0lork0aj1p04r4uca0sk@4ax.com>
On Sun, 10 Jun 2007 22:16:34 -0700, Marek
<mstep@podiuminternational.org> wrote:
> if (@old_line_num_to_comp == @out_line_num_to_comp) { ... }
>
>But apparently here is the same problem, the comma operator is working
>silently over the two arrays. This is tricky and I am wondering, why
No comma operator. Something different happening there; it checks
whether @old_line_num_to_comp and @out_line_num_to_comp have the same
number of elements.
>Larry Wall or somebody else from you gurus is not inventing an
>operator, just to compare two arrays, one element after the other :-)
Well surprising as it may be, it turns out that "this kinda things" is
not required that often. And in *many cases*, but by all means *not*
in all of them, a simple
if ("@old_line_num_to_comp" eq "@out_line_num_to_comp") { ... }
would do it.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Sat, 16 Jun 2007 14:37:54 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Useless use of array element in void context
Message-Id: <r3m773h1n9db32prgd9680es8oar8utl9k@4ax.com>
On Mon, 11 Jun 2007 01:48:09 -0700, Marek
<mstep@podiuminternational.org> wrote:
>Thank you Peter!
Very polite of you to thank, but please quote *some* relevant context
from the posts you reply to, and put your comments below those
portions: this is considered good practice and greately aids
communication. You'll notice that most of us do, here.
>of course! Little question to you more: you suggested:
>
> my $same = 1;
> $same = $same && $old_line[$_] == $out_line[$_] for (2 .. 6);
> if ($same) { ... }
>
>I changed to:
>
> my $same = 1;
> $same = $old_line[$_] == $out_line[$_] for (2 .. 6);
> if ($same) { ... }
>
>because I did not understand the use of the second "$same" after "="
>Is it really needed?
You're confused by the absence of parentheses. Ask perl:
: gin:~ [14:35:40]$ perl -MO=Deparse,-p -e '$same = $same && $old_line[$_] == $out_line[$_] for (2 .. 6)'
: ;
: ($same = ($same && ($old_line[$_] == $out_line[$_]))) foreach (2 .. 6);
: -e syntax OK
You were probably thinking along the lines of
($same = $same) && ($old_line[$_] == $out_line[$_]))
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Sat, 16 Jun 2007 14:39:15 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Useless use of array element in void context
Message-Id: <2em77357g0lhi2jsqcaobdmj32bgb8leb9@4ax.com>
On Tue, 12 Jun 2007 01:01:33 +0200, "Dr.Ruud"
<rvtol+news@isolution.nl> wrote:
>> Affijn:
>
>Heheh, "Affijn" is a Dutch variant of the French "enfin".
And "enfin" for us poor (Italian and most) English speaker is... "the
end"?
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 523
**************************************
