[30880] in Perl-Users-Digest
Perl-Users Digest, Issue: 2125 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jan 14 16:09:42 2009
Date: Wed, 14 Jan 2009 13:09:09 -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: 2125
Today's topics:
Re: Add columns of a File <someone@example.com>
Re: match text followed by number <tim@burlyhost.com>
Re: opening a file <tim@burlyhost.com>
Re: opening a file <cartercc@gmail.com>
Re: opening a file <tim@burlyhost.com>
Re: opening a file <jurgenex@hotmail.com>
Re: opening a file <tim@burlyhost.com>
Re: opening a file <tim@burlyhost.com>
Re: opening a file <cartercc@gmail.com>
Re: opening a file <cwilbur@chromatico.net>
Re: opening a file <tim@burlyhost.com>
Re: set timeout module for Perl <tzz@lifelogs.com>
Re: The single biggest STUPIDITY in Perl ... <g_m@remove-comcast.net>
Re: Using exec() <jurgenex@hotmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 14 Jan 2009 09:15:25 -0800
From: "John W. Krahn" <someone@example.com>
Subject: Re: Add columns of a File
Message-Id: <O4pbl.25813$Jy.1183@newsfe06.iad>
Rajpreet wrote:
>
> I am fairly new to perl. I have a sample file and need to add file 4th
> and 5th column and create a column with this new value. Something like
> below
>
> Sample File:
>
> 123456 12345 1234 123
> 12 135 ---- This is addition of 4th and 5th column
> 789 789 789
> 78 7 85
>
> I need to either put the new column in the same file
perl -i -lape'$_.="\t".($F[3]+$F[4])' yourfile
> or create a new file with the above format.
perl -lape'$_.="\t".($F[3]+$F[4])' yourfile > new_file
John
--
Those people who think they know everything are a great
annoyance to those of us who do. -- Isaac Asimov
------------------------------
Date: Wed, 14 Jan 2009 09:20:56 -0800
From: Tim Greer <tim@burlyhost.com>
Subject: Re: match text followed by number
Message-Id: <Y9pbl.36707$JA5.2392@newsfe08.iad>
nick_keighley_nospam@hotmail.com wrote:
> I'm trying to match lines that consist of text with a number at the
> end
>
> Migration reject cause 4
>
> and I tried this
>
> if (m/(.*) (\d*)$/)
> {
> print "\$1 is $1 \$2 is $2\n";
> }
>
> $1 matched the whole line including the number
>
> if (m/(.*) (\d+)$/)
>
> failed to match. Is there a way to get something to match the text
> and the number seperatly?
>
> --
> Nick keighley
Use non greedy matching with a wild card. (.*?) (\d+)$ Are you sure
the end of the string is a digit, and it's preceded by a white space?
--
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 09:02:40 -0800
From: Tim Greer <tim@burlyhost.com>
Subject: Re: opening a file
Message-Id: <RUobl.36703$JA5.8026@newsfe08.iad>
cartercc 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
> you DO care if the script dies.
>
> It's true that in the vast majority of cases a prudent script will
> perform error checking for open(), but it's also true that one
> shouldn't follow the rule blindly forgetting the purpose and the
> effects of error checking.
>
> CC
Right, but checking the return value doesn't mean to die if it fails to
open. It just means to not start processing data that might not exist
(for one of many examples). Checking the return value could result in
many different ways of dealing with the following code and what you're
doing. Of course, in this case of the OP, this was a very specific
thing, because they needed that data and didn't know why it wasn't
opening. I'd imagine you always have a reason to check the return
value in any program, in any situation, and you just deal with the
results one way or the other (whatever is most appropriate). Sometimes
that's to die, and sometimes it'll skip the following code logic that
would have processed some data, or any number of logistical reasoning.
--
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 09:03:42 -0800 (PST)
From: cartercc <cartercc@gmail.com>
Subject: Re: opening a file
Message-Id: <55444082-f1e1-4042-97b3-547907ce2c26@b1g2000yqg.googlegroups.com>
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. Please note that by 'rule' I refer to discretionary behavior
that we generally refer to as 'good practice'. The rule that every
statement in Perl ends with a semicolon is a mandatory rule, and a
script will throw a compile time error if we miss a semicolon.
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).
Again, this isn't a big deal, and I TOTALLY AGREE that the return
value for open() should generally be checked, and that warnings should
generally be enables. However, for the reasons I stated, I often don't
do this, and I am perfectly willing to accept the consequences.
CC
------------------------------
Date: Wed, 14 Jan 2009 09:07:06 -0800
From: Tim Greer <tim@burlyhost.com>
Subject: Re: opening a file
Message-Id: <_Yobl.36704$JA5.17972@newsfe08.iad>
cartercc 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. The biggest problem I have is with typographical errors,
> and warnings catch those.
>
> I totally agree with error checking, and the scripts that I write for
> others to run ALWAYS include this kind of error checking. The scripts
> that I write FOR MYSELF for processing files rarely do, however,
> because open() never fails and I'm too lazy to take the extra effort
> (small though it may be) to type out the 'or die' clause. My quibble
> is not with the rule, but with the idea that the rule has no
> exceptions. Every rule has exceptions.
>
> If it's any consolation, I am the only one that suffers the penalty
> for not checking whether or not a file opens in my own scripts, and I
> am perfectly willing to risk incurring the penalty to keep from typing
> a few extra keystrokes with every invocation of open. This is a
> deliberate choice on my part, and I have never sought to impose that
> choice on anyone else.
>
> CC
I suppose you're aware then, that if it did fail on a file that you did
need data from, that you would spend more than the 1 second a warn, die
or method you create to note the problem, and start digging through the
file, adding the checks, only when it does fail. If you didn't make a
typo and the file exists and is readable, then yeah, you'll probably
never have a problem. But, the same is true of checking the return.
You still would never have a problem and never see it die, warn or log
an error -- even if it silently ignores it (due to the return value)
and moves on fine, in a friendly manner. I couldn't imagine how it's
really saving any time at all by not adding a simple check. If
anything, create some very simple module or library and use that for
the open routines on all of your scripts, even if to just log and
happily and blindly move on (because yeah, sometimes it's okay to just
keep moving). Anyway, it's certainly up to you if it's just your code
and you affected.
--
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 09:05:39 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: opening a file
Message-Id: <1e6sm4hckfvvas1uag2rsr2tsaipop1qtb@4ax.com>
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)
Cost in terms of what? In terms of execution time or memory should be
negligable except in very extreme cases, in particular because accessing
the file system is so expensive on the OS side anyway that you will
probably have difficulties even measuring the additional cost of die().
>and when the costs outweigh the benefit, you shouldn't use it.
Of course.
>Example: opening the file is
>tangential to the script so you don't care whether the file opens but
>you DO care if the script dies.
Then don't use die() but some other appropriate error handling, maybe
logging the even or whatever is suitable for that situation.
>It's true that in the vast majority of cases a prudent script will
>perform error checking for open(), but it's also true that one
>shouldn't follow the rule blindly forgetting the purpose and the
>effects of error checking.
Fair enough. But I still can't imagine a situation where you wouldn't
care about the success of an open() call.
jue
------------------------------
Date: Wed, 14 Jan 2009 09:10:51 -0800
From: Tim Greer <tim@burlyhost.com>
Subject: Re: opening a file
Message-Id: <y0pbl.8401$1k1.6501@newsfe14.iad>
Tad J McClellan wrote:
> At a minimum, you need to check before using the filehandle. eg:
>
> # log stuff if we can:
> if (open my $log, '>>', '/tmp/logfile' ) {
> print $log "some logged info here\n"
> }
> # never use $log below here...
And, for the sake of clarity, that above example _is_ checking the
return value with if (open...), before it continues working with the
data, so I can't help but agree with Tad. I absolutely can't imagine
how you'd do this otherwise, unless you want to run the risk of open
(my $fileh, '<', $filename); and then just start blindly working with
$fileh. That seems more than a preference, but a high risk. If you
know you don't make mistakes typing, ever, and you know the files are
always there, always readable and their data and its output and your
scripts are trivial, then go for it.
--
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 09:19:08 -0800
From: Tim Greer <tim@burlyhost.com>
Subject: Re: opening a file
Message-Id: <h8pbl.36706$JA5.25106@newsfe08.iad>
cartercc wrote:
> 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.
I don't think anyone's upset if you do this yourself on your own systems
for your own scripts, and it doesn't affect anyone else. Still, it
doesn't seem like a good idea out of laziness or being busy. Checking
the return of open should actually save you time in every case, so it
just seems strange you'd not _want_ to do it. Of course, if you choose
not to, that's cool, since you don't seem to do it that way for other
people.
Still, you replied to the thread saying what appeared to suggest that
not everyone should check the return value in every case. I don't
imagine any circumstance or reason in a single case not to, and it
should even save time and hassles. If you just meant to not use
something nasty like die(), then that's completely valid, though one
really should never have a reason not to check the return value.
Saying you know you should, but don't always do it or want to, is
another thing, but it just seemed that you were suggesting it and it
struck me as odd for that reason.
> 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).
There is probably a better way to do it, where you're not having to
initialize each row (but that's just a guess without seeing the
script). Sometimes things here or there can be annoying and you can
save time, but when you do that, I don't know that you could ever trust
the output of the script when it all comes down to it, and in which
case why take the time to create the script or run it, unless you're
just doing something for a general idea or rough estimate of the
output?
> Again, this isn't a big deal, and I TOTALLY AGREE that the return
> value for open() should generally be checked, and that warnings should
> generally be enables. However, for the reasons I stated, I often don't
> do this, and I am perfectly willing to accept the consequences.
>
I think people would disagree about it not being a big deal, but I also
don't think anyone minds how you run your own personal scripts. I've
never seen anyone that didn't make a goof in their code at some point,
and I'd prefer to have something catch it right away. I really can't
say I agree there are reasons, but to each their own.
--
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 09:33:07 -0800 (PST)
From: cartercc <cartercc@gmail.com>
Subject: Re: opening a file
Message-Id: <101f2819-d820-4614-81fa-72128b22b2d1@g38g2000yqd.googlegroups.com>
On Jan 14, 12:05=A0pm, J=FCrgen Exner <jurge...@hotmail.com> wrote:
> Fair enough. But I still can't imagine a situation where you wouldn't
> care about the success of an open() call.
I processed a file yesterday where I broke the input file into four
output files. In doing so, I wrote intermediate values to four
intermediate files simply for the sake of a sanity check. The output
was perfect, and I never looked at or even opened the intermediate
files. Yes, I could have checked to see if they had been opened and
all that, and if I had had a problem I certainly would have.
I'm not advocating not doing all the error checking, opening files,
warnings, and all that. All I'm saying is that IMO when you're writing
throw away scripts for your own convenience, a little sloppiness can
be excused ... not justified, but only excused. To be fair, I started
off doing the file open error checking, and only slipped into some
shortcuts after writing a lot of scripts. Again, in my work, I know
immediately when something doesn't work, like a typo in a file name --
but the consequence is the same: a file not existing or being empty
means a mistake, and it doesn't take any more effort to fix the
problem in one case or another.
Again, when I write scripts for others, I don't use shortcuts (which
also includes documentation of variables, functions, etc.)
CC
------------------------------
Date: Wed, 14 Jan 2009 13:50:53 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: opening a file
Message-Id: <86r6353enm.fsf@mithril.chromatico.net>
>>>>> "TG" == Tim Greer <tim@burlyhost.com> writes:
TG> cartercc wrote:
>> Again, this isn't a big deal, and I TOTALLY AGREE that the return
>> value for open() should generally be checked, and that warnings
>> should generally be enables. However, for the reasons I stated, I
>> often don't do this, and I am perfectly willing to accept the
>> consequences.
TG> I think people would disagree about it not being a big deal, but
TG> I also don't think anyone minds how you run your own personal
TG> scripts. I've never seen anyone that didn't make a goof in
TG> their code at some point, and I'd prefer to have something catch
TG> it right away. I really can't say I agree there are reasons,
TG> but to each their own.
More to the point, if you're posting to a newsgroup to ask a small group
of experts to debug your code, it's essential that you have done
everything you can to find the bug yourself.
This means that if there's an open call, you check the return value.
This means that you have use strict; and use warnings; right after the
shebang line.
If you are enough of an experienced Perl programmer to never ever need
help, you can do whatever you like with the result of your open calls.
But for the rest of us lesser mortals, any way we can automatically find
our mistakes without having to post to an audience of thousands is a
good thing.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Wed, 14 Jan 2009 11:42:44 -0800
From: Tim Greer <tim@burlyhost.com>
Subject: Re: opening a file
Message-Id: <Verbl.11024$qi.9845@newsfe09.iad>
Charlton Wilbur wrote:
>>>>>> "TG" == Tim Greer <tim@burlyhost.com> writes:
>
> TG> cartercc wrote:
>
> >> Again, this isn't a big deal, and I TOTALLY AGREE that the
> >> return value for open() should generally be checked, and that
> >> warnings should generally be enables. However, for the reasons
> >> I stated, I often don't do this, and I am perfectly willing to
> >> accept the consequences.
>
> TG> I think people would disagree about it not being a big deal,
> but TG> I also don't think anyone minds how you run your own
> personal
> TG> scripts. I've never seen anyone that didn't make a goof in
> TG> their code at some point, and I'd prefer to have something
> catch
> TG> it right away. I really can't say I agree there are reasons,
> TG> but to each their own.
>
> More to the point, if you're posting to a newsgroup to ask a small
> group of experts to debug your code, it's essential that you have done
> everything you can to find the bug yourself.
>
> This means that if there's an open call, you check the return value.
> This means that you have use strict; and use warnings; right after the
> shebang line.
>
> If you are enough of an experienced Perl programmer to never ever need
> help, you can do whatever you like with the result of your open calls.
> But for the rest of us lesser mortals, any way we can automatically
> find our mistakes without having to post to an audience of thousands
> is a good thing.
>
> Charlton
>
>
Good points, but in fairness (and I might have missed it), carter is
simply saying he doesn't for his own code. I don't think they actually
would post code without checks either if they were posting for help or
posting an answer. I get what he's saying, I just don't know that I
agree that there's ever a reason to save a few seconds of time for the
sake of it being your own code you're sure about, even if it's trivial
data its working with. Copy and paste the simple check (whatever that
might be) and you get the best of both worlds. But, that's just my
view.
--
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 14:09:23 -0600
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: set timeout module for Perl
Message-Id: <864p01myz0.fsf@lifelogs.com>
On Tue, 13 Jan 2009 06:00:51 -0800 (PST) Anio <meneldor@gmail.com> wrote:
A> Hi all, i need perl module for delay execution of code like setTimeout
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. Now you have processes A (parent, PID=$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
------------------------------
Date: Wed, 14 Jan 2009 13:41:28 -0500
From: "~greg" <g_m@remove-comcast.net>
Subject: Re: The single biggest STUPIDITY in Perl ...
Message-Id: <9L2dneGolbfmrPPUnZ2dnUVZ_oTinZ2d@giganews.com>
"jps" > ...
> Well... Objects are a GOOOOD thing.
> References are a BAAAAAAAAAAAAAAAAAAAD thing.
My understanding is that scalars are always implicitly
passed by reference anyway, unless, or until, their value
is altered.
And I'm sure that perl has done the right thing, inspite of me,
more often than I'd care to admit,
It's just my hubris that I'd like to have a feeling
of at least the possibility of being able to exercise
more definite, simple and clear control over everything.
The kind of rush you can get from C or C++.
~~
At the moment, in my opinion, the way perl handles
unicode -- its utf8 flag usage etc -- is the worst thing about it.
But I hope to be able to take that back soon.
I hope to be able to say, authoritatively,
that it's the way that the-way-that-perl-handles-unicode
is explained, that's the worst thing about it.
------------------------------
Date: Wed, 14 Jan 2009 09:12:06 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Using exec()
Message-Id: <0v6sm49hpk4i7rirnaf6dce9qjgvm050kt@4ax.com>
Bill H <bill@ts1000.us> wrote:
>According to the perldoc exec() never returns when it is called,
No. It never returns if the call was successfull. That is different.
>which
>is fine, but I can't see anywhere if the calling script will continue
>on or does it stop when you do the exec.
Well, if the call doesn't return, then how could the script continue?
In any case, what happens behind the scenes is that your Perl code is
being replaced(!) by the called external program and the process starts
executing that new code.
>Will the exec let me start another perl script
>but allow the calling script to finish up and exit as if it had never
>called an exec?
No. exec() replaces the code and the old code is gone. I think you may
be looking for system() instead of for exec().
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 2125
***************************************
