[29447] in Perl-Users-Digest
Perl-Users Digest, Issue: 691 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jul 27 11:09:44 2007
Date: Fri, 27 Jul 2007 08:09:11 -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 Fri, 27 Jul 2007 Volume: 11 Number: 691
Today's topics:
Re: @arts <tadmc@seesig.invalid>
Re: Compiling perl on Solaris 10...bread crumb trail an <tony_curtis32@yahoo.com>
Re: ERR: 13: Missing right $] anno4000@radom.zrz.tu-berlin.de
Re: ERR: 13: Missing right $] <bik.mido@tiscalinet.it>
Re: I am giving up perl because of assholes on clpm -- <zentara@highstream.net>
Re: I am giving up perl because of assholes on clpm -- <bugbear@trim_papermule.co.uk_trim>
Re: Math <jluis@escomposlinux.org>
Re: Objects/Structures in Perl <olson_ord@yahoo.it>
Re: Perl with DBI <sbryce@scottbryce.com>
Re: pid from startet process <hjp-usenet2@hjp.at>
Re: pid from startet process <hjp-usenet2@hjp.at>
Re: pid from startet process <josef.moellers@fujitsu-siemens.com>
Reading from stdin then launching a program that reads <stefano.sabatini-lala@poste.it>
Re: regular expression match on the fly <bik.mido@tiscalinet.it>
Re: standard setup for scripts <tadmc@seesig.invalid>
Re: standard setup for scripts <noreply@gunnar.cc>
Re: String::CRC crc function returns incorrect result, <none@none.c0m>
Re: String::CRC crc function returns incorrect result, <sisyphus1@nomail.afraid.org>
Version for Script? <g4173c@motorola.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 27 Jul 2007 10:54:56 GMT
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: @arts
Message-Id: <slrnfajjh8.p85.tadmc@tadmc30.sbcglobal.net>
Mike Hartsough <michaellhartsough@sbcglobal.net> wrote:
> Tad McClellan wrote:
>> Mike Hartsough <michaellhartsough@sbcglobal.net> wrote:
>>
>>
>> > I saw no proof offered by Michele Dondi nor Tad McClellan, who
>> > decided to join in rather than point out the Posting Guidelines,
>>
>>
>> Specifically because the Jsut troll deserves no better.
>>
>> (ie. this poster has a history here)
>
> So you're saying you have the right to accuse anyone of being this "Jsut
> troll" without any evidence to prove it?
No.
And that did not happen in this thread as it slipped up yet again
and revealed itself.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Fri, 27 Jul 2007 10:26:14 -0400
From: Tony Curtis <tony_curtis32@yahoo.com>
Subject: Re: Compiling perl on Solaris 10...bread crumb trail anyone?
Message-Id: <f8cva6$46v$1@knot.queensu.ca>
Aftermath Fan wrote:
> I need to compile perl on Solaris 10 (sparc v9 platform). Yes, I know
> Solaris comes with a version of perl, but /usr/bin/perl on solaris 10
> is (surprisingly) not compiled with full 64-bit flags:
>
> use64bitint=define use64bitall=undef uselongdouble=undef
>
> The specific limitation is that it can't address more than 4GB of
> memory, which is symptomatic of a 32-bit binary. I would like to
> address more.
>
> Unfortunately, my attempts to compile perl on Solaris 10 (using the
> gcc in /usr/sfw/bin) have all been met with:
>
>
> Use which C compiler? [gcc -B/usr/ccs/bin/]
> Assembler messages:
> Error: invalid architecture -xarch=generic64
> Uh-oh, the C compiler 'gcc -B/usr/ccs/bin/' doesn't seem to be
> working.
That's a flag for the Studio compilers; gcc doesn't understand it. Why
not use Studio instead? More tuned...
http://developers.sun.com/sunstudio/downloads/
hth
t
------------------------------
Date: 27 Jul 2007 10:13:11 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: ERR: 13: Missing right $]
Message-Id: <5gtupnF3httr6U1@mid.dfncis.de>
pp <pp@mm.org> wrote in comp.lang.perl.misc:
> Peter Makholm wrote:
> > pp <pp@mm.org> writes:
> >
> >> Can anyone tell me how to fix this error in perl?
> >> The above error point to the following line or perl code.
> >>
> >> %UN_MONTH= map { lc($MONTH[$_]), $_ } 0..$#MONTH ; # look up by
> >> month name
> >
> > Works here:
> >
> > makholm@makholm:~$ perl -w -MData::Dumper -le '@MONTH = qw(Jan Feb Mar
> Apr Maj Jun); %UN_MONTH= map { lc($MONTH[$_]), $_ } 0..$#MONTH ; print
> Dumper \%UN_MONTH;'
> > $VAR1 = {
> > 'feb' => 1,
> > 'jan' => 0,
> > 'jun' => 5,
> > 'mar' => 2,
> > 'apr' => 3,
> > 'maj' => 4
> > };
> >
> > makholm@makholm:~$
> >
> > //Makholm
> hi
> thanks for the prompt reply.
> that error is generated by the script downloaded from the following web
> site:
> http://www.jmarshall.com/tools/cgiproxy/
>
> Are you able to get it working in yoru system?
Why don't you ask the author?
I, for one, would not run a script downloaded from a random site on
the web. Also, *if* you found a bug, telling the author would help
everyone who is using the script. Getting someone from clpm to fix
it for you would help only you.
The error message in the subject is not a Perl message. Did you use
Perl to run the script?
Anno
------------------------------
Date: Fri, 27 Jul 2007 11:49:08 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: ERR: 13: Missing right $]
Message-Id: <5mfja35hsbkv6646k9qce9vnks11nuroj8@4ax.com>
On Fri, 27 Jul 2007 19:18:09 +1000, pp <pp@mm.org> wrote:
>Subject: ERR: 13: Missing right $]
How strange! Actually that doesn't look like a Perl error at all, if
it's intended to be verbatim.
>Can anyone tell me how to fix this error in perl?
>The above error point to the following line or perl code.
Sometimes errors are not reported to the *exact* they happen.
>%UN_MONTH= map { lc($MONTH[$_]), $_ } 0..$#MONTH ; # look up by month
This line of Perl code is syntactically fine, and I can't even see how
could it fail at runtime.
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: Fri, 27 Jul 2007 07:26:05 -0400
From: zentara <zentara@highstream.net>
Subject: Re: I am giving up perl because of assholes on clpm -- switching to Python
Message-Id: <gblja3plfdlr9192tmh11fure11bkssflm@4ax.com>
On Thu, 26 Jul 2007 09:38:34 -0700, Paul Boddie <paul@boddie.org.uk>
wrote:
>zentara wrote:
>>
>> This is where the big boys play, you have to be able to be able to
>> scuffle and take punishment if you are wrong or unduly ignorant.
>> You also need to squash somehow who attacks you, when you
>> know you are right.
>
>Where is this again? High school?
No, it's the prison's exercise yard. (The prison being capitalism :-) )
If you sit on the bleachers and watch (i.e. lurk this newsgroup to
learn), there is no problem. But step out onto the field and enter
the play, be prepared for some open-hand slapping and verbal abuse,
especially if you don't read the Faq, do prior research, or just want a
handout.
>I can understand people getting
>impatient with repeated incoherent one-line messages of the form "can
>u give me teh codes thanx", but you'd show off your community a bit
>better by entertaining even the most naive questions - people have to
>start somewhere, you know.
perl beginners maillist is the place to go for that. Excellent answers
are given, with a "cherry on top".
You can understand that when these gurus get the same question, for the
500th time, they start screaming "search groups.google" or "read the
Faq".
>In comp.lang.perl.misc? It seems to me that the "big boys" in this
>case have an inflated sense of their own bigness.
>Paul
Maybe, but that karma will eventually play out against them.
>
>P.S. Although it's nice to point to beginner resources, too, let us
>avoid comp.lang.python becoming some kind of linux-kernel ego trip
>where anyone who has stuck around has an interest in perpetuating a
>hostile atmosphere.
Well, I'm just pointing out that she shouldn't give up on Perl because
of this newsgroup. I seldom post here myself, mostly because I know I'm
usually outgunned by the regulars.
I've always got the impression that this newsgroup was about arguing the
fine points of Perl, not explaining the basics to newbies.
zentara
--
I'm not really a human, but I play one on earth.
http://zentara.net/japh.html
------------------------------
Date: Fri, 27 Jul 2007 11:45:06 +0100
From: bugbear <bugbear@trim_papermule.co.uk_trim>
Subject: Re: I am giving up perl because of assholes on clpm -- switching to Python
Message-Id: <46a9ccb2$0$1592$ed2619ec@ptn-nntp-reader02.plus.net>
David Formosa (aka ? the Platypus) wrote:
>
> I have found that often the prerequisite steps for asking a question,
> working out exactly what behavour I desire, the behavour I'm seeing
> and then isolating the code to a minimum required to express the
> problem, often helps me solve the problem before I even have to post.
>
yes indeed. Good practice; it EITHER
helps you find your own solution, or
helps other help you.
It's all good.
BugBear
------------------------------
Date: Fri, 27 Jul 2007 13:26:26 +0100
From: José Luis Pérez Diez <jluis@escomposlinux.org>
Subject: Re: Math
Message-Id: <VA.00000bd6.0051dd27@escomposlinux.org>
In article <slrnfahqf9.i1m.hjp-usenet2@zeno.hjp.at>, Peter J. Holzer
wrote:
> Nope. Converting a binary number of a given precision to decimal and
> back to binary is always possible without loss[0]. The problem seems to
> be that perl uses only 15 decimal digits, while it would need 16 to
> cover the 53 bits of mantissa (I think 16 should be enough, but I
> haven't considered all cases - maybe there are some where 17 are
> required).
>
perl -Mbignum=a,100 -e 'my $numero=0; for (0..53) {$numero+= 1/2**$_}
;$numero =~ s/0*$//g;print length($numero)."\n$numero\n";'
55
1.99999999999999988897769753748434595763683319091796875
------------------------------
Date: Fri, 27 Jul 2007 05:16:18 -0700
From: "O. Olson" <olson_ord@yahoo.it>
Subject: Re: Objects/Structures in Perl
Message-Id: <1185538578.705639.248900@w3g2000hsg.googlegroups.com>
On Jul 26, 11:48 pm, Keith Keller <kkeller-use...@wombat.san-
francisco.ca.us> wrote:
>
> It's probably easier to simply create each hashref the way you want it:
>
> my $curr_time={
> HOUR => 1,
> MINUTE => 2,
> SECOND => 3,
>
> };
>
> my $next_midnight={
> HOUR => 4,
> MINUTE => 5,
> SECOND => 6,
>
> };
>
I don't think I can do this, because I am going to be using this as a
variable. I think I would try Jens solution below.
> Some more unrelated comments:
>
> > # This function would print the time variable passed on to it, without
> > adding a new line character to it
> > sub printTime()
>
> You have (), which strictly speaking defines printTime as a function
> that takes no arguments. You don't see any errors because calling it
> like you do above (&printTime($next_midnight)) circumvents prototypes.
> You should probably leave out both the () on the sub definition, and the
> & on function calls.
>
This is an interesting thing. I looked at "perlsub" - and though they
mention creating subroutines with prototypes - they do not elaborate
on it. For e.g. I tried:
sub printTime($temp_time)
{
print "$temp_time";
}
Assuming $temp_time is a scalar like an integer. The compiler
complains that $temp_time is not defined. In case I do something
like :
sub printTime(my $temp_time)
{
print "$temp_time";
}
I still get the same error. What am I doing wrong?
Thanks again,
O.O.
------------------------------
Date: Fri, 27 Jul 2007 08:35:57 -0600
From: Scott Bryce <sbryce@scottbryce.com>
Subject: Re: Perl with DBI
Message-Id: <7ZCdnXZJKqlUnzfbnZ2dnUVZ_q3inZ2d@comcast.com>
Jason wrote:
> But this leads me to my next question. I want `Test 3` to be a
> variable, but using
>
> $dbh->do("CREATE TABLE param('var') (`date` VARCHAR(14)...
-------------------------^^^^^^^^^^^^
> is giving that same generic error as above.
ITYM $param('var').
------------------------------
Date: Fri, 27 Jul 2007 13:00:49 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: pid from startet process
Message-Id: <slrnfajk31.jjr.hjp-usenet2@zeno.hjp.at>
On 2007-07-26 22:57, Douglas Wells <see@signature.invalid> wrote:
> In article <slrnfahnt5.i1m.hjp-usenet2@zeno.hjp.at>,
> "Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
>> On 2007-07-19 22:28, Douglas Wells <see@signature.invalid> wrote:
>> > (And in response to another comment in this thread, the PID of
>> > child will almost certainly not be the shell's PID plus 1. Any
>> > system that does that presents a major security risk and should
>> > be trashed immediately -- because PIDs would then be guessable.)
>>
>> PIDs are guessable on the majority of unix systems (the only exceptions
>> I know are some BSD variants) - so this is something the average unix
>> programmer expects.
>
> Yes, elsewhere in this thread, I acknowledged that I made a wrong
> declaration about "most" POSIX-like system: Many of them do
> generate new candidates for PIDs by incrementing a counter. I
> have not, however, yielded on the claim of a security threat posed
> by this algorithm. Instead, I supplied a scenario, based on
> historical security incidents, that posed a threat in the presence
> of this algorithm.
Yes. If you had yielded that claim I wouldn't have had any reason to
answer. But since you haven't, I had to object.
The pid has traditionally always been a simple wrap-around counter. Any
unix programmer should know this. Using it in a context where a random
number (much less a cryptographically strong random number) is required
is just using the wrong tool for the job. Such an error may lead to a
security problem, but that's the fault of the programmer, not the tool.
(In your scenario, the real error is probably not using O_EXCL, btw, not
using the pid, but that depends on the intended use).
>> OTOH, a random pid is something the average unix programmer does not
>> expect - which may lead to a different class of (possibly
>> security-critical) errors.
>
> I'm sorry, but I find that (the security-critical error possibility)
> preposterous. Can you provide a scenario that both leads to correct
> behavior in the presence of the incrementing PID algorithm and to
> the presence of a security threat in its absence?
Yes. A linearly incrementing pid has some minimum time between the start
time of two processes with the same pid. Typically, about 30000 forks
are needed before the same pid can be reused.
A programmer which knows this may assume that the start time of the
process with suitably high resolution (for example 1 millisecond - 1
second is already too grainy given current computer speeds) together
with the pid is always unique: The system would need to be able to fork
30000 processes within 1 ms, which is far beyond the capabilities of
current systems and will stay impossible for some time.
A randomized pid breaks this assumption: The pid may be (with some small
probability, but nonetheless) reused immediately. Thus it is possible
that two processes which are started in the same millisecond get the
same "unique" id. What happens then depends on the application: Maybe
nothing, maybe some data gets mixed up, maybe some data vanishes ...
I know a number of applications which didn't work correctly on BSD
systems after randomized pids were introduced. The results were usually
lost data or data leaked to a different user, so that was at least
potentially security-critical.
Personally, I think it's a good thing that these applications were
broken, because it alerted the maintainers that the assumption
"timestamp + pid is unique" was faulty way before it became faulty on
systems on which it may have been possible to systematically exploit the
bug (IIRC all these applications used a one-second timestamp which is
now getting too short).
I'm not saying that random pids are bad /per se/. But the average unix
programmer probably doesn't know that they exist so he cannot consider
their consequences.
(As an aside: Is the randomness of the pids on BSD systems
cryptographically strong? If not, a programmer might assume they are and
make the same error as a programmer who thinks that linearly incremented
pids are "non-predictable". If they are, how about other systems with
random pids?)
[rest of posting snipped, as it was completely beside the point I was
trying to make]
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: Fri, 27 Jul 2007 13:18:17 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: pid from startet process
Message-Id: <slrnfajl3p.jjr.hjp-usenet2@zeno.hjp.at>
On 2007-07-27 07:38, Josef Moellers <josef.moellers@fujitsu-siemens.com> wrote:
> Peter J. Holzer wrote:
>
>> OTOH, a random pid is something the average unix programmer does not
>> expect - which may lead to a different class of (possibly
>> security-critical) errors.
>
> Sorry, but I have never seen a piece of (*x-) software that relies on
> some relation between PIDs.
See for example the original definition of the maildir format. Any
software which still uses that format is broken on systems which can
reuse the same pid within one second.
> It will break as soon as you have a wrap-around.
No. That is expected and handled. The relation which the application
relies on is "two processes which are alive within the same second
cannot have the same pid".
This assumption is of course faulty anyway (there may already be systems
which can fork 30000 times per second, and it may be possible to delay a
process before generating the timestamp on slower systems), but the fact
is that the first systems where this problem was noticed (with real lost
mail, not just as a theoretical possibility) were systems with
randomized pids - because it is many orders of magnitude more likely to
happen on such systems.
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: Fri, 27 Jul 2007 15:45:56 +0200
From: Josef Moellers <josef.moellers@fujitsu-siemens.com>
Subject: Re: pid from startet process
Message-Id: <f8csum$735$1@nntp.fujitsu-siemens.com>
Peter J. Holzer wrote:
> On 2007-07-27 07:38, Josef Moellers <josef.moellers@fujitsu-siemens.com=
> wrote:
>=20
>>Peter J. Holzer wrote:
>>
>>
>>>OTOH, a random pid is something the average unix programmer does not
>>>expect - which may lead to a different class of (possibly
>>>security-critical) errors.
>>
>>Sorry, but I have never seen a piece of (*x-) software that relies on=20
>>some relation between PIDs.
>=20
>=20
> See for example the original definition of the maildir format. Any
> software which still uses that format is broken on systems which can
> reuse the same pid within one second.
OK, I see. So it's not really the fact that PIDs are supposed to be=20
monotonic increasing (apart from one place), but the fact that, when=20
using random PIDs, a PID can be re-used before all the other PIDs were=20
(re-)used. Indeed, with random PIDs, it would not be impossible for a=20
process to get the PID of a process which has just died.
OTOH it would work if one could guarantee that a recently deceased=20
process' PID will be the last PID (re-)used of all available PIDs at=20
that moment, e.g. by putting PIDs into a FIFO.
I stand corrected,
Josef
--=20
These are my personal views and not those of Fujitsu Siemens Computers!
Josef M=F6llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
Company Details: http://www.fujitsu-siemens.com/imprint.html
------------------------------
Date: Fri, 27 Jul 2007 12:50:42 +0200 (CEST)
From: Stefano Sabatini <stefano.sabatini-lala@poste.it>
Subject: Reading from stdin then launching a program that reads from stdin strange behaviour
Message-Id: <slrnfajj6u.57j.stefano.sabatini-lala@santefisi.caos.org>
Hi all perlers,
I'm writing a perl script which reads from stdin, then launch an
interactive session of gnuplot. I'm on a gnu-linux system, perl 5.8.
The simplified code looks like this:
#! /usr/bin/perl
# reads from stdin, then lauch interactively gnuplot
open(FH, "/dev/stdin");
# filter stdin
while (<FH>) {
;
}
close(FH);
print "Launching gnuplot...\n";
# and now launch a gnuplot interactive session
system "gnuplot -";
If I feed the script with a file, like this:
cat file.txt | perl gnuplot-launcher.pl
gnuplot exits immediately from the interactive session.
If I filter a regular file (like "file.txt") or type interactively on
stdin like this:
cat - | gnuplot-launcher.pl
I'm writing
interactively
on
stdin
^D
then the gnuplot interactive mode seems to work.
All I want to do is to be able to access to an interactive session of
gnuplot from perl, but I'm evidently missing something.
Many thanks in advance.
Cheers.
--
Stefano Sabatini
Linux user number 337176 (see http://counter.li.org)
------------------------------
Date: Fri, 27 Jul 2007 11:42:29 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: regular expression match on the fly
Message-Id: <bffja393e078rermei4g3jvr7bba9vc694@4ax.com>
On Fri, 27 Jul 2007 08:31:04 GMT, "a" <a@mail.com> wrote:
>In order to keep the regex valid, the \ has to be modified to be \\
>the | has to be modified to be \| for your second example.
Just read on quotemeta() and \Q as hinted in my other post.
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: Fri, 27 Jul 2007 10:26:00 GMT
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: standard setup for scripts
Message-Id: <slrnfaik5s.iem.tadmc@tadmc30.sbcglobal.net>
Tom Bolick <tom_spam@removethis-tabsoftwaresystems.com> wrote:
> $IS_WEBSITE = (-e "/home/userme/lib/site_perl");
> if ($IS_WEBSITE){
You don't need a variable:
if ( -e "/home/userme/lib/site_perl"){
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Fri, 27 Jul 2007 14:25:07 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: standard setup for scripts
Message-Id: <5gu6ngF3imvoiU1@mid.individual.net>
anno4000@radom.zrz.tu-berlin.de wrote:
> Tom Bolick wrote:
>> Gunnar Hjalmarsson wrote:
>>> Guess you could put all but the first line in a separate file and call
>>> it like:
>>>
>>> BEGIN { do 'setup.pl' }
>>
>> But will this work with strict? Any variables defined in setup.pl are
>> not defined in the script that calls it? Or am I wrong?
>
> You are. Did you try it?
>
> The one thing that won't have an effect outside setup.pl is "use
> strict". Put that (and "use warnings") in the main script.
Right, Anno, I missed that 'use strict' is lexically scoped.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Fri, 27 Jul 2007 11:40:38 +0100
From: `Zidane Tribal <none@none.c0m>
Subject: Re: String::CRC crc function returns incorrect result, why?
Message-Id: <zYjqi.84065$oo1.73150@newsfe10.ams>
Sisyphus wrote:
>
> "`Zidane Tribal" <none@none.c0m> wrote in message
> news:KR8qi.137295$764.71@newsfe12.ams...
> .
> .
>> for example, this script.....
>>
>> #!/usr/bin/perl -w
>> use strict;
>> use String::CRC;
>> print "crc: " . crc($ARGV[0]) . " " . length($ARGV[0]) . "\n";
>>
>> produces this output:
>>
>> zidane@bluemist:~/ps2/dev/crccheck$ ./crctest.pl 12345
>> crc: 3817467633 5
>> zidane@bluemist:~/ps2/dev/crccheck$
>>
>> whereas this command:
>>
>> zidane@bluemist:~/ps2/dev/crccheck$ echo -n "12345" | cksum
>> 3288622155 5
>> zidane@bluemist:~/ps2/dev/crccheck$
>>
> .
> .
>> can anyone explain what i am doing wrong?
>
> I don't think you're doing anything wrong - they are apparently using
> different algorithms.
>
> String::CRC::Cksum ( http://search.cpan.org/~ahamm/String-CRC-Cksum-0.03/
> ) claims to be compatible with the POSIX cksum program.
>
> Cheers,
> Rob
but that then begs the question...... which is the *right* algorithm....
is there one standardised algorithm?
Thanks,
`Zidane.
--
You dont need a reason to help people. `Zidane Tribal.
------------------------------
Date: Fri, 27 Jul 2007 21:41:56 +1000
From: "Sisyphus" <sisyphus1@nomail.afraid.org>
Subject: Re: String::CRC crc function returns incorrect result, why?
Message-Id: <46a9da00$0$13845$afc38c87@news.optusnet.com.au>
"`Zidane Tribal" <none@none.c0m> wrote in message
news:zYjqi.84065$oo1.73150@newsfe10.ams...
.
.
>
> but that then begs the question...... which is the *right* algorithm....
> is there one standardised algorithm?
>
The *right* algorithm is the one that best suits your purposes.
If you want a perl module that's going to produce the same values as 'cksum'
then it looks like you need String::CRC::Cksum.
But if you don't need something that matches 'cksum' you could use any one
of the other modules - or even something like Digest::MD5 (which is a core
module) or Digest::SHA.
Cheers,
Rob
------------------------------
Date: Fri, 27 Jul 2007 07:47:14 -0700
From: T <g4173c@motorola.com>
Subject: Version for Script?
Message-Id: <1185547634.908357.75050@e9g2000prf.googlegroups.com>
Greetings:
At the beginning of all my Perl scripts I do:
#!/usr/local/bin/perl -w
# $Id$
The $Id$ will expand out in RCS/CVS to a version. My question is there
a way for me to get this in perl? It's in a comment line so will be
ignore by perl, but wondering if there's another way around this or
should I just create a $version variable and control the version that
way?
Thanks for any help in advance!
T
------------------------------
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 691
**************************************
