[30879] in Perl-Users-Digest
Perl-Users Digest, Issue: 2124 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jan 14 11:14:23 2009
Date: Wed, 14 Jan 2009 08:14:16 -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: 2124
Today's topics:
Re: opening a file <cartercc@gmail.com>
Re: opening a file <syscjm@sumire.gwu.edu>
Re: opening a file <cartercc@gmail.com>
Re: opening a file <tadmc@seesig.invalid>
Re: unable to open file <tadmc@seesig.invalid>
Using exec() <bill@ts1000.us>
Re: Using exec() <joost@zeekat.nl>
Re: Using exec() <syscjm@sumire.gwu.edu>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 14 Jan 2009 05:33:32 -0800 (PST)
From: cartercc <cartercc@gmail.com>
Subject: Re: opening a file
Message-Id: <fccd7c7f-bd1b-4cba-a836-f199b3f1d1a6@k36g2000pri.googlegroups.com>
On Jan 10, 8:07=A0am, 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
------------------------------
Date: Wed, 14 Jan 2009 08:30:04 -0600
From: Chris Mattern <syscjm@sumire.gwu.edu>
Subject: Re: opening a file
Message-Id: <slrngmrtnc.plm.syscjm@sumire.gwu.edu>
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.
> you DO care if the script dies.
Not every instance of checking what open() returns is done with "or die".
If you don't want the script to die, don't. But it is difficult in the
extreme to visualize a case where whether or not a file opened makes absolutely
no difference in what the rest of the script needs to do.
--
Christopher Mattern
NOTICE
Thank you for noticing this new notice
Your noticing it has been noted
And will be reported to the authorities
------------------------------
Date: Wed, 14 Jan 2009 07:27:12 -0800 (PST)
From: cartercc <cartercc@gmail.com>
Subject: Re: opening a file
Message-Id: <5e18a38a-4301-45a9-8050-e9d6efdfa4f4@q37g2000vbn.googlegroups.com>
On Jan 14, 9:30=A0am, 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
------------------------------
Date: Wed, 14 Jan 2009 09:43:00 -0600
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: opening a file
Message-Id: <slrngms204.2ia.tadmc@tadmc30.sbcglobal.net>
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.
I have never seen one (even after reading all of your post).
> Using the 'or
> die' construct
The "check the return value" part was meant to be ironclad.
The "what action to take part" (eg. die) was not meant to be ironclad.
If die() is not what you want to do when the open failed, then
replace it with code that does do what you want.
> has costs (albeit minimal) and when the costs outweigh
> the benefit, you shouldn't use it.
I submit that the costs never outweigh the benefit.
You are free to disagree.
> 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.
I assume that your program is going to read or write from the
unopened filehandle?
If not, then why call open() at all?
If so, then your program will spew superfluous warnings, potentially
masking real warnings. (and if you are programming without warnings
enabled, then you deserve any pain you receive.)
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...
> It's true that in the vast majority of cases a prudent script will
> perform error checking for open(),
I still have not seen a single exception...
> but it's also true that one
> shouldn't follow the rule blindly forgetting the purpose and the
> effects of error checking.
I cannot envision where blindly following my original advice
is unwarranted.
Which is exactly why I state it the way I do.
I've had this discussion many times before...
If it is ever disproved, then I'll change how I state it.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Wed, 14 Jan 2009 05:18:58 -0600
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: unable to open file
Message-Id: <slrngmrih2.v1a.tadmc@tadmc30.sbcglobal.net>
Ken Teague <"kteague at pobox dot com"> wrote:
> Jürgen Exner wrote:
>> Ask perl to tell you why it can't open the file:
>> open(F, $_[0]) or error("Can't open file $_[0] because $! !");
>
>
> Thanks, Jue. "No such file or directory", which seems to lead to what
> Jim is hinting to me in his follow-up reply.
>
> Jim Gibson wrote:
>> Try adding the full path to prodscript.html to the $HTML_template
>> variable. It is likely that the default directory is not the cgi-bin
>> directory when the Perl script executes.
>
> Thanks, Jim. After adding the extra code that Jue recommended, it looks
> like you're right. As far as adding the full path, I tried different
> variations of paths without luck:
> * full windows file system path
That should work.
> * full HTML path (/cgi-bin/prodscript.html and /htdocs/prodscript.html)
That has no chance of working. A URI (URL) is not a filepath at all.
> * relative path (./prodscript.html and .\prodscript.html)
That should be able to work, if your cwd is set correctly.
> Which path would it want? The HTML path or file system path?
A filesystem path.
> Is there
> a way I could avoid absolute paths? I tend to think they're evil in
> source.
It appears that your program has some other current working directory.
You need to find out what it is, or chdir() to a known location if
relative paths are to work.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Wed, 14 Jan 2009 06:17:38 -0800 (PST)
From: Bill H <bill@ts1000.us>
Subject: Using exec()
Message-Id: <baa56dd9-b861-43ed-88b0-822ef0dcd05d@h5g2000yqh.googlegroups.com>
According to the perldoc exec() never returns when it is called, 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.
The way I want to use it is I have a script that uses PDF::API to make
a pdf based on user input, then using imagemagik it makes viewable
jpgs out of the pages. What I want to do, is when the script has
completed the above, I want to start another program that combines
pdf's that have been made for latter viewing, but don't want the user
to have to wait for it. 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?
Bill H
------------------------------
Date: Wed, 14 Jan 2009 15:23:58 +0100
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: Using exec()
Message-Id: <877i4ym0e9.fsf@zeekat.nl>
Bill H <bill@ts1000.us> writes:
> According to the perldoc exec() never returns when it is called, 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.
exec() replaces the current process by the new one. The only time the
"calling script" will continue is if the exec() call fails. If exec
succeeds there is no "calling script" anymore.
> The way I want to use it is I have a script that uses PDF::API to make
> a pdf based on user input, then using imagemagik it makes viewable
> jpgs out of the pages. What I want to do, is when the script has
> completed the above, I want to start another program that combines
> pdf's that have been made for latter viewing, but don't want the user
> to have to wait for it. 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?
Not on its own, no. You probably want some combination of fork() and
exec(). What I personally tend to do is
system("/some/function bla bla &") and die;
to start a program in the background.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: Wed, 14 Jan 2009 08:40:27 -0600
From: Chris Mattern <syscjm@sumire.gwu.edu>
Subject: Re: Using exec()
Message-Id: <slrngmruar.plm.syscjm@sumire.gwu.edu>
On 2009-01-14, Bill H <bill@ts1000.us> wrote:
> According to the perldoc exec() never returns when it is called, 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.
Roughly speaking, it stops (actually, what happens is the command you
exec()'d *replaces* your script. The script ceases to exist as a program
being executed and the process loads the new program in its place and
starts it executing. That's why exec() never returns; the act of calling
it causes the program that called it to disappear.)
>
> The way I want to use it is I have a script that uses PDF::API to make
> a pdf based on user input, then using imagemagik it makes viewable
> jpgs out of the pages. What I want to do, is when the script has
> completed the above, I want to start another program that combines
> pdf's that have been made for latter viewing, but don't want the user
> to have to wait for it. 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. The calling script will go away when it calls exec(). That's what
exec() does. You probably want to use system() but you'll need to run
a command that spawns in the background if you don't want your script to
wait for child process to end. Alternatively, you could fork() to make
a new process and then exec() in the new process to run the command you
want (which is what system() does under the covers for you anyways).
--
Christopher Mattern
NOTICE
Thank you for noticing this new notice
Your noticing it has been noted
And will be reported to the authorities
------------------------------
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 2124
***************************************
