[25240] in Perl-Users-Digest
Perl-Users Digest, Issue: 7485 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Dec 5 03:05:40 2004
Date: Sun, 5 Dec 2004 00:05:06 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 5 Dec 2004 Volume: 10 Number: 7485
Today's topics:
FAQ 4.19: How do I validate input? <comdog@panix.com>
file handle problem <sc245@hotmail.com>
file handle problem <sc245@hotmail.com>
Re: file handle problem <jurgenex@hotmail.com>
Re: file handle problem <noreply@gunnar.cc>
Re: file handle problem <noreply@gunnar.cc>
Re: file handle problem <someone@example.com>
Re: File locking <nospam@all.thx>
Re: File locking <tintin@invalid.invalid>
Re: File locking <nospam@all.thx>
Re: File locking <1usa@llenroc.ude.invalid>
Golf... <wyzelli@yahoo.com>
Re: Golf... <uri@stemsystems.com>
Re: Golf... <wyzelli@yahoo.com>
Re: Golf... <uri@stemsystems.com>
Re: Golf... <wyzelli@yahoo.com>
Re: Golf... <uri@stemsystems.com>
How to kill all child processes except itself? <samsarazeal@gmail.com>
Re: installing dbd::mysql via cygwin on windows <amead@comcast.net>
Re: print FILE truncating input <cNaOlSePbA@MvPeLtEsAtSaEr.com>
Re: Trying to install module with CPAN <amead@comcast.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 5 Dec 2004 05:03:01 +0000 (UTC)
From: PerlFAQ Server <comdog@panix.com>
Subject: FAQ 4.19: How do I validate input?
Message-Id: <cou4q5$if9$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.
--------------------------------------------------------------------
4.19: How do I validate input?
The answer to this question is usually a regular expression, perhaps
with auxiliary logic. See the more specific questions (numbers, mail
addresses, etc.) for details.
--------------------------------------------------------------------
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: Sat, 4 Dec 2004 18:29:48 -0500
From: "newbie" <sc245@hotmail.com>
Subject: file handle problem
Message-Id: <cothat$80e$1@news01.cit.cornell.edu>
Hi all,
I have the following simple file reading code, the files being read in is
fairly large (4 MB with 160,000 lines, but each line only contain like 3
strings).
open(FILEHANDLE, "<a.dat") || die "Can't open: $!\n";
chomp(@array1 = <FILEHANDLE>);
close FILEHANDLE;
#do somthing with @array1
open(FILEHANDLE, "<b.data") || die "Can't open: $!\n";
chomp(@array2 = <FILEHANDLE>);
close FILEHANDLE;
#do something with @array2
My problem is that the 1st time reading in the file is fine, but when I open
the filehandler the 2nd time, the program gets stuck. I think it's something
to do with the large file, because I try out with smaller files, and it
works fine. Can anyone help me? Thanks
While on file reading subject, is there a fast way of reading in large
files?
------------------------------
Date: Sat, 4 Dec 2004 21:42:03 -0500
From: "newbie" <sc245@hotmail.com>
Subject: file handle problem
Message-Id: <cotshs$bu2$1@news01.cit.cornell.edu>
Thanks guys, I get the point of not putting large file in memory. I got a
new question. Say I have a bunch of large files, and I want to just get rid
of the last line of each of these large files. Is there a simpler way
without reading in and outputing the file?
Thanks.
------------------------------
Date: Sun, 05 Dec 2004 00:22:16 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: file handle problem
Message-Id: <Ywssd.1554$wa3.248@trnddc02>
newbie wrote:
> I have the following simple file reading code, the files being read
> in is fairly large (4 MB with 160,000 lines, but each line only
> contain like 3 strings).
>
> open(FILEHANDLE, "<a.dat") || die "Can't open: $!\n";
> chomp(@array1 = <FILEHANDLE>);
> close FILEHANDLE;
[...]
> While on file reading subject, is there a fast way of reading in large
> files?
Well, the standard answer is do you _really_ need to read the whole file
into memory?
The more perlish way would be to read the file line by line and process each
line as it is being read. Then even huge files are no problem.
Yes, there are cases where you do need the whole file content in memory.
But experience showed that in real life scenarios you can almost always
process the file line by line.
jue
------------------------------
Date: Sun, 05 Dec 2004 01:21:53 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: file handle problem
Message-Id: <31f2qcF3bc12bU1@individual.net>
newbie wrote:
> I have the following simple file reading code, the files being read in is
> fairly large (4 MB with 160,000 lines, but each line only contain like 3
> strings).
>
> open(FILEHANDLE, "<a.dat") || die "Can't open: $!\n";
> chomp(@array1 = <FILEHANDLE>);
> close FILEHANDLE;
>
> #do somthing with @array1
>
> open(FILEHANDLE, "<b.data") || die "Can't open: $!\n";
> chomp(@array2 = <FILEHANDLE>);
> close FILEHANDLE;
>
> #do something with @array2
>
> My problem is that the 1st time reading in the file is fine, but when I open
> the filehandler the 2nd time, the program gets stuck. I think it's something
> to do with the large file, because I try out with smaller files, and it
> works fine. Can anyone help me?
The starting-point is that you should avoid reading such large files
into memory if possible, and rather read them line by line:
open(FILEHANDLE, "<a.dat") || die "Can't open: $!\n";
while (<FILEHANDLE>) {
# do somthing with line X
}
close FILEHANDLE;
Why do you think you need to read the files into memory? If you let us
know what you want to do, somebody may be able to advise you further.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Sun, 05 Dec 2004 03:45:26 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: file handle problem
Message-Id: <31fb9qF37ogqlU1@individual.net>
newbie wrote:
> Thanks guys, I get the point of not putting large file in memory. I got a
> new question. Say I have a bunch of large files, and I want to just get rid
> of the last line of each of these large files. Is there a simpler way
> without reading in and outputing the file?
Check out Tie::File.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Sun, 05 Dec 2004 03:14:15 GMT
From: "John W. Krahn" <someone@example.com>
Subject: Re: file handle problem
Message-Id: <b2vsd.231603$df2.13533@edtnps89>
newbie wrote:
> Thanks guys, I get the point of not putting large file in memory. I got a
> new question. Say I have a bunch of large files, and I want to just get rid
> of the last line of each of these large files. Is there a simpler way
> without reading in and outputing the file?
perldoc -f truncate
John
--
use Perl;
program
fulfillment
------------------------------
Date: Sun, 5 Dec 2004 14:10:05 +1300
From: "MadDogMcGee" <nospam@all.thx>
Subject: Re: File locking
Message-Id: <cotn5g$rjs$1@lust.ihug.co.nz>
I seem to have solved my problem:
$file = "test.iso";
while (1) {
if (open(FILE, "< $file")) {
print "Transfer completed\n";
close (FILE);
}
else {
print "Not ready\n";
}
}
Is there anything undesirable about this approach?
Notes: I'm on an NT based system, and the file is being copied by a
different program. I don't want to work on the file with Perl until it's
finished being copied across.
"MadDogMcGee" <nospam@all.thx> wrote in message
news:<cot24f$c8g$1@lust.ihug.co.nz>...
> Hi,
>
> I want to process the contents of a file, but only when it's copied across
> to the work folder. Some of the files take a few seconds to bring across.
> How do I detect that the file is complete and ready for processing?
>
> Thanks.
>
>
"Lawson Hanson" <lawhan@ozemail.com.au> wrote in message
news:J_qsd.344$A6.16953@nnrp1.ozemail.com.au...
> MadDogMcGee wrote:
> > Hi,
> >
> > I want to process the contents of a file, but only when it's copied
across
> > to the work folder. Some of the files take a few seconds to bring
across.
> > How do I detect that the file is complete and ready for processing?
> >
> > Thanks.
> >
> >
>
> One way might be to do something like:
>
> 1. Obtain the size (byte count) of the source file
> 2. Obtain the MD5 message digest checksum
> of the source file
> 3. Copy the file from the source to the target
> 4. Check the size of the target file every so often
> 5. When the target file has the same byte count as
> the source file, then obtain the MD5 message
> digest checksum of the target file
> 6. Compare the MD5 message digest checksums of the
> two files, and proceed only if they are equal.
>
> That might be a bit of overkill, but it should enable
> a fairly robust solution to the problem.
>
> Regards,
>
> Lawson
------------------------------
Date: Sun, 5 Dec 2004 17:42:17 +1300
From: "Tintin" <tintin@invalid.invalid>
Subject: Re: File locking
Message-Id: <31fhqdF3a2oqgU1@individual.net>
"MadDogMcGee" <nospam@all.thx> wrote in message
news:cotn5g$rjs$1@lust.ihug.co.nz...
>I seem to have solved my problem:
>
>
> $file = "test.iso";
>
> while (1) {
>
> if (open(FILE, "< $file")) {
> print "Transfer completed\n";
> close (FILE);
>
> }
> else {
> print "Not ready\n";
> }
>
> }
>
>
>
> Is there anything undesirable about this approach?
Did you intend on having an infinite loop?
Your test for file existence, not copy completion (unless NTFS buffers
everything before copying)
------------------------------
Date: Sun, 5 Dec 2004 19:22:07 +1300
From: "MadDogMcGee" <nospam@all.thx>
Subject: Re: File locking
Message-Id: <cou9eh$7or$1@lust.ihug.co.nz>
"Tintin" <tintin@invalid.invalid> wrote in message
news:31fhqdF3a2oqgU1@individual.net...
>
> "MadDogMcGee" <nospam@all.thx> wrote in message
> news:cotn5g$rjs$1@lust.ihug.co.nz...
> >I seem to have solved my problem:
> >
> >
> > $file = "test.iso";
> >
> > while (1) {
> >
> > if (open(FILE, "< $file")) {
> > print "Transfer completed\n";
> > close (FILE);
> >
> > }
> > else {
> > print "Not ready\n";
> > }
> >
> > }
> >
> >
> >
> > Is there anything undesirable about this approach?
>
> Did you intend on having an infinite loop?
>
> Your test for file existence, not copy completion (unless NTFS buffers
> everything before copying)
>
>
>
Yes, I meant it to be an infinite loop, but just as an example of using open
for determining copy completion. I will write the actual code tomorrow,
during work hours. I tested the above on Windows XP and it worked the way I
wanted.
------------------------------
Date: 5 Dec 2004 06:34:25 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: File locking
Message-Id: <Xns95B610034DEDCasu1cornelledu@132.236.56.8>
"MadDogMcGee" <nospam@all.thx> wrote in
news:cou9eh$7or$1@lust.ihug.co.nz:
>> "MadDogMcGee" <nospam@all.thx> wrote in message
>> news:cotn5g$rjs$1@lust.ihug.co.nz...
>> > $file = "test.iso";
>> >
>> > while (1) {
>> >
>> > if (open(FILE, "< $file")) {
>> > print "Transfer completed\n";
>> > close (FILE);
>> >
>> > }
>> > else {
>> > print "Not ready\n";
>> > }
>> >
>> > }
> I tested the above on Windows XP and it worked the way I wanted.
This is a very tight loop with an expensive system call in it. If you are
not going to use OS facilities to wait for completeion, you should at
least sleep a second between calls to avoid hogging the CPU.
--
A. Sinan Unur
1usa@llenroc.ude.invalid
(remove '.invalid' and reverse each component for email address)
------------------------------
Date: Sun, 05 Dec 2004 04:45:15 GMT
From: "Peter Wyzl" <wyzelli@yahoo.com>
Subject: Golf...
Message-Id: <vnwsd.59367$K7.17967@news-server.bigpond.net.au>
I have binary data representing an IP address (among other things) in $data.
(part of a libpcap file, read in binary mode)
The 4 bytes of $data repreenting the IP address start at offset 26. I am
looking for a good solution to represent this in dotted quad. Since there
are many repetitions of this manipulation, efficiency is important.
What I have so far is:
(assume $sourceip has been pre-declared and $data contains binary data)
$sourceip = join '.', map {ord}(split '', substr $data,26,4,);
Shorter solutions are also of interest to me.
BTW, this is on a windows platform so the data is in little endian order in
the headers, and network order in the raw IP packet (no reason to make life
simple...) This IP is therefore stored in network order. I am
contemplating a solution using unpack, but am still learing all the
different templates, and am unsure whether it is more efficient than substr
(or enough so to be worth trying). I have not yet benchmarked a regex
solution, having a hunch that it would be less efficient.
--
Wyzelli
------------------------------
Date: Sun, 05 Dec 2004 05:01:50 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Golf...
Message-Id: <x7is7hnxs1.fsf@mail.sysarch.com>
>>>>> "PW" == Peter Wyzl <wyzelli@yahoo.com> writes:
PW> (assume $sourceip has been pre-declared and $data contains binary data)
PW> $sourceip = join '.', map {ord}(split '', substr $data,26,4,);
PW> Shorter solutions are also of interest to me.
unpack is your friend. no need for both split and substr. sprintf can do
the ord and join in one.
<untested>
my $ip = sprintf '%c.%c.%c.%c', unpack 'X26CCCC', $data ;
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: Sun, 05 Dec 2004 05:47:56 GMT
From: "Peter Wyzl" <wyzelli@yahoo.com>
Subject: Re: Golf...
Message-Id: <gixsd.59428$K7.55813@news-server.bigpond.net.au>
"Uri Guttman" <uri@stemsystems.com> wrote in message
news:x7is7hnxs1.fsf@mail.sysarch.com...
: >>>>> "PW" == Peter Wyzl <wyzelli@yahoo.com> writes:
:
: PW> (assume $sourceip has been pre-declared and $data contains binary
data)
:
: PW> $sourceip = join '.', map {ord}(split '', substr $data,26,4,);
:
: PW> Shorter solutions are also of interest to me.
:
: unpack is your friend. no need for both split and substr. sprintf can do
: the ord and join in one.
:
: <untested>
Thats OK, I'm happy to do the testing and playing around...
: my $ip = sprintf '%c.%c.%c.%c', unpack 'X26CCCC', $data ;
$sourceip = sprintf '%s.%s.%s.%s', unpack'x26CCCC', $data;
works (the unpack C makes it a char already and %c messes with that....
which means I can dispense with sprintf and use join again to get
$sourceip = join '.', unpack 'x26CCCC', $data;
12 strokes less!
Also you meant x not X in the template for unpack (forward null bytes not
backwards....)
But now that does what I need, in a nice elegant way. I will attempt a
benchmark shortly, but I suspect anything with less function calls must be
better. 2 v 5 is a good saving.
Incidentally, I have been able to process 5Mb (sysreading 1 packet at a
time) in less than 3 seconds before this improvement, so this looks hopeful
for reasonable performance on larger files..
Thanks Uri. That was just the mental poke I needed to move forward with
this little project.
:)
--
Wyzelli
------------------------------
Date: Sun, 05 Dec 2004 06:03:44 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Golf...
Message-Id: <x74qj1nuww.fsf@mail.sysarch.com>
>>>>> "PW" == Peter Wyzl <wyzelli@yahoo.com> writes:
PW> "Uri Guttman" <uri@stemsystems.com> wrote in message
PW> :
PW> : <untested>
PW> Thats OK, I'm happy to do the testing and playing around...
want to do more testing and fixing of my code? :)
PW> : my $ip = sprintf '%c.%c.%c.%c', unpack 'X26CCCC', $data ;
PW> $sourceip = sprintf '%s.%s.%s.%s', unpack'x26CCCC', $data;
PW> works (the unpack C makes it a char already and %c messes with that....
d'oh! like i said, untested. and i was loopy then (all day in fact. :( ).
PW> which means I can dispense with sprintf and use join again to get
PW> $sourceip = join '.', unpack 'x26CCCC', $data;
PW> 12 strokes less!
and fewer calls which is more important.
PW> Also you meant x not X in the template for unpack (forward null bytes not
PW> backwards....)
well i always have case issues :)
PW> But now that does what I need, in a nice elegant way. I will
PW> attempt a benchmark shortly, but I suspect anything with less
PW> function calls must be better. 2 v 5 is a good saving.
that is the general rule of thumb in perl but there are many
counterintuitive examples especially with regexes.
PW> Incidentally, I have been able to process 5Mb (sysreading 1 packet
PW> at a time) in less than 3 seconds before this improvement, so this
PW> looks hopeful for reasonable performance on larger files..
it should be much faster IMO. post the results.
PW> Thanks Uri. That was just the mental poke I needed to move
PW> forward with this little project.
i will sharpen my poker for the next time! :)
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: Sun, 05 Dec 2004 06:10:23 GMT
From: "Peter Wyzl" <wyzelli@yahoo.com>
Subject: Re: Golf...
Message-Id: <jDxsd.59454$K7.53414@news-server.bigpond.net.au>
"Peter Wyzl" <wyzelli@yahoo.com> wrote in message
news:gixsd.59428$K7.55813@news-server.bigpond.net.au...
: "Uri Guttman" <uri@stemsystems.com> wrote in message
: news:x7is7hnxs1.fsf@mail.sysarch.com...
:: >>>>> "PW" == Peter Wyzl <wyzelli@yahoo.com> writes:
::
<snip>:
: $sourceip = join '.', unpack 'x26CCCC', $data;
$sourceip = join '.', unpack 'x26C4', $data;
Is even better again...
(guess who is finally starting to understand this function? :) And that's
even after reading MJD's excellent tutorial at I know not where (can't seem
to find it again)
--
Wyzelli
------------------------------
Date: Sun, 05 Dec 2004 06:24:24 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Golf...
Message-Id: <x7zn0tmfdz.fsf@mail.sysarch.com>
>>>>> "PW" == Peter Wyzl <wyzelli@yahoo.com> writes:
PW> "Peter Wyzl" <wyzelli@yahoo.com> wrote in message
PW> news:gixsd.59428$K7.55813@news-server.bigpond.net.au...
PW> : "Uri Guttman" <uri@stemsystems.com> wrote in message
PW> : news:x7is7hnxs1.fsf@mail.sysarch.com...
PW> :: >>>>> "PW" == Peter Wyzl <wyzelli@yahoo.com> writes:
PW> ::
PW> <snip>:
PW> : $sourceip = join '.', unpack 'x26CCCC', $data;
PW> $sourceip = join '.', unpack 'x26C4', $data;
PW> Is even better again...
i should have done that too. pack/unpack are very amazing but they scare
too many. coming from an assembler/c background, they make perfect sense
to me.
PW> (guess who is finally starting to understand this function? :) And
PW> that's even after reading MJD's excellent tutorial at I know not
PW> where (can't seem to find it again)
sure to be on plover.com somewhere. google his site.
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: 4 Dec 2004 19:10:48 -0800
From: "zeal" <samsarazeal@gmail.com>
Subject: How to kill all child processes except itself?
Message-Id: <1102216248.804195.257850@f14g2000cwb.googlegroups.com>
I have a perl script, part of it as below:
-------------------------------------------
$rc = eval{
my ($rc);
local $SIG{ALRM} = sub { die "Timeout" };
alarm $timeout;
$rc = 0xffff & system $cmd;
alarm 0;
return $rc;
};
if ( $@ && $@ =~ /Timeout/ ) {
local $SIG{INT} = 'IGNORE';
kill INT => -$$;
$rc = 0x9999;
}
--------------------------------------------
What I want to do is that kill all child processes after the timeout
but keep the script itself alive. Actually I need to kill all processes
(the whole process group) invoked from the system() call. The reason I
need to use system is, I need to analysis the return value "$rc".
In most cases, the system() can finish before the timeout, however, in
some cases, it will time out, then I want to kill all the processes
after the timeout.
The way I used to do the kill is
-----------------------------
local $SIG{INT} = 'IGNORE';
kill INT => -$$;
-----------------------------
I got this from somewhere, it's said that when a SIG sent to a negative
pid, it will be sent to the whole process group. Since I "INGORE"
myself, then this shouls satisfy my requirement.
I run this script in LINUX system.
Most of the case, it works fine. However, sometimes, I found that when
the script is finished, some child processes are still running, which
means that they were not killed.
And use "pstree -p", I found that those alive child processes's parent
PID is changed, not the pid of the perl script process.
My question is how can I completely kill all the child processess?
BTW: the "$cmd" is used to call "make -f somemakefile", several
generation of child processes may invoked during the system().
One example,
when I run my script.
31166 2416 0 04:01 pts/0 00:00:00 /usr/bin/perl -w ./regtests.pl
After it's done, some timeout processes are already killed, but two of
them are still alive
pstree -p
+-sh(31844)---make(31845)---sim(31851)
+-sh(31856)---make(31857)---sim(31863)
The parent id is already changed ...
On one of my debian platform (kernel 2.6), this always happens, most of
child processes are alive. On other linux platform (including debian
(kernel 2.4), redhat, gentoo), only some of them can not be killed.
Any solutions???
Thanks very much!
------------------------------
Date: Sun, 05 Dec 2004 01:07:24 -0600
From: Alan Mead <amead@comcast.net>
Subject: Re: installing dbd::mysql via cygwin on windows
Message-Id: <pan.2004.12.05.07.07.24.117913@comcast.net>
On Sat, 04 Dec 2004 00:31:11 +0000, Glenn wrote:
> I'm having an issue installing the DBD::mysql; it's complaining about
> not being able to find mysql_config.
>
> I've seen some posts regarding installing mysql-devel.. I'm unsure what
> this means.
>
> I have installed MySQL in Program Files _prior_ to my install of
> cygwin.. is this an issue in and of itself?
>
> Is it possible for someone to provide a template mysql_config file that
> I can plus in one of my cygwin dir's somewhere?
If you can find it, a few days ago there was a thread about this and Paul
Lalli, I think, posted a link to some DBD::mysql docs. It looked as
though it might be difficult to do this. I agree with the other poster;
you should see if there is someone in the mysql community that has done
this and could help.
-Alan
------------------------------
Date: Sat, 04 Dec 2004 23:36:33 -0600
From: Spin <cNaOlSePbA@MvPeLtEsAtSaEr.com>
Subject: Re: print FILE truncating input
Message-Id: <10r57ivqe0kbs77@corp.supernews.com>
Joe Smith wrote:
> Spin wrote:
>
>> print "Result Type: ".$result_type."\n";
>> print FILE get_lab_header($loc),"\n";
>
>
> Change that to
>
> print FILE "Result Type: $result_type\n",get_labheader($loc),"\n";
>
> and make sure that get_labheader() uses sprintf (and not printf).
> -Joe
Changing to sprintf from printf did the trick.
Thanks for your help,
Caleb
------------------------------
Date: Sun, 05 Dec 2004 01:11:01 -0600
From: Alan Mead <amead@comcast.net>
Subject: Re: Trying to install module with CPAN
Message-Id: <pan.2004.12.05.07.11.01.646066@comcast.net>
On Sat, 04 Dec 2004 14:44:11 +0000, Joe Smith wrote:
> simon wrote:
>
>> The error message I receive is as follows:
>>
> > [29 lines of normal output]
>
> Did you leave out a line there? I don't see an error message.
> -Joe
Yeah, what's the problem? It stops at this point?
I do things slightly differently. I type cpan and then at the cpan
prompt, I install the module. The syntax is printed by cpan when it
starts.
I mention this because the first time I ran it, I had to answer a bunch of
questions.
Also, I sometimes run into trouble because I forget to su before I run
cpan. If you run as yourself, it cannot do the install step of the
installation.
HTH,
-Alan
------------------------------
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 7485
***************************************
