[25090] in Perl-Users-Digest
Perl-Users Digest, Issue: 7340 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Oct 29 14:06:12 2004
Date: Fri, 29 Oct 2004 11:05:09 -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, 29 Oct 2004 Volume: 10 Number: 7340
Today's topics:
computing the checksum <cNaOlSePbA@MvPeLtEsAtSaEr.com>
Convert String Containing Hex Values <cpryce@nospam.pryce.net>
Re: Convert String Containing Hex Values <noreply@gunnar.cc>
Re: Convert String Containing Hex Values <do-not-use@invalid.net>
Re: Convert String Containing Hex Values <cmail@cherryplankton.com>
Re: Convert String Containing Hex Values <cmail@cherryplankton.com>
FAQ 8.44: How do I tell the difference between errors f <comdog@panix.com>
Re: How do I check a valid mail address? (Anno Siegel)
Re: How to handle large variable <do-not-use@invalid.net>
Re: How to handle large variable <uri@stemsystems.com>
Re: How to handle large variable <do-not-use@invalid.net>
Re: How to handle large variable <uguttman@athenahealth.com>
Re: IDEs <nospam@nospam.com>
Re: IDEs <nospam@nospam.com>
Re: IDEs <nospam@nospam.com>
Re: IDEs <jwillmore@adelphia.net>
Re: IDEs <nospam@nospam.com>
Re: modifying hash key (dispatch table) <do-not-use@invalid.net>
Re: Net::POP3 Install <nospam@nospam.com>
Re: OT: perl errors <jeff@spamalanadingong.com>
Re: OT: perl errors <jwillmore@adelphia.net>
Re: OT: perl errors <mritty@gmail.com>
Re: Parsing 'dirty/corrupt data'. Advice wanted <nospam@bigpond.com>
Re: removin \n from only part of a string (sroemerm)
Re: speeding up perl script execution under apache <nospam@bigpond.com>
system return value makes for strange logic <ioneabu@yahoo.com>
Re: system return value makes for strange logic <ithinkiam@gmail.com>
Re: system return value makes for strange logic <ioneabu@yahoo.com>
Re: system return value makes for strange logic <ebohlman@omsdev.com>
Re: system return value makes for strange logic <do-not-use@invalid.net>
Re: system return value makes for strange logic <dsgSPAMFILTER@alum.dartmouth.org>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 29 Oct 2004 10:40:04 -0600
From: Spin <cNaOlSePbA@MvPeLtEsAtSaEr.com>
Subject: computing the checksum
Message-Id: <10o4sj3dm7koj2e@corp.supernews.com>
I need to compute the checksum on a hex message sent to a lab machine
via Device::SerialPort.
This is the C code snippet and instructions in their manual:
Assume the message is held in buf. "buf" is an array of unsigned char.
unsigned char *buf
short int message_size;
unsigned char trailer[2];
trailer[0] = 0;
for (int i = 0; i < message_size; i++)
trailer[0] += buf[i];
trailer[0] |= 0x80; // Turning on high bite ensures this cannot be an
ETX byte
trailer[1] = 0x03; // End of message ETX
Here's what I have in my perl script (note I'm just printing to screen
at this point, not to the device):
#!/usr/bin/perl -w
use strict;
use Term::ANSIColor;
my $status = chr(02); # Start of message (STX)
$status .= chr(hex(30));
$status .= chr(hex(33));
$status .= chr(hex(80));
$status .= chr(hex(86));
$status .= chr(hex(53));
$status .= chr(hex(50));
$status .= chr(hex(20));
$status .= chr(hex(20));
$status .= chr(hex(20));
$status .= chr(hex(73));
my $check_sum = 0;
my @reroute = unpack("H2"x length($status),$status);
for my $i (0 .. 10) {
$check_sum += hex($reroute[$i]);
print $reroute[$i];
$i++;
}
$check_sum |= hex(0x80);
$status .= hex($check_sum);
$status .= chr(03);
print color("red"), $check_sum, color("reset");
print unpack("H*",$status),"\n";
I know from their example that the checksum byte should be:
$status .= chr(hex(89));
I do not know any C and am a noobie at perl.
Thanks for your time,
CSG
------------------------------
Date: Fri, 29 Oct 2004 11:30:02 -0500
From: cp <cpryce@nospam.pryce.net>
Subject: Convert String Containing Hex Values
Message-Id: <291020041130026861%cpryce@nospam.pryce.net>
If I have a string that looks like this:
Job_x0020_Number
How do I turn that into:
Job Number
?
--
cp
------------------------------
Date: Fri, 29 Oct 2004 18:40:02 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Convert String Containing Hex Values
Message-Id: <2ufa4gF29pjriU1@uni-berlin.de>
cp wrote:
> If I have a string that looks like this:
>
> Job_x0020_Number
>
> How do I turn that into:
>
> Job Number
s/_x\d+_/ /;
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 29 Oct 2004 18:41:29 +0200
From: Arndt Jonasson <do-not-use@invalid.net>
Subject: Re: Convert String Containing Hex Values
Message-Id: <yzd7jp91npi.fsf@invalid.net>
cp <cpryce@nospam.pryce.net> writes:
> If I have a string that looks like this:
>
> Job_x0020_Number
>
> How do I turn that into:
>
> Job Number
If you try to solve the problem in a language you know, you will see
that you need to define the problem in more detail before you can
start coding. You ought to do so before asking here.
Making some plausible assumptions about your problem, this might work:
$string = "Job_x0020_Number";
$string =~ s/_x[0-9a-fA-F]+_/ /;
Since you wrote "hex values" in the subject line, I assume all
hexadecimal digits can occur after the 'x'.
------------------------------
Date: Fri, 29 Oct 2004 12:38:24 -0400
From: cp <cmail@cherryplankton.com>
Subject: Re: Convert String Containing Hex Values
Message-Id: <10o4sm4blnc878d@news.supernews.com>
cp wrote:
> If I have a string that looks like this:
>
> Job_x0020_Number
>
> How do I turn that into:
>
> Job Number
>
> ?
>
s/(.*)\_[[:xdigit:]]+\_(.*)/$1 $2/;
--
www.cherryplankton.com
------------------------------
Date: Fri, 29 Oct 2004 12:43:31 -0400
From: cp <cmail@cherryplankton.com>
Subject: Re: Convert String Containing Hex Values
Message-Id: <10o4svnqte7beb5@news.supernews.com>
cp wrote:
> cp wrote:
>
>> If I have a string that looks like this:
>>
>> Job_x0020_Number
>>
>> How do I turn that into:
>>
>> Job Number
>>
>> ?
>>
> s/(.*)\_[[:xdigit:]]+\_(.*)/$1 $2/;
>
>
Just tested mine, doesn't work if you use leading x for hex number. Change
to:
s/(.*)\_x[[:xdigit:]]+\_(.*)/$1 $2/;
still uglier than other solutions given but it should work.
--
www.cherryplankton.com
------------------------------
Date: Fri, 29 Oct 2004 16:03:01 +0000 (UTC)
From: PerlFAQ Server <comdog@panix.com>
Subject: FAQ 8.44: How do I tell the difference between errors from the shell and perl?
Message-Id: <cltpjl$bcb$1@reader1.panix.com>
This message is one of several periodic postings to comp.lang.perl.misc
intended to make it easier for perl programmers to find answers to
common questions. The core of this message represents an excerpt
from the documentation provided with Perl.
--------------------------------------------------------------------
8.44: How do I tell the difference between errors from the shell and perl?
(answer contributed by brian d foy, "<bdfoy@cpan.org>"
When you run a Perl script, something else is running the script for
you, and that something else may output error messages. The script might
emit its own warnings and error messages. Most of the time you cannot
tell who said what.
You probably cannot fix the thing that runs perl, but you can change how
perl outputs its warnings by defining a custom warning and die
functions.
Consider this script, which has an error you may not notice immediately.
#!/usr/locl/bin/perl
print "Hello World\n";
I get an error when I run this from my shell (which happens to be bash).
That may look like perl forgot it has a print() function, but my shebang
line is not the path to perl, so the shell runs the script, and I get
the error.
$ ./test
./test: line 3: print: command not found
A quick and dirty fix involves a little bit of code, but this may be all
you need to figure out the problem.
#!/usr/bin/perl -w
BEGIN {
$SIG{__WARN__} = sub{ print STDERR "Perl: ", @_; };
$SIG{__DIE__} = sub{ print STDERR "Perl: ", @_; exit 1};
}
$a = 1 + undef;
$x / 0;
__END__
The perl message comes out with "Perl" in front. The BEGIN block works
at compile time so all of the compilation errors and warnings get the
"Perl:" prefix too.
Perl: Useless use of division (/) in void context at ./test line 9.
Perl: Name "main::a" used only once: possible typo at ./test line 8.
Perl: Name "main::x" used only once: possible typo at ./test line 9.
Perl: Use of uninitialized value in addition (+) at ./test line 8.
Perl: Use of uninitialized value in division (/) at ./test line 9.
Perl: Illegal division by zero at ./test line 9.
Perl: Illegal division by zero at -e line 3.
If I don't see that "Perl:", it's not from perl.
You could also just know all the perl errors, and although there are
some people who may know all of them, you probably don't. However, they
all should be in the perldiag manpage. If you don't find the error in
there, it probably isn't a perl error.
Looking up every message is not the easiest way, so let perl to do it
for you. Use the diagnostics pragma with turns perl's normal messages
into longer discussions on the topic.
use diagnostics;
If you don't get a paragraph or two of expanded discussion, it might not
be perl's message.
--------------------------------------------------------------------
Documents such as this have been called "Answers to Frequently
Asked Questions" or FAQ for short. They represent an important
part of the Usenet tradition. They serve to reduce the volume of
redundant traffic on a news group by providing quality answers to
questions that keep coming up.
If you are some how irritated by seeing these postings you are free
to ignore them or add the sender to your killfile. If you find
errors or other problems with these postings please send corrections
or comments to the posting email address or to the maintainers as
directed in the perlfaq manual page.
Note that the FAQ text posted by this server may have been modified
from that distributed in the stable Perl release. It may have been
edited to reflect the additions, changes and corrections provided
by respondents, reviewers, and critics to previous postings of
these FAQ. Complete text of these FAQ are available on request.
The perlfaq manual page contains the following copyright notice.
AUTHOR AND COPYRIGHT
Copyright (c) 1997-2002 Tom Christiansen and Nathan
Torkington, and other contributors as noted. All rights
reserved.
This posting is provided in the hope that it will be useful but
does not represent a commitment or contract of any kind on the part
of the contributers, authors or their agents.
------------------------------
Date: 29 Oct 2004 15:29:49 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: How do I check a valid mail address?
Message-Id: <cltnld$l25$1@mamenchi.zrz.TU-Berlin.DE>
Matt Garrish <matthew.garrish@sympatico.ca> wrote in comp.lang.perl.misc:
>
> "PerlFAQ Server" <comdog@panix.com> wrote in message
> news:cl81ua$5p7$1@reader1.panix.com...
>
> > --------------------------------------------------------------------
> >
> > 9.17: How do I check a valid mail address?
> >
> >
> > You can't, at least, not in real time. Bummer, eh?
> >
> > Without sending mail to the address and seeing whether there's a human
> > on the other hand to answer you, you cannot determine whether a mail
> > address is valid.
>
> On the other "hand"? Shouldn't that be "end"?
Likewise in
Many are tempted to try to eliminate many frequently-invalid mail
addresses with a simple regex, such as "/^[\w.-]+\@(?:[\w-]+\.)+\w+$/".
It's a very bad idea. However, this also throws out many valid ones, and
says nothing about potential deliverability, so it is not suggested.
either "However, this also..." should be replaced by "It", or "It's a very
bad idea" has got to go.
Anno
------------------------------
Date: 29 Oct 2004 17:48:36 +0200
From: Arndt Jonasson <do-not-use@invalid.net>
Subject: Re: How to handle large variable
Message-Id: <yzdoeil1q5n.fsf@invalid.net>
Tad McClellan <tadmc@augustmail.com> writes:
> Arndt Jonasson <do-not-use@invalid.net> wrote:
>
> > For those who still wonder: $/ (the input line separator) gets set
> ^^^^
> > (locally) to nothing, so the whole file will be considered as one line
> ^^^^^^^ ^^^^
> > when doing <IN>.
>
>
> Let's not be so loose with terminology, it can lead to confusion...
I agree.
> Calling a thing that is not necessarily a line "line" is a Bad Idea.
I agree, but Programming Perl, 2nd edition (I know there is a 3rd),
only uses the word "line" when describing the angle operator. But I
should have spent 10 seconds and looked up the full name of $/ before
posting. I hope no one reads my explanations without looking the stuff
up themselves when they need it.
> $/ does not get set to nothing (whatever that means), it
> gets set to undef.
My thought process was probably something like "$/ gets set to the undefined
value, which causes the input operation to behave as if there were no
such thing as a record separator". Saying "$/ is set to undef" would have
been saying less than I wanted. It turned out a bit sloppy, yes. In another
context, "nothing" could very well mean the empty string.
Exactly how vague is one allowed to be without misleading, when saying
things about 'undef', I wonder. "$x has no value", "$x is undefined",
"$x has the value 'undef'", "$x has the undefined value", "$x is set
to nothing". Which of these are OK? I haven't picked up the common
Perl speech patterns yet.
(I find your two-line blank spaces harder to read than one-line ones, but
that's personal taste, of course.)
------------------------------
Date: Fri, 29 Oct 2004 16:23:15 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: How to handle large variable
Message-Id: <x7fz3xo5n1.fsf@mail.sysarch.com>
>>>>> "AJ" == Arndt Jonasson <do-not-use@invalid.net> writes:
>> $/ does not get set to nothing (whatever that means), it
>> gets set to undef.
AJ> My thought process was probably something like "$/ gets set to the
AJ> undefined value, which causes the input operation to behave as if
AJ> there were no such thing as a record separator". Saying "$/ is set
AJ> to undef" would have been saying less than I wanted. It turned out
AJ> a bit sloppy, yes. In another context, "nothing" could very well
AJ> mean the empty string.
and the empty string in $/ has another specific meaning of paragraph
mode. so using the term 'nothing' around $/ is not a good idea. computer
stuff likes specificity and not vagueness.
AJ> Exactly how vague is one allowed to be without misleading, when
AJ> saying things about 'undef', I wonder. "$x has no value", "$x is
AJ> undefined", "$x has the value 'undef'", "$x has the undefined
AJ> value", "$x is set to nothing". Which of these are OK? I haven't
AJ> picked up the common Perl speech patterns yet.
vagueness is not permitted!! :)
try reading some bad technical documentation where there are dangling
pronouns galore. which 'that' does this 'it' refer to? general writing
expects to have more pronouns and such for style and the reader can
usually pick out the proper meaning via many clues and some
redundancy. in computer writing (and coding), accuracy and unambiguity
are key.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: 29 Oct 2004 18:36:49 +0200
From: Arndt Jonasson <do-not-use@invalid.net>
Subject: Re: How to handle large variable
Message-Id: <yzdbrel1nxa.fsf@invalid.net>
Uri Guttman <uri@stemsystems.com> writes:
> >>>>> "AJ" == Arndt Jonasson <do-not-use@invalid.net> writes:
>
> >> $/ does not get set to nothing (whatever that means), it
> >> gets set to undef.
>
> AJ> My thought process was probably something like "$/ gets set to the
> AJ> undefined value, which causes the input operation to behave as if
> AJ> there were no such thing as a record separator". Saying "$/ is set
> AJ> to undef" would have been saying less than I wanted. It turned out
> AJ> a bit sloppy, yes. In another context, "nothing" could very well
> AJ> mean the empty string.
>
> and the empty string in $/ has another specific meaning of paragraph
> mode. so using the term 'nothing' around $/ is not a good idea. computer
> stuff likes specificity and not vagueness.
Is there a need to rub it in? We agree. I'm the kind of person who'd
like to see a formal definition for Perl.
> AJ> Exactly how vague is one allowed to be without misleading, when
> AJ> saying things about 'undef', I wonder. "$x has no value", "$x is
> AJ> undefined", "$x has the value 'undef'", "$x has the undefined
> AJ> value", "$x is set to nothing". Which of these are OK? I haven't
> AJ> picked up the common Perl speech patterns yet.
>
> vagueness is not permitted!! :)
>
> try reading some bad technical documentation where there are dangling
> pronouns galore. which 'that' does this 'it' refer to? general writing
> expects to have more pronouns and such for style and the reader can
> usually pick out the proper meaning via many clues and some
> redundancy. in computer writing (and coding), accuracy and unambiguity
> are key.
Yes, yes, I wasn't advocating sloppy style (like permitting all of the
above statements about $x), but I do want to know where the line is
drawn. Are all of them unpermissible?
I've had documentation written by me reworked by a "technical writer" (*)
so that while the language was slightly more mellifluous, it had become
impossible to see exactly what the documentation was saying - we had to
scrap that rework and go back to the original. I know what you mean.
(*) A really bad one. I don't mean any disrespect to the technical writers
as a species.
------------------------------
Date: Fri, 29 Oct 2004 13:52:46 -0400
From: Uri Guttman <uguttman@athenahealth.com>
Subject: Re: How to handle large variable
Message-Id: <m37jp9wgwh.fsf@linux.local>
>>>>> "AJ" == Arndt Jonasson <do-not-use@invalid.net> writes:
AJ> Uri Guttman <uri@stemsystems.com> writes:
>> and the empty string in $/ has another specific meaning of paragraph
>> mode. so using the term 'nothing' around $/ is not a good idea. computer
>> stuff likes specificity and not vagueness.
AJ> Is there a need to rub it in? We agree. I'm the kind of person who'd
AJ> like to see a formal definition for Perl.
i never stated we need a formal definition for perl. how did you get
that from my post? i said that your wording was wrong in an important
way ($/ does diff things when set to undef and ''). it could have been a
minor wording issue and i would not have commented upon it.
>> vagueness is not permitted!! :)
>>
>> try reading some bad technical documentation where there are dangling
>> pronouns galore. which 'that' does this 'it' refer to? general writing
>> expects to have more pronouns and such for style and the reader can
>> usually pick out the proper meaning via many clues and some
>> redundancy. in computer writing (and coding), accuracy and unambiguity
>> are key.
AJ> Yes, yes, I wasn't advocating sloppy style (like permitting all of
AJ> the above statements about $x), but I do want to know where the
AJ> line is drawn. Are all of them unpermissible?
like anything else in software and the world, it takes experience. some
get it faster than other like coding in general. writing unambiguous
english (or any natural lang) is a skill unto itself. and if it is too
unambiguous it becomes stilted and boring and useless too. read damian
conway's or peter scott's books to see how to write interesting and
accurate technical english.
uri
------------------------------
Date: Fri, 29 Oct 2004 11:45:04 -0400
From: "daniel kaplan" <nospam@nospam.com>
Subject: Re: IDEs
Message-Id: <1099065071.110850@nntp.acecape.com>
"James Willmore" <jwillmore@adelphia.net> wrote in message
news:V_SdnarV_9B6rB_cRVn-gA@adelphia.com...
> There's a FAQ for that :-) 'perldoc perlfaq`
i should have guessed
------------------------------
Date: Fri, 29 Oct 2004 12:13:59 -0400
From: "daniel kaplan" <nospam@nospam.com>
Subject: Re: IDEs
Message-Id: <1099066472.399820@nntp.acecape.com>
"James Willmore" <jwillmore@adelphia.net> wrote in message
news:V_SdnarV_9B6rB_cRVn-gA@adelphia.com...
>
> There's a FAQ for that :-) 'perldoc perlfaq`
>
first off james thanks for poitning that out to me so nicely, i have gone
and sent the email to:
supprt -die bot die- A(something)State ENDOFSENTENCEMARKER and some other
three letter word
but perhaps you can help me out here, i foudn that email address in the HTML
version of the faq. but my problem is searching through perldoc.
your suggestion of "perldoc perlfaq", gave me so much reading i thought i
was reading dicken's "david copperfield" (the unabridged version). and now
knowing what to look for i still couldnt find it!
once in found it in the HTML i tried the old reverse engineering method of
searching for it using perldoc. i used as many variations of perlfaq with
additions, comments, changes, with the -q, without, with quotes, without,
you see where i am gettng at. and still, nada....
so am i using the perldoc incorrectly? believe me, would love to find
everything in just a few keystrokes, not only does it reduce the flame wars
but it also gets me over my problem quicker....woudl appreciate some
thoughts....thanks
------------------------------
Date: Fri, 29 Oct 2004 12:16:09 -0400
From: "daniel kaplan" <nospam@nospam.com>
Subject: Re: IDEs
Message-Id: <1099066601.959543@nntp.acecape.com>
"Michael Carman" <mjcarman@mchsi.com> wrote in message
news:clthdk$9422@onews.rockwellcollins.com...
> How does your *editor* cause problems with 'use' statements? (rhetorical)
my apologies , from antoher thread, i made a new one so people looking for
IDEs would see thoughts and recommendations.
in a nutshell, the debugger of OpenPerlIDE complained on just loadin the USE
statements. it became too much of a headache. so komodo is slow running,
but it also in the end never whinned about anything but my errors. so i
switched back to that.
------------------------------
Date: Fri, 29 Oct 2004 13:18:24 -0400
From: James Willmore <jwillmore@adelphia.net>
Subject: Re: IDEs
Message-Id: <o7-dnULix73Y5h_cRVn-3A@adelphia.com>
daniel kaplan wrote:
> "James Willmore" <jwillmore@adelphia.net> wrote in message
> news:V_SdnarV_9B6rB_cRVn-gA@adelphia.com...
>
>>There's a FAQ for that :-) 'perldoc perlfaq`
<snip>
> but perhaps you can help me out here, i foudn that email address in the HTML
> version of the faq. but my problem is searching through perldoc.
>
> your suggestion of "perldoc perlfaq", gave me so much reading i thought i
> was reading dicken's "david copperfield" (the unabridged version). and now
> knowing what to look for i still couldnt find it!
from `perldoc perlfaq` (just the section needed from the OP)
=begin
How to contribute to the perlfaq
You may mail corrections, additions, and suggestions to
perlfaq-workers@perl.org . This alias should not be used to ask*
FAQs.
It's for fixing the current FAQ. Send questions to the
comp.lang.perl.misc newsgroup. You can view the source tree at
http://cvs.perl.org/cvsweb/perlfaq/ (which is outside of the main
Perl
source tree). The CVS repository notes all changes to the FAQ.
=cut
I'm not sure what you mean by "i still couldnt find it!". In fact,
this section is as near to the top of the FAQ as you can get without
being the top of the FAQ :-)
<snip>
> so am i using the perldoc incorrectly? believe me, would love to find
> everything in just a few keystrokes, not only does it reduce the flame wars
> but it also gets me over my problem quicker....woudl appreciate some
> thoughts....thanks
Might I suggest that you read `perldoc perldoc`. You'll find that
you can use the '-t' switch in perldoc to produce text output that
can be piped through another command or to a text file. So, for
example, to find the line that 'mail' resides on in 'perlfaq', you
could execute the following:
`perldoc -t perlfaq | grep -n mail`
and get the following information:
15: You may mail corrections, additions, and suggestions to
22: What will happen if you mail your Perl programming problems to
the authors
140: * What mailing lists are there for Perl?
730: * How do I parse a mail header?
734: * How do I check a valid mail address?
738: * How do I return the user's mail address?
740: * How do I send mail?
742: * How do I use MIME to make an attachment to a mail message?
744: * How do I read mail?
and see that line is what you might be looking for.
This is just one way to extend perldoc to get exactly what you want
from whatever documentation you view.
HTH
Jim
------------------------------
Date: Fri, 29 Oct 2004 13:49:13 -0400
From: "daniel kaplan" <nospam@nospam.com>
Subject: Re: IDEs
Message-Id: <1099072187.929116@nntp.acecape.com>
"James Willmore" <jwillmore@adelphia.net> wrote in message
news:o7-dnULix73Y5h_cRVn-3A@adelphia.com...
> daniel kaplan wrote:
> > "James Willmore" <jwillmore@adelphia.net> wrote in message
> > news:V_SdnarV_9B6rB_cRVn-gA@adelphia.com...
> >
> You may mail corrections, additions, and suggestions to
> perlfaq-workers@perl.org . This alias should not be used to ask*
> FAQs.
yeah was looking at AS's HTML for perl, not the FAQ, changing link now
as for the perldoc, still...no grep (is there a dos equiv?) and doing a
search on the email address itself produced nothing
will forward my email to the correct adfdress thanks
thanks for all your jelp
------------------------------
Date: 29 Oct 2004 18:19:29 +0200
From: Arndt Jonasson <do-not-use@invalid.net>
Subject: Re: modifying hash key (dispatch table)
Message-Id: <yzdk6t91oq6.fsf@invalid.net>
Tad McClellan <tadmc@augustmail.com> writes:
> My personal style is to never use ampersands on sub calls, whether
> called direct or via a coderef, I always use parens on sub calls
> instead (even when they take no args).
I was going to ask whether that was true even for 'eof', since the
calls "eof" and "eof()" behave differently, but I suppose 'eof' is not
a subroutine, but a built-in function.
------------------------------
Date: Fri, 29 Oct 2004 11:50:19 -0400
From: "daniel kaplan" <nospam@nospam.com>
Subject: Re: Net::POP3 Install
Message-Id: <1099065261.539133@nntp.acecape.com>
"Anno Siegel" <anno4000@lublin.zrz.tu-berlin.de> wrote in message
news:cltct8$c1i$3@mamenchi.zrz.TU-Berlin.DE...
> No Sir. You don't get to say what kind of replies you prefer. As
> long as you keep wasting everybody's time with badly posed and inane
> questions, you're going to be criticized for it. By the few that still
> read your stuff, that is...
>
before you asnwer back with this, and with that, you should check the end
result of the thread....if you had you would that not only did i correct the
situation, but exactly what i did, in case it happens to someone else.
------------------------------
Date: Fri, 29 Oct 2004 17:17:54 GMT
From: Jeff Thies <jeff@spamalanadingong.com>
Subject: Re: OT: perl errors
Message-Id: <6Xugd.11634$5i5.9641@newsread2.news.atl.earthlink.net>
Jürgen Exner wrote:
> Jeff Thies wrote:
>
>>Note my reply to Gunnar. There is a bug in Carp 1.24 where it works
>>with software errors but not compilation errors, at least not in my
>>environment. I've read the reason for that, but it makes little sense
>
>
> But who would deploy a CGI script to a web server if the script doesn't
> even pass a simple "perl -c"?
Actually I first noticed this when I did this:
use Image::Magick;
I expected it to either work or throw an error that it wasn't in
@INC, not a 500 error and nothing else.
Perhaps I should test locally first but I don't. Usually it's a database
page and testing without live data and all the other online config files
and modules makes little sense. I don't make many compile time mistakes
but it sure is nice to know what they are! Perl errors make it very easy
to trace them.
Jeff
> I recognize that there are scenarios where it would be too difficult to
> duplicate a complex web service environment with databases etc. locally and
> where you have to test on the server. But there is no reason no to compile
> the script locally before uploading it.
>
> jue
>
>
------------------------------
Date: Fri, 29 Oct 2004 13:29:55 -0400
From: James Willmore <jwillmore@adelphia.net>
Subject: Re: OT: perl errors
Message-Id: <2bSdnQ7AzcRq4B_cRVn-1w@adelphia.com>
Matt Garrish wrote:
> "James Willmore" <jwillmore@adelphia.net> wrote in message
> news:r46dnZdeIIXUXhzcRVn-hw@adelphia.com...
>
>>Jeff Thies wrote:
>>
>>>use CGI::Carp 'fatalsToBrowser';
>>>
>>
>>#you forgot the 'qw' in the original script
>>use CGI::Carp qw/fatalsToBrowser/;
>>
>
>
> Which isn't going to make any difference...
I haven't tried it the way the OP posted, but it *is* that way in
the documentation ... so, logically, I thought it would make a
difference (if one fouls up the actual import of CGI::Carp, then you
get a server 500 error, because the mechanism for outputting the
error to the browser isn't there :-) ).
However, after running the following tests, it appears you are correct.
[jim@localhost jim]$ perl -e "use CGI::Carp qw/fatalsToBrowser/;"
[jim@localhost jim]$ perl -e "use CGI::Carp 'fatalsToBrowser';"
[jim@localhost jim]$
Both return nothing - which is the expected behavior.
Now I've learned something today. Thanks.
Jim
------------------------------
Date: Fri, 29 Oct 2004 13:45:31 -0400
From: Paul Lalli <mritty@gmail.com>
Subject: Re: OT: perl errors
Message-Id: <cltvki$7m8$1@misc-cct.server.rpi.edu>
James Willmore wrote:
> However, after running the following tests, it appears you are correct.
>
> [jim@localhost jim]$ perl -e "use CGI::Carp qw/fatalsToBrowser/;"
> [jim@localhost jim]$ perl -e "use CGI::Carp 'fatalsToBrowser';"
>
> Both return nothing - which is the expected behavior.
>
> Now I've learned something today. Thanks.
Have you actually learned what qw// does?
qw// creates a list of single quoted strings. qw/foo bar baz/ is 100%
equivalent to ('foo', 'bar', 'baz'). Similarly, qw/fatalsToBrowser/ is
exactly equivalent to ('fatalsToBrowser'). The parentheses are
unneeded to create the list (they're generally just there for
precedence). This is why the two lines are equivalent.
Hope that helps a bit.
Paul Lalli
------------------------------
Date: Sat, 30 Oct 2004 02:05:48 +1000
From: Gregory Toomey <nospam@bigpond.com>
Subject: Re: Parsing 'dirty/corrupt data'. Advice wanted
Message-Id: <2uf82vF2a5tp8U1@uni-berlin.de>
burlo_stumproot@yahoo.se wrote:
>
>
> I'm finding myself in a position where I have to extract data from a
> file possibly filled with a lot of other junk of unknown length and
> format.
>
> The data has a strict format, a header line followed by lines of data
> that goes on for a fixed number of lines in some cases and in other
> cases until the next header line.
>
> My problem is that the data can at any point contain one or more lines
> with junk/data I dont want. It looks like the data is collected from
> an output device that listens to more than one application. (And I
> cant do anything about that). Some (or most) of the junk can be easily
> identified as such and can be removed but how to deal with the rest?
>
>
> Im not looking for code examples but rather advice on how to solve a
> problem like this in a robust and secure way.
>
My computer scientist brainspace pops up with thus question. It is analagous
to parsing in the presence of syntax errors.
Perhaps try http://search.cpan.org/~dconway/Parse-RecDescent-1.94/
gtoomey
------------------------------
Date: 29 Oct 2004 08:41:14 -0700
From: roemerman@gmail.com (sroemerm)
Subject: Re: removin \n from only part of a string
Message-Id: <e32a40f9.0410290741.2a9a9cbb@posting.google.com>
> Well, I used the s/// operator, which is explained in "perldoc perlop".
> The pattern is replaced with the return value from the expression to the
> right.
> Try to figure things out yourself by studying the mentioned part of the
> docs, and I'll be happy to answer possible *specific* questions you may
> have.
>
> One observation I make right now is that it would have been a better
> choice to exchange
>
> s!\n!!g
>
> for
>
> tr!\n!!d
>
> They do the same thing, but the latter is probably more efficient. (The
> tr/// operator is also described in "perldoc perlop", right after s///.)
In between "perldoc perlop", and the other posts I think I've got it
now. In general, I had a fairly good idea how it worked, but some of
the specifics escaped me and my crapy resources. My only Perl
resource is a crummy Osborne book. Specify I did not know what [^>]
did, also !, I could not find those in this book, but I'll probably
use perldoc more in the future instead.
Thanks guys for all your help.
------------------------------
Date: Sat, 30 Oct 2004 01:57:47 +1000
From: Gregory Toomey <nospam@bigpond.com>
Subject: Re: speeding up perl script execution under apache
Message-Id: <2uf7jrF2a23aoU2@uni-berlin.de>
stig erikson wrote:
> Hello.
> Even though this might be more of an apache question i will try here.
>
> We have a few perl scripts in production, they run in a web service
> environment. We use apache 2 with the mod_cgi module that came with
> apache on redhat. We have performance problems.
> It is run on a rather slow Pentium II 200Mhz server and it will be
> change in some not too far future but we would like to do something
> meanwhile.
I've written my own article/chechlist on this!
http://gregorytoomey.com/index.php?option=content&task=view&id=2&Itemid=2
> The entire script (from first to last line) takes about 0.05-0.1 second
> to run. When we run it on apache it will take around 2.5 seconds to
> execute the entire script.
> The overhead from executing perl and "compiling" the script is almost
> 2.5 seconds. This is the problem. (serving static pages is fast, so the
> problem is execution of scripts).
> The total execution time ir rather consistant no matter what script is
> run. For all scripts we run the overhead time is approximately 2.5
> seconds.
Your setup is way under powered. My aim is to get my Perl cgi executing
under 0.1 sec. See my article.
> We would like to minimize the overhead to gain time.
> Preferrably we dont want to change the scripts.
> Is there something we can do cut down the overhead time?
> Make perl start faster och make the compilation faster?
> Even a cut of the overhead from 2.5 to 2.0 seconds would help.
>
> Thank you
> Stig
gtoomey
------------------------------
Date: Fri, 29 Oct 2004 11:25:35 -0400
From: wana <ioneabu@yahoo.com>
Subject: system return value makes for strange logic
Message-Id: <10o4odkcq2dgm01@news.supernews.com>
I was writing a short script to create a mysql database and kept getting
confusing results:
system("mysqladmin --user='$user' --password='$pass' create $db")
or die "$db not created due to error\n";
The function lead to die being called and printing the error message but the
database was being created successfully. I changed it to:
system("mysqladmin --user='$user' --password='$pass' create $db")
and die "$db not created due to error\n";
and even though it doesn't look right at first glance, it makes sense
because system apparently returns 0 with success and numbers > 0 for
failure. I read about it in 'Programming Perl' and saw the explanation
that the return value gives information about the nature of the failure.
Isn't this strange? Don't we normally look to $! for errors and consider 0
to mean failure? I can accept it, but 'do and die' sounds funny compared
to the usual 'do or die'.
wana
------------------------------
Date: Fri, 29 Oct 2004 16:34:23 +0100
From: Chris Cole <ithinkiam@gmail.com>
Subject: Re: system return value makes for strange logic
Message-Id: <pan.2004.10.29.15.34.23.487715@gmail.com>
On Fri, 29 Oct 2004 11:25:35 -0400, wana wrote:
> I was writing a short script to create a mysql database and kept getting
> confusing results:
>
> system("mysqladmin --user='$user' --password='$pass' create $db")
> or die "$db not created due to error\n";
>
> The function lead to die being called and printing the error message but the
> database was being created successfully. I changed it to:
>
> system("mysqladmin --user='$user' --password='$pass' create $db")
> and die "$db not created due to error\n";
>
> and even though it doesn't look right at first glance, it makes sense
> because system apparently returns 0 with success and numbers > 0 for
> failure. I read about it in 'Programming Perl' and saw the explanation
> that the return value gives information about the nature of the failure.
> Isn't this strange? Don't we normally look to $! for errors and consider 0
> to mean failure? I can accept it, but 'do and die' sounds funny compared
> to the usual 'do or die'.
>
Try this for a more sensible format:
system("mysqladmin --user='$user' --password='$pass' create $db") == 0 or
die "$db not created due to error\n";
BTW why aren't you using perl DBI? That will give you more control over
errors and the like.
Chris.
------------------------------
Date: Fri, 29 Oct 2004 12:00:19 -0400
From: wana <ioneabu@yahoo.com>
Subject: Re: system return value makes for strange logic
Message-Id: <10o4qeom6h0se14@news.supernews.com>
>> to mean failure? I can accept it, but 'do and die' sounds funny compared
>> to the usual 'do or die'.
>>
> Try this for a more sensible format:
>
> system("mysqladmin --user='$user' --password='$pass' create $db") == 0 or
> die "$db not created due to error\n";
>
> BTW why aren't you using perl DBI? That will give you more control over
> errors and the like.
> Chris.
I didn't realize you could create a database with DBI. I'll have to read up
on it more. I actually use DBI with CGI and MySQL a lot but I thought you
had to create the database first and specify it for DBI->connect. Thanks
for the suggestions. I like your == 0 or alternative.
wana
------------------------------
Date: 29 Oct 2004 16:09:59 GMT
From: Eric Bohlman <ebohlman@omsdev.com>
Subject: Re: system return value makes for strange logic
Message-Id: <Xns9591729577743ebohlmanomsdevcom@130.133.1.4>
wana <ioneabu@yahoo.com> wrote in
news:10o4odkcq2dgm01@news.supernews.com:
> and even though it doesn't look right at first glance, it makes sense
> because system apparently returns 0 with success and numbers > 0 for
> failure. I read about it in 'Programming Perl' and saw the
> explanation that the return value gives information about the nature
> of the failure. Isn't this strange? Don't we normally look to $! for
> errors and consider 0 to mean failure? I can accept it, but 'do and
> die' sounds funny compared to the usual 'do or die'.
The reason is that system() returns the exit status of the program it runs.
What that status is is under the program's control, not perl's. The
convention (which again has nothing to do with Perl) is that a program
exits with 0 on success and any number of non-zero values upon failure.
Why? Because there's only one way a program can succeed, but quite a few
ways it can fail (the number of such ways varying from program to program)
and it's helpful if it can signal *why* it failed.
------------------------------
Date: 29 Oct 2004 18:28:02 +0200
From: Arndt Jonasson <do-not-use@invalid.net>
Subject: Re: system return value makes for strange logic
Message-Id: <yzdfz3x1obx.fsf@invalid.net>
Eric Bohlman <ebohlman@omsdev.com> writes:
> wana <ioneabu@yahoo.com> wrote in
> news:10o4odkcq2dgm01@news.supernews.com:
>
> > and even though it doesn't look right at first glance, it makes sense
> > because system apparently returns 0 with success and numbers > 0 for
> > failure. I read about it in 'Programming Perl' and saw the
> > explanation that the return value gives information about the nature
> > of the failure. Isn't this strange? Don't we normally look to $! for
> > errors and consider 0 to mean failure? I can accept it, but 'do and
> > die' sounds funny compared to the usual 'do or die'.
>
> The reason is that system() returns the exit status of the program it runs.
> What that status is is under the program's control, not perl's. The
> convention (which again has nothing to do with Perl) is that a program
> exits with 0 on success and any number of non-zero values upon failure.
> Why? Because there's only one way a program can succeed, but quite a few
> ways it can fail (the number of such ways varying from program to program)
> and it's helpful if it can signal *why* it failed.
The history of that convention has mainly to do with Unix. I think VMS
is one system that treats return status from processes differently. At
least the C standard committee found it necessary to invent
preprocessor symbols for denoting successful and failing process exit,
since 0 for success was not universal.
Since I'm on the subject: it often happens in Perl code that people
take the return value from 'system', divide it by 256, and think they
have the exit status. They have that, if the process didn't dump core
(if we're on a Unix system). If it dumped core, the lowest bits are
nonzero. Thus, a program crash may be misinterpreted as successful
exit. The doc for 'system' does say this, but it may be easy to forget.
------------------------------
Date: Fri, 29 Oct 2004 12:48:21 -0400
From: "David Gale" <dsgSPAMFILTER@alum.dartmouth.org>
Subject: Re: system return value makes for strange logic
Message-Id: <2ufadrF294t0bU1@uni-berlin.de>
Quoth Arndt Jonasson <do-not-use@invalid.net>:
> Since I'm on the subject: it often happens in Perl code that people
> take the return value from 'system', divide it by 256, and think they
> have the exit status. They have that, if the process didn't dump core
> (if we're on a Unix system). If it dumped core, the lowest bits are
> nonzero. Thus, a program crash may be misinterpreted as successful
> exit. The doc for 'system' does say this, but it may be easy to
> forget.
Actually, they lose more than just whether or not it dumped core. If it was
interrupted by *any* signal, that goes in the lower bits.
Try:
perl -e 'print system("sleep 30")."\n";'
and hit Ctl-C while it's sleeping.
------------------------------
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 V10 Issue 7340
***************************************
