[30881] in Perl-Users-Digest
Perl-Users Digest, Issue: 2126 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jan 14 21:10:00 2009
Date: Wed, 14 Jan 2009 18:09:26 -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 Wed, 14 Jan 2009 Volume: 11 Number: 2126
Today's topics:
Re: Add columns of a File <hansmu@xs4all.nl>
Re: match text followed by number <tadmc@seesig.invalid>
Re: match text followed by number <tim@burlyhost.com>
Re: match text followed by number <tadmc@seesig.invalid>
Re: match text followed by number <tim@burlyhost.com>
Re: opening a file <hansmu@xs4all.nl>
Re: opening a file <mvdwege_public@myrealbox.com>
Re: opening a file <hjp-usenet2@hjp.at>
Re: opening a file <hjp-usenet2@hjp.at>
Re: opening a file <tadmc@seesig.invalid>
Re: opening a file <hjp-usenet2@hjp.at>
Re: opening a file xhoster@gmail.com
Re: opening a file <tim@burlyhost.com>
Re: opening a file <george@example.invalid>
Re: opening a file <george@example.invalid>
Re: set timeout module for Perl <jurgenex@hotmail.com>
Re: set timeout module for Perl <hansmu@xs4all.nl>
Re: set timeout module for Perl <meneldor@gmail.com>
Re: set timeout module for Perl <jurgenex@hotmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 15 Jan 2009 00:42:40 +0100
From: Hans Mulder <hansmu@xs4all.nl>
Subject: Re: Add columns of a File
Message-Id: <496e7999$0$192$e4fe514c@news.xs4all.nl>
cartercc wrote:
> printf OUTFILE "$row[0]\t$row[1]\t$row[2]\t$row[3]\t$row[4]\t%d\n",
> $row[3] + $row[4];
That will break horribly if @row contains a '%' character.
Better use:
print OUTFILE join("\t", @row[0..4], $row[3] + $row[4]), "\n";
Or, if you must use printf to format the added column:
printf OUTFILE "%s\t%d\n", join("\t", @row[0..4]), $row[3] + $row[4];
Hope his helps,
-- HansM
------------------------------
Date: Wed, 14 Jan 2009 15:48:06 -0600
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: match text followed by number
Message-Id: <slrngmsncm.6un.tadmc@tadmc30.sbcglobal.net>
Tim Greer <tim@burlyhost.com> wrote:
> nick_keighley_nospam@hotmail.com wrote:
>> if (m/(.*) (\d+)$/)
>>
>> failed to match.
> Use non greedy matching with a wild card. (.*?) (\d+)$
Than cannot possibly have any effect.
Greediness does not matter here because this pattern is anchored.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Wed, 14 Jan 2009 16:15:45 -0800
From: Tim Greer <tim@burlyhost.com>
Subject: Re: match text followed by number
Message-Id: <Revbl.34857$Nv1.21792@newsfe03.iad>
Tad J McClellan wrote:
> Tim Greer <tim@burlyhost.com> wrote:
>> nick_keighley_nospam@hotmail.com wrote:
>
>>> if (m/(.*) (\d+)$/)
>>>
>>> failed to match.
>
>> Use non greedy matching with a wild card. (.*?) (\d+)$
>
>
> Than cannot possibly have any effect.
>
> Greediness does not matter here because this pattern is anchored.
>
>
I had meant in regard to the second example, actually (which used .*
\d*, and just wasn't paying attention earlier when I posted.
--
Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
Industry's most experienced staff! -- Web Hosting With Muscle!
------------------------------
Date: Wed, 14 Jan 2009 18:13:39 -0600
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: match text followed by number
Message-Id: <slrngmsvtj.8rc.tadmc@tadmc30.sbcglobal.net>
Tim Greer <tim@burlyhost.com> wrote:
> Tad J McClellan wrote:
>
>> Tim Greer <tim@burlyhost.com> wrote:
>>> nick_keighley_nospam@hotmail.com wrote:
>>
>>>> if (m/(.*) (\d+)$/)
>>>>
>>>> failed to match.
>>
>>> Use non greedy matching with a wild card. (.*?) (\d+)$
>>
>>
>> Than cannot possibly have any effect.
>>
>> Greediness does not matter here because this pattern is anchored.
>>
>>
>
> I had meant in regard to the second example, actually (which used .*
> \d*, and just wasn't paying attention earlier when I posted.
But that pattern was anchored too, so greediness still could
not have any possible effect.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Wed, 14 Jan 2009 17:13:48 -0800
From: Tim Greer <tim@burlyhost.com>
Subject: Re: match text followed by number
Message-Id: <h5wbl.49660$tD1.8835@newsfe07.iad>
Tad J McClellan wrote:
> Tim Greer <tim@burlyhost.com> wrote:
>> Tad J McClellan wrote:
>>
>>> Tim Greer <tim@burlyhost.com> wrote:
>>>> nick_keighley_nospam@hotmail.com wrote:
>>>
>>>>> if (m/(.*) (\d+)$/)
>>>>>
>>>>> failed to match.
>>>
>>>> Use non greedy matching with a wild card. (.*?) (\d+)$
>>>
>>>
>>> Than cannot possibly have any effect.
>>>
>>> Greediness does not matter here because this pattern is anchored.
>>>
>>>
>>
>> I had meant in regard to the second example, actually (which used .*
>> \d*, and just wasn't paying attention earlier when I posted.
>
>
> But that pattern was anchored too, so greediness still could
> not have any possible effect.
>
>
I wasn't clear. You're correct. I was indeed wrong. I was meaning
that I wasn't paying attention earlier, in that I quickly read it and
saw the mention of the greediness (all of the string in $1), yet I
didn't pay attention to the regex they posted or think about my reply.
Pardon, I'm having trouble making sense, it's been a long day...
--
Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
Industry's most experienced staff! -- Web Hosting With Muscle!
------------------------------
Date: Wed, 14 Jan 2009 23:45:19 +0100
From: Hans Mulder <hansmu@xs4all.nl>
Subject: Re: opening a file
Message-Id: <496e6c29$0$193$e4fe514c@news.xs4all.nl>
cartercc wrote:
> In my job, I constantly write and run scripts that open and close
> files. Many of these scripts are on-the-fly scripts. I've been at work
> for three hours today, and already I've written two of these kinds of
> scripts and have run around two dozen. Very rarely do I bother
> checking the return value of open(), and I don't ever recall having an
> open fail. The biggest problem I have is with typographical errors,
> and warnings catch those.
You could consider adding:
use Fatal qw/:void open close/;
to the boiler plate code at the top of every script. That will add an
"...or die" to every 'open' or 'close' command where the return value
isn't used. This gives you useful error messages without stroking keys.
Hope this helps,
-- HansM
------------------------------
Date: Wed, 14 Jan 2009 23:57:05 +0100
From: Mart van de Wege <mvdwege_public@myrealbox.com>
Subject: Re: opening a file
Message-Id: <86vdshcx8e.fsf@gareth.avalon.lan>
cartercc <cartercc@gmail.com> writes:
> This isn't a big deal. I often don't check the return value of open
> and I'm quite willing to accept the consequences. However, this only
> applies to scripts written for ME on MY system, and I know that system
> intimately. When I'm busy, I do this literally hundreds of times a
> week, perhaps (on a very long day) a hundred times a day. I know what
> I'm doing.
>
> On a philosophical note, OF COURSE (!) there are exceptions to every
> rule.
On a philosophical note, when it comes to programming, you *always*
check the outcome of *any* statement that interacts with outside data.
You're free to disregard that rule, like you are free to disregard
other rules, but you set yourself up for bugs and security
vulnerabilities if you do.
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
------------------------------
Date: Thu, 15 Jan 2009 00:30:29 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: opening a file
Message-Id: <slrngmstcl.k3m.hjp-usenet2@hrunkner.hjp.at>
On 2009-01-14 14:30, Chris Mattern <syscjm@sumire.gwu.edu> wrote:
> On 2009-01-14, cartercc <cartercc@gmail.com> wrote:
>> On Jan 10, 8:07 am, Tad J McClellan <ta...@seesig.invalid> wrote:
>>> You should always, yes *always*, check the return value from open():
>>
>> Like other ironclad rules, this also has exceptions. Using the 'or
>> die' construct has costs (albeit minimal) and when the costs outweigh
>> the benefit, you shouldn't use it. Example: opening the file is
>> tangential to the script so you don't care whether the file opens but
>
> If you don't care whether the file opens, why are you opening it?
> At the very least I think you'd need to know it didn't open so you
> don't attempt to do I/O with it.
I can think of one situation where you don't need to check whether the
open succeeded: When you try to open a file for reading and a
non-existent file is exactly equivalent to an empty file. Then
open(my $fh, '<', $optional_file);
while (<$fh>) {
# whatever
}
is fine from a purely functional point of view. But I'd still write that
as
if (open(my $fh, '<', $optional_file)) {
while (<$fh>) {
# whatever
}
}
just to assure the reader of the program (probably myself in six months)
that I haven't forgotten the check.
hp
------------------------------
Date: Thu, 15 Jan 2009 00:34:20 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: opening a file
Message-Id: <slrngmstjs.k3m.hjp-usenet2@hrunkner.hjp.at>
On 2009-01-14 15:27, cartercc <cartercc@gmail.com> wrote:
> On Jan 14, 9:30 am, Chris Mattern <sys...@sumire.gwu.edu> wrote:
>> If you don't care whether the file opens, why are you opening it?
>
> My point was that you can conjure up an exception for every rule.
>
> In my job, I constantly write and run scripts that open and close
> files. Many of these scripts are on-the-fly scripts. I've been at work
> for three hours today, and already I've written two of these kinds of
> scripts and have run around two dozen. Very rarely do I bother
> checking the return value of open(), and I don't ever recall having an
> open fail.
You have never, ever mistyped a file name, started a script in the wrong
directory or as the wrong user? You, sir, have my utmost admiration -
or you would have if I believed you, which I don't.
> The biggest problem I have is with typographical errors,
> and warnings catch those.
Warnings don't catch mistyped filenames. Checking the return value of
open does.
hp
PS: I recall that not so long ago you started a thread with the subject
"crisis perl".
------------------------------
Date: Wed, 14 Jan 2009 16:12:58 -0600
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: opening a file
Message-Id: <slrngmsora.6un.tadmc@tadmc30.sbcglobal.net>
cartercc <cartercc@gmail.com> wrote:
> The rule that every
> statement in Perl ends with a semicolon is a mandatory rule,
No it isn't.
It is in C. It is in Java.
It isn't in Perl.
In C, Java etc, the semicolon is a statement "terminator".
In Perl, the semicolon is a statement "separator".
The difference is subtle but is there nonetheless.
> and a
> script will throw a compile time error if we miss a semicolon.
This script won't:
----------------------
#!/usr/bin/perl
use warnings;
use strict;
# Look Ma! No semicolon...
print "Hello world\n"
# ... because the print() has no following statement to "separate"
----------------------
> For another example, consider warnings. One of my tasks is to process
> a file which may consists of several hundred thousand rows, totaling
> different kinds of values. When I run the script with warnings, I get
> an uninitialized value warning for every row printed to the screen,
> and the script takes a significant amount of time to run. When I run
> the script without warnings, the script runs quickly. To silence the
> warnings I can either (1) initialize a hash value for each row, or (2)
> run without warnings. I choose (2).
Actually, you can choose between
2a) run without warnings
2b) turn warnings off for the one line that is making warnings
that you don't care to see:
{ no warnings 'uninitialized';
print undef
}
(no semicolon yet again)
With 2b, you still get assistance from warnings everywhere else.
> Again, this isn't a big deal,
It is for people who know where the costs of software development are
(in maintenance).
As I said here once way back in '01:
I'm just some guy on Usenet, so feel free to ignore me, but
if you worked for me, you wouldn't work for me.
:-)
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Thu, 15 Jan 2009 00:52:36 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: opening a file
Message-Id: <slrngmsum5.k3m.hjp-usenet2@hrunkner.hjp.at>
On 2009-01-14 17:03, cartercc <cartercc@gmail.com> wrote:
> For another example, consider warnings. One of my tasks is to process
> a file which may consists of several hundred thousand rows, totaling
> different kinds of values. When I run the script with warnings, I get
> an uninitialized value warning for every row printed to the screen,
> and the script takes a significant amount of time to run. When I run
> the script without warnings, the script runs quickly.
Run-time is the least problem here. If your script spews out any
warnings (much less one warning for each line of useful output) during
normal operation, you are doing something wrong. How are you supposed to
notice the serious warnings if you always get a lot of spurious
warnings?
> To silence the warnings I can either (1) initialize a hash value for
> each row,
There are other ways. For example you can use the //, || or ?: operators
to use default values:
for (@keys) {
printf("%-15s %10.2f\n", $_, $values{$_} // 0;
}
> or (2) run without warnings. I choose (2).
You are throwing the baby out with the bath water. You can turn off
specific warnings for a specific scope:
use warnings;
...
for my $row (@rows) {
no warnings 'uninitialized';
# silently prints all undef values in @$row as ''
print join('\t', @$row), "\n";
}
hp
------------------------------
Date: 15 Jan 2009 01:05:08 GMT
From: xhoster@gmail.com
Subject: Re: opening a file
Message-Id: <20090114200739.617$ys@newsreader.com>
"Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
> On 2009-01-14 15:27, cartercc <cartercc@gmail.com> wrote:
> > On Jan 14, 9:30 am, Chris Mattern <sys...@sumire.gwu.edu> wrote:
> >> If you don't care whether the file opens, why are you opening it?
> >
> > My point was that you can conjure up an exception for every rule.
> >
> > In my job, I constantly write and run scripts that open and close
> > files. Many of these scripts are on-the-fly scripts. I've been at work
> > for three hours today, and already I've written two of these kinds of
> > scripts and have run around two dozen. Very rarely do I bother
> > checking the return value of open(), and I don't ever recall having an
> > open fail.
>
> You have never, ever mistyped a file name, started a script in the wrong
> directory or as the wrong user? You, sir, have my utmost admiration -
> or you would have if I believed you, which I don't.
I've done the first two. I don't recall doing the third. When I got
warnings about reads or writes on a closed filehandles, I immediately knew
that I screwed up, and it was pretty easy to figure out how. (Just as I
would have had I checked and warned on the return value of open.)
>
> > The biggest problem I have is with typographical errors,
> > and warnings catch those.
>
> Warnings don't catch mistyped filenames. Checking the return value of
> open does.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Wed, 14 Jan 2009 17:22:22 -0800
From: Tim Greer <tim@burlyhost.com>
Subject: Re: opening a file
Message-Id: <Kdwbl.49668$tD1.31866@newsfe07.iad>
xhoster@gmail.com wrote:
> I've done the first two.  I don't recall doing the third.  When I got
> warnings about reads or writes on a closed filehandles, I immediately
> knew that I screwed up, and it was pretty easy to figure out how.Â
> (Just as I would have had I checked and warned on the return value of
> open.)
>
I'd imagine it'd be easy enough to figure out in a lot of cases,
especially if you use unique filehandle names and such, but if you
didn't and the script grew, it could open the potential for problems to
crop up that weren't immediately obvious, though I still imagine it
wouldn't take very long to find the issue. I suppose the issue varies
upon the risk and how you're using data, how important that data is,
and how important the results are -- though probably none of those
things are technically going to increase by not checking the return
value, it could in some situations (but again, that would be due to
poor logic in the script anyway, but if we were all perfect, we'd not
need failures to be reported, let alone return values). I'm certain
people can (and have) created scripts without good checking that work
fine and may work fine indefinitely, but it's just easier to
intentionally put in checks and fail safes as you go along in my
opinion.
--
Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
Industry's most experienced staff! -- Web Hosting With Muscle!
------------------------------
Date: Wed, 14 Jan 2009 18:45:45 -0700
From: George <george@example.invalid>
Subject: Re: opening a file
Message-Id: <r4vgdptr8vci.mnajveycp8tz$.dlg@40tude.net>
On Thu, 15 Jan 2009 00:34:20 +0100, Peter J. Holzer wrote:
> On 2009-01-14 15:27, cartercc <cartercc@gmail.com> wrote:
>> On Jan 14, 9:30 am, Chris Mattern <sys...@sumire.gwu.edu> wrote:
>>> If you don't care whether the file opens, why are you opening it?
>>
>> My point was that you can conjure up an exception for every rule.
>>
>> In my job, I constantly write and run scripts that open and close
>> files. Many of these scripts are on-the-fly scripts. I've been at work
>> for three hours today, and already I've written two of these kinds of
>> scripts and have run around two dozen. Very rarely do I bother
>> checking the return value of open(), and I don't ever recall having an
>> open fail.
>
> You have never, ever mistyped a file name, started a script in the wrong
> directory or as the wrong user? You, sir, have my utmost admiration -
> or you would have if I believed you, which I don't.
>
>> The biggest problem I have is with typographical errors,
>> and warnings catch those.
>
> Warnings don't catch mistyped filenames. Checking the return value of
> open does.
>
> hp
>
> PS: I recall that not so long ago you started a thread with the subject
> "crisis perl".
A mistyped filename is precisely what I did starting out this thread, where
I had ehp instead of eph, and I was pulling my hair out.
I consider myself well-advised (by you and others) to use:
open(my $fh, '<', $filename) or die "cannot open $filename: $!";
--
George
Bring them on.
George W. Bush
Picture of the Day http://apod.nasa.gov/apod/
------------------------------
Date: Wed, 14 Jan 2009 18:50:31 -0700
From: George <george@example.invalid>
Subject: Re: opening a file
Message-Id: <1byouvy4tjp7i$.1dquqpnmf2hdq.dlg@40tude.net>
On Tue, 13 Jan 2009 18:49:16 -0800, Tim Greer wrote:
> Tim Greer wrote:
>
>> George wrote:
>>
>>> Whatever joke there was has clearly waned, but I have one more
>>> question about this material. Earlier you advised to use lexical
>>> filehandles, something like:
>>>
>>> open(my $fh, '<', $filename) or die "cannot open $filename: $!";
>>>
>>> In chapter one of the camel book in the filehandles section, it just
>>> uses:
>>>
>>> open(SESAME, "filename");
>>>
>>> How does this differ from
>>>
>>> open(my $SESAME, "filename");
>>>
>>> , and does it make a difference?
>>
>> The three argument method is simply the preferred way now. Things
>> evolve over time and this has become the preferred method for many.
>> There's really not a difference in a matter of speaking, it can just
>> make things easier down the road. Having an argument for the
>> redirection character can sometimes make you think about what you're
>> doing and specifically specify the redirect character you want to use.
>>
>> For example, instead of open(FILE, "file") or die $!, where it's
>> opening for 'read' by default, you tell it to specifically read open
>> my
>> $filehandle, '<', "filename" or die $!. I've seen a lot of people ask
>> why their files weren't updated and they didn't recall to add the
>> proper redirect character (>, >>, or whatever) to their open function.
>> You can use whichever you feel more confortable with. You should
>> still check if it was successful and report the failure (and why) if
>> not.
>
> I misspoke that there are really no differences, as there actually are,
> depending on the scenario. Also, I should have actually added more
> details about indirect file handles above. However, instead of
> repeating a few of the advantages to the three-argument open and
> indirect file handles, please refer to
> perldoc -f open (on the web at
> http://perldoc.perl.org/functions/open.html)
>
> As well as, you can get read up quickly at:
> http://perldoc.perl.org/perlopentut.html Specifically, refer to
> "Simple Opens" and the latter mentioned 3-argument version. Directly
> below is "Indirect Filehandles", which you should find of particular
> interest. These outline the differences, again depending on the
> scenario and provide all of the gory details.
Thanks, Tim, my fortran buddies were asking about this, and that link hits
the spot.
As OP, I'm done with this for this for now and am moving on to bigger and
better mistakes.:-0
--
George
Any government that supports, protects or harbours terrorists is complicit
in the murder of the innocent and equally guilty of terrorist crimes.
George W. Bush
Picture of the Day http://apod.nasa.gov/apod/
------------------------------
Date: Wed, 14 Jan 2009 14:07:42 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: set timeout module for Perl
Message-Id: <vcosm4hqj2oighf0s3iojk4oljr9k9mb4v@4ax.com>
Ted Zlatanov <tzz@lifelogs.com> wrote:
>Store the PID in a variable $pid.
No need for that, because ...
>Fork. Now you have processes A (parent, PID=$pid) and B (child)).
... the standard way to distinguish between parent and child is to check
the return value of fork(): childPID to the parent process and 0 to the
child process.
jue
------------------------------
Date: Thu, 15 Jan 2009 00:28:52 +0100
From: Hans Mulder <hansmu@xs4all.nl>
Subject: Re: set timeout module for Perl
Message-Id: <496e765d$0$192$e4fe514c@news.xs4all.nl>
Jürgen Exner wrote:
> Ted Zlatanov <tzz@lifelogs.com> wrote:
>> Store the PID in a variable $pid.
>
> No need for that, because ...
>
>> Fork. Now you have processes A (parent, PID=$pid) and B (child)).
>
> ... the standard way to distinguish between parent and child is to check
> the return value of fork(): childPID to the parent process and 0 to the
> child process.
Ted is storing the parent PID in a variable, so that the child knows
what process to send its signal to:
kill(USR1, $pid);
Of course he could also use the getppid function:
kill(USR1, getppid());
That might work better if his parent process has exited and the PID $pid
has been reassigned to a new process.
Hope this helps,
-- HansM
------------------------------
Date: Wed, 14 Jan 2009 15:44:06 -0800 (PST)
From: Anio <meneldor@gmail.com>
Subject: Re: set timeout module for Perl
Message-Id: <5d7d33f2-ed9a-4fc6-8846-8b0892e8463f@s9g2000prg.googlegroups.com>
On 14 =F1=CE, 22:09, Ted Zlatanov <t...@lifelogs.com> wrote:
> On Tue, 13 Jan 2009 06:00:51 -0800 (PST) Anio <menel...@gmail.com> wrote:
>
> A> Hi all, i need perl module for delay execution of code likesetTimeout
> A> (fn,ms) in Javascript does. Any suggestions?
>
> I saw the other followups, but here's a simple way:
>
> Store the PID in a variable $pid.
>
> Fork. =9ANow you have processes A (parent, PID=3D$pid) and B (child)).
>
> Do your action on the USR1 signal in A (usually this is done with
> setting a variable that you check elsewhere).
>
> In B, sleep for X milliseconds and then send the USR1 signal to the PID
> in $pid you remembered from before.
>
> Maybe this will help you if you want to avoid frameworks.
>
> Ted
Thanks for that. I tested it:
#########
my @lines =3D qw/foo bar baz/;
my @times =3D qw/0.2 0.25 0.34/;
for (my $i=3D0; $i<scalar @times; $i++) {
my $parent =3D $$;
unless (my $pid =3D fork()) {
select(undef, undef, undef, "$times[$i]");
kill "USR1",$parent;
exit();
}
}
$SIG{USR1} =3D sub {
print shift @lines, "\n"
};
<>; # to keep parent alive
###########
It work very good! But sometimes it exits with "User defined signal 1"
immediately and i cant understand why. Any ideas?
------------------------------
Date: Wed, 14 Jan 2009 16:56:13 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: set timeout module for Perl
Message-Id: <kc2tm49f94itl4fbdn5tstjj7358cbmfg6@4ax.com>
Hans Mulder <hansmu@xs4all.nl> wrote:
>Jürgen Exner wrote:
>> Ted Zlatanov <tzz@lifelogs.com> wrote:
>>> Store the PID in a variable $pid.
>>
>> No need for that, because ...
>>
>>> Fork. Now you have processes A (parent, PID=$pid) and B (child)).
>>
>> ... the standard way to distinguish between parent and child is to check
>> the return value of fork(): childPID to the parent process and 0 to the
>> child process.
>
>Ted is storing the parent PID in a variable, so that the child knows
>what process to send its signal to:
>
> kill(USR1, $pid);
Ok, I missed that. Thanks!
jue
------------------------------
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 2126
***************************************
