[26681] in Perl-Users-Digest
Perl-Users Digest, Issue: 8788 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Dec 23 00:05:31 2005
Date: Thu, 22 Dec 2005 21: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 Thu, 22 Dec 2005 Volume: 10 Number: 8788
Today's topics:
Re: Dynamic directory handles? <tadmc@augustmail.com>
Re: Dynamic directory handles? <tadmc@augustmail.com>
Exiting without printing <NoSPam@NoSpam.com>
Re: Exiting without printing xhoster@gmail.com
Re: Exiting without printing <NoSPam@NoSpam.com>
Re: Exiting without printing xhoster@gmail.com
Re: Exiting without printing <jurgenex@hotmail.com>
Re: Exiting without printing <tadmc@augustmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 22 Dec 2005 19:30:01 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Dynamic directory handles?
Message-Id: <slrndqmkop.85q.tadmc@magna.augustmail.com>
IanW <whoever@whereever.com> wrote:
> Must admit I get a bit lazy in CGI scripts
So CGI programming is a hobby for you rather than a profession?
Being lazy at your job is Not Good. :-)
> I've also never come across a directory or file that wouldn't
> open on any of my scripts..
I've never been in a car accident, so I don't need seat belts. Right?
> I was thinking of sth along those lines
s/sth/something/;
Please don't use "cutsie" spellings in Usenet posts.
It is inconsiderate of folks whose first language is not English.
>> next if $fl eq '.' or $fl eq '..';
>
> is there any reason for doing it that way over my original line using a
> regexp?
Yes, the same reason that you should be applying to all the code
you write: it is easier to read and understand.
Optimize for labor, optimize for labor, optimize for labor.
> is it a performance thing?
Yes, your maintenance programmer will perform better.
(and it will execute faster, but that is almost never a
valid consideration in this day and age.
)
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Thu, 22 Dec 2005 19:51:44 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Dynamic directory handles?
Message-Id: <slrndqmm1g.85q.tadmc@magna.augustmail.com>
IanW <whoever@whereever.com> wrote:
> "Tad McClellan" <tadmc@augustmail.com> wrote in message
> news:slrndqlck1.71n.tadmc@magna.augustmail.com...
>> 3) There is an already-invented (and tested) wheel for doing
>> recursive directory searching, the File::Find module.
>
> The only thing that sometimes puts me off using modules for relatively
> simple things like this, is that I wonder how much extra resources they use
> or whether they compromise performance in some way.
Cost to spend extra CPU cycles: $0.000001
Cost to develop code that saves those cycles: $1000.00
Your program will have to execute an awfully large number of
times for your approach to be economical.
Having a room full of programmers working on shaving off a few
cycles or bytes was commonplace in the '70s, but nowadays cycles
are cheap, RAM is cheap, what is expensive is your salary.
(though payday may make you argue that you are not expensive enough. :-)
> That is, File: Find must
> be quite a sizable module with a stack of function/options, so couldn't that
> mean lots more memory to run,
Does your application have to run on a cell phone or some other
place where RAM costs a premium?
> or is that an incorrect presumption?
It was correct 30 years ago, but it has changed due to Moore's Law.
>> If $fl is a symlink to a "higher" directory, then your
>> code will go into an infinite loop here.
>
> it's a script that will only run on my Windows servers, so that wasn't an
> issue
Windows does not have symbolic links?
> is there any particular reason you use
> single quotes there instead of double quotes?
Yes, I use single quotes unless I require one of the two extra
things (escapes and interpolation) that double quotes brings with it.
> I tend to use "" for pretty
> much everything.
Some strings contain variables, some strings don't.
During debugging, you are very often looking for variables.
You have to examine _every_ string, looking for variables.
I get to skip careful examination of many strings, because
they have been marked "no variables here" by the single quotes.
ie. it enables faster debugging.
> Also, I don't ever seem to use "||" - "or" would work as
> well in that scenario wouldn't it?
What happened when you tried it?
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Thu, 22 Dec 2005 20:48:45 -0500
From: "Daniel Kaplan" <NoSPam@NoSpam.com>
Subject: Exiting without printing
Message-Id: <1135302523.268749@nntp.acecape.com>
Hi All,
Can someone direct me to the proper perldoc file which explains the easiest
way to exit a Perl app?
I am writing a script that is run by the server once an hour, not via a web
browser. But a simple :
exit (0); //causes Perl app to fail
If I precede it with :
print $q->header();
print "";
Then everything is ok. Maybe it's nothing, but it just bothers me to have
to do this output which servers no purpose.
Thanks ahead,
Daniel
------------------------------
Date: 23 Dec 2005 02:21:20 GMT
From: xhoster@gmail.com
Subject: Re: Exiting without printing
Message-Id: <20051222212120.241$sz@newsreader.com>
"Daniel Kaplan" <NoSPam@NoSpam.com> wrote:
> Hi All,
>
> Can someone direct me to the proper perldoc file which explains the
> easiest way to exit a Perl app?
>
> I am writing a script that is run by the server once an hour, not via a
> web browser. But a simple :
That isn't very informative. Scripts are always run by a server, in some
sense of the word or another, and are almost never run by a web browser.
>
> exit (0); //causes Perl app to fail
What do you mean by "fail". What are the symptoms?
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Thu, 22 Dec 2005 21:35:16 -0500
From: "Daniel Kaplan" <NoSPam@NoSpam.com>
Subject: Re: Exiting without printing
Message-Id: <1135305317.326877@nntp.acecape.com>
<xhoster@gmail.com> wrote in message
news:20051222212120.241$sz@newsreader.com...
> That isn't very informative. Scripts are always run by a server, in some
> sense of the word or another, and are almost never run by a web browser.
You are correct, my apologies. What I meant wat, I have scripts that users
run from their browsers, in which case, printing something on exit is
needed, and required.
What I am talking about here is a script that my server runs itself every
hour (to clean up things, databases, etc.) .It's not from a browser,
therefore no output is needed.
As for failing I am talking the standard 500 error. Simply because I don't
print out something before hitting the exit (0) line.
Sorry about that.
------------------------------
Date: 23 Dec 2005 03:06:37 GMT
From: xhoster@gmail.com
Subject: Re: Exiting without printing
Message-Id: <20051222220637.974$Yt@newsreader.com>
"Daniel Kaplan" <NoSPam@NoSpam.com> wrote:
> <xhoster@gmail.com> wrote in message
> news:20051222212120.241$sz@newsreader.com...
>
> > That isn't very informative. Scripts are always run by a server, in
> > some sense of the word or another, and are almost never run by a web
> > browser.
>
> You are correct, my apologies. What I meant wat, I have scripts that
> users run from their browsers, in which case, printing something on exit
> is needed, and required.
>
> What I am talking about here is a script that my server runs itself every
> hour (to clean up things, databases, etc.) .It's not from a browser,
> therefore no output is needed.
>
> As for failing I am talking the standard 500 error. Simply because I
> don't print out something before hitting the exit (0) line.
A 500 error is not a perl error. If you are getting a 500 error, then
the server is not simply running the script itself. Is some other script
on the server using LWP or something to trigger itself to run a CGI script
by faking a web submission? If so, why?
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Fri, 23 Dec 2005 03:49:22 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: Exiting without printing
Message-Id: <6tKqf.51579$CL.4633@trnddc04>
Daniel Kaplan wrote:
> Can someone direct me to the proper perldoc file which explains the
> easiest way to exit a Perl app?
perldoc -f exit
> I am writing a script that is run by the server once an hour, not via
> a web browser. But a simple :
>
> exit (0); //causes Perl app to fail
I don't believe you.
There is just about no way that this command could cause a program to fail
by any reasonable definition of "fail".
> If I precede it with :
>
> print $q->header();
> print "";
>
> Then everything is ok. Maybe it's nothing, but it just bothers me
> to have to do this output which servers no purpose.
I cannot repro your problem:
C:\tmp>type t.pl
use strict;
use warnings;
#do whatever you please
exit (0);
C:\tmp>t.pl
C:\tmp>
Obviously t.pl did not fail.
Please post a minimal but complete program that demonstrates the problem.
Also, please be more precise in describing in what you expect to happen
versus the actual behaviour of the program. Saying "it fails" is about as
informative as saying "my car doesnt' run" and can have just about as many
reasons from missing gas to a broken transmission or flat tires.
jue
------------------------------
Date: Thu, 22 Dec 2005 22:34:45 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Exiting without printing
Message-Id: <slrndqmvj5.8e2.tadmc@magna.augustmail.com>
Daniel Kaplan <NoSPam@NoSpam.com> wrote:
> Hi All,
Hrrmph.
> Can someone direct me to the proper perldoc file which explains the easiest
> way to exit a Perl app?
perldoc -f exit
> I am writing a script that is run by the server once an hour,
"the server" is what kind of server? FTP server? SMTP server?
How is the program initiated? Via a cron job or some such?
> not via a web
> browser.
Oh, it is probably an HTTP server (ie. webserver) then?
> But a simple :
>
> exit (0); //causes Perl app to fail
No it doesn't.
It cause the Perl app to exit with a zero exit code, which indicates
success. Exiting with a non-zero exit code indicates failure.
So, it must be something other than the Perl app that is failing
at this point. Maybe you have not partitioned the problem correctly?
> If I precede it with :
>
> print $q->header();
> print "";
>
> Then everything is ok.
This has much more to do with how your web server is configured
than with Perl.
You have a much better chance of getting help if you ask
where they talk about web server configuration, instead of here.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
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 8788
***************************************
