[12640] in Perl-Users-Digest
Perl-Users Digest, Issue: 49 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jul 7 08:47:20 1999
Date: Wed, 7 Jul 1999 05:37:28 -0700 (PDT)
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, 7 Jul 1999 Volume: 9 Number: 49
Today's topics:
Stat Function and File Test Operators <troyknight@troyknight.eurobell.co.uk>
Re: Stat Function and File Test Operators (Iain Chalmers)
Re: Stat Function and File Test Operators <troyknight@troyknight.eurobell.co.uk>
Re: Stat Function and File Test Operators (I R A Aggie)
Re: Stat Function and File Test Operators (Randal L. Schwartz)
Re: Stat Function and File Test Operators <troyknight@troyknight.eurobell.co.uk>
Re: Stat Function and File Test Operators (Dave Till)
Re: Stat Function and File Test Operators <uri@sysarch.com>
Re: Stat Function and File Test Operators (Dave Till)
Re: Stat Function and File Test Operators <uri@sysarch.com>
Re: Stat Function and File Test Operators <troyknight@troyknight.eurobell.co.uk>
Re: Stat Function and File Test Operators <uri@sysarch.com>
Re: Stat Function and File Test Operators (Ronald J Kimball)
Re: Stat Function and File Test Operators <uri@sysarch.com>
Re: Stat Function and File Test Operators (Dave Till)
stat() for local item? <laughingotter@foxinternet.net>
Re: stat() for local item? <cassell@mail.cor.epa.gov>
Re: stat() for local item? (Abigail)
Re: stat() for local item? (Philip 'Yes, that's my address' Newton)
Digest Administrivia (Last modified: 1 Jul 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 5 Jul 1999 10:19:46 +0100
From: "Troy Knight" <troyknight@troyknight.eurobell.co.uk>
Subject: Stat Function and File Test Operators
Message-Id: <7lpt70$2nn1$1@slrn.eurobell.net>
Why do these give different answers?
1) $file = "some file";
@stats = stat $file;
print @stats[9];
2) $file = "some file";
print -M $file;
I thought that these were BOTH meant to print out the last time modified in
seconds since Jan 1st 1970, but they don't. The first one gets it right, but
the second gives a number something like 0.5something.
Also, what is the last accessed file stat returned from the stat function? I
thought it would give the last time accessed, but it again gives the
beginning of that day in seconds when I know I have accessed it through my
web browser and through my text editor after that.
Thanks for any help.
------------------------------
Date: Mon, 05 Jul 1999 19:31:01 +1000
From: bigiain@mightymedia.com.au (Iain Chalmers)
Subject: Re: Stat Function and File Test Operators
Message-Id: <bigiain-0507991931010001@bigman.mighty.aust.com>
In article <7lpt70$2nn1$1@slrn.eurobell.net>, "Troy Knight"
<troyknight@troyknight.eurobell.co.uk> wrote:
> Why do these give different answers?
>
> 1) $file = "some file";
> @stats = stat $file;
> print @stats[9];
>
> 2) $file = "some file";
> print -M $file;
>
> I thought that these were BOTH meant to print out the last time modified in
> seconds since Jan 1st 1970, but they don't. The first one gets it right, but
> the second gives a number something like 0.5something.
so the first thing you did was to read the documentation of both functions
in perlfunc, where it says:
" -M Age of file in days when script started."
and
" 9 mtime last modify time since the epoch"
so that you wouldnt end up telling the whole world that "you thought"
wrong, right?
HTH HAND
Iain
------------------------------
Date: Mon, 5 Jul 1999 10:56:22 +0100
From: "Troy Knight" <troyknight@troyknight.eurobell.co.uk>
Subject: Re: Stat Function and File Test Operators
Message-Id: <7lpvbk$2nol$1@slrn.eurobell.net>
Iain Chalmers <bigiain@mightymedia.com.au> wrote in message
news:bigiain-0507991931010001@bigman.mighty.aust.com...
> In article <7lpt70$2nn1$1@slrn.eurobell.net>, "Troy Knight"
> <troyknight@troyknight.eurobell.co.uk> wrote:
>
> > Why do these give different answers?
> >
> > 1) $file = "some file";
> > @stats = stat $file;
> > print @stats[9];
> >
> > 2) $file = "some file";
> > print -M $file;
> >
> > I thought that these were BOTH meant to print out the last time modified
in
> > seconds since Jan 1st 1970, but they don't. The first one gets it right,
but
> > the second gives a number something like 0.5something.
>
> so the first thing you did was to read the documentation of both functions
> in perlfunc, where it says:
>
> " -M Age of file in days when script started."
>
> and
>
> " 9 mtime last modify time since the epoch"
>
> so that you wouldnt end up telling the whole world that "you thought"
> wrong, right?
Hey, sorry man. Will do next time. I am just reading from a perl book (Teach
Yourself Perl In 21 days).
>
> HTH HAND
>
> Iain
------------------------------
Date: 5 Jul 1999 13:31:55 GMT
From: fl_aggie@thepentagon.com (I R A Aggie)
Subject: Re: Stat Function and File Test Operators
Message-Id: <slrn7o1d2m.tac.fl_aggie@thepentagon.com>
On Mon, 5 Jul 1999 10:56:22 +0100, Troy Knight
<troyknight@troyknight.eurobell.co.uk>, in
<7lpvbk$2nol$1@slrn.eurobell.net> wrote:
+ Hey, sorry man. Will do next time. I am just reading from a perl book (Teach
+ Yourself Perl In 21 days).
Is that Till's book? or is it a more recent copy where Sams brought on
a second author?
Till's book is a bit buggy...
James
------------------------------
Date: 05 Jul 1999 08:57:57 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: Stat Function and File Test Operators
Message-Id: <m1908vozqy.fsf@halfdome.holdit.com>
>>>>> "Troy" == Troy Knight <troyknight@troyknight.eurobell.co.uk> writes:
Troy> Hey, sorry man. Will do next time. I am just reading from a perl
Troy> book (Teach Yourself Perl In 21 days).
Ugh. Please read <URL:http://xenu.phys.uit.no/~tom/TYP21D.html>
before you mess up your life any further.
print "Just another Perl hacker,"
--
Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying
Email: <merlyn@stonehenge.com> Snail: (Call) PGP-Key: (finger merlyn@teleport.com)
Web: <A HREF="http://www.stonehenge.com/merlyn/">My Home Page!</A>
Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me
------------------------------
Date: Mon, 5 Jul 1999 18:08:04 +0100
From: "Troy Knight" <troyknight@troyknight.eurobell.co.uk>
Subject: Re: Stat Function and File Test Operators
Message-Id: <7lqol2$2odk$1@slrn.eurobell.net>
Randal L. Schwartz <merlyn@stonehenge.com> wrote in message
news:m1908vozqy.fsf@halfdome.holdit.com...
> >>>>> "Troy" == Troy Knight <troyknight@troyknight.eurobell.co.uk> writes:
>
> Troy> Hey, sorry man. Will do next time. I am just reading from a perl
> Troy> book (Teach Yourself Perl In 21 days).
>
> Ugh. Please read <URL:http://xenu.phys.uit.no/~tom/TYP21D.html>
> before you mess up your life any further.
>
Have read the above webpage. I think this review is a little harsh, yes it
is quite buggy, has mistakes and quite alot of the explanations could be
simpler. I think that if your intelligent enough you can work out what
mistakes have been made and just ignore them or work out what it's meant to
mean. One of the most annoying things he does in his book is use multiple
(and sometimes wrong) names for things, this can be very confusing. Overall
though I am okay with learning from it, and it is not 'discouraging' me from
perl as the above webpage suggests it could be, and I'm gonna stick with it
(as long as people on this newsgroup can put up with questions which are
aren't explained in the book), and Tom Christian did give it 3/5 "Camels"
which aint that bad!
> print "Just another Perl hacker,"
>
> --
> Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
> Keywords: Perl training, UNIX[tm] consulting, video production, skiing,
flying
> Email: <merlyn@stonehenge.com> Snail: (Call) PGP-Key: (finger
merlyn@teleport.com)
> Web: <A HREF="http://www.stonehenge.com/merlyn/">My Home Page!</A>
> Quote: "I'm telling you, if I could have five lines in my .sig, I
would!" -- me
------------------------------
Date: 5 Jul 1999 13:57:12 -0400
From: davet@angel.uunet.ca (Dave Till)
Subject: Re: Stat Function and File Test Operators
Message-Id: <7lqrlo$85v$1@angel.uunet.ca>
Randal Schwartz wrote:
>> Ugh. Please read <URL:http://xenu.phys.uit.no/~tom/TYP21D.html>
>> before you mess up your life any further.
A cheerful hello to you too, Randal. :-) (And a heads-up:
Sams has released a new version of the book, written by Laura Lemay,
that I had nothing to do with. So when new posters to c.l.p.m. talk about
TYP21D, they may not be referring to my book, which is pretty
much out of print now anyways. It wouldn't be fair to blame Ms. Lemay
for something that's my fault.)
Troy Knight <troyknight@troyknight.eurobell.co.uk> wrote:
>I think this review is a little harsh, yes it
>is quite buggy, has mistakes and quite alot of the explanations could be
>simpler.
I have an errata sheet for my book: "http://www.net/~davet/errata52.html".
This may be useful to you.
>One of the most annoying things he does in his book is use multiple
>(and sometimes wrong) names for things, this can be very confusing.
Some of this was deliberate: I didn't use certain terminology if it
was likely to be misunderstood by a reader with a limited computer
science background, (which is why I used "pattern matching"
instead of "regular expressions", for instance).
However, If I were to do it over again, I'd use "filehandle" instead of
"file variable".
--
--Dave Till, dilettante (documents, CGI scripts, web pages, oh my)
email: davet (at) uunet.ca WWW: http://www.net/~davet/
Disclaimer: these are my opinions. Someday, they may be yours.
"UNIX remains rooted in the culture of the word." - Thomas Scoville
------------------------------
Date: 05 Jul 1999 14:16:33 -0400
From: Uri Guttman <uri@sysarch.com>
Subject: Re: Stat Function and File Test Operators
Message-Id: <x7eminx8qm.fsf@home.sysarch.com>
>>>>> "TK" == Troy Knight <troyknight@troyknight.eurobell.co.uk> writes:
TK> Randal L. Schwartz <merlyn@stonehenge.com> wrote in message
>> Ugh. Please read <URL:http://xenu.phys.uit.no/~tom/TYP21D.html>
TK> Have read the above webpage. I think this review is a little
TK> harsh, yes it is quite buggy, has mistakes and quite alot of the
TK> explanations could be simpler. I think that if your intelligent
TK> enough you can work out what mistakes have been made and just
TK> ignore them or work out what it's meant to mean. One of the most
TK> annoying things he does in his book is use multiple (and sometimes
TK> wrong) names for things, this can be very confusing. Overall
TK> though I am okay with learning from it, and it is not
TK> 'discouraging' me from perl as the above webpage suggests it could
TK> be, and I'm gonna stick with it (as long as people on this
TK> newsgroup can put up with questions which are aren't explained in
TK> the book), and Tom Christian did give it 3/5 "Camels" which aint
TK> that bad!
you would still do better with any decent book from o'reilly. the
author's rebuttals are wimpy at best. he thinks that modules are too
difficult for 21 days? i bet he recommends cut and paste programming and
shows how to roll your own buggy cgi parser.
if a book has, as you say inconsistant names, obvious bugs (even if you
can work around them), and a condescending attitude that you can learn
real stuff but only kiddie perl, i would stay away from it. get your
money back unless you dog-eared it already.
uri
--
Uri Guttman ----------------- SYStems ARCHitecture and Software Engineering
uri@sysarch.com --------------------------- Perl, Internet, UNIX Consulting
Have Perl, Will Travel ----------------------------- http://www.sysarch.com
The Best Search Engine on the Net ------------- http://www.northernlight.com
"F**king Windows 98", said the general in South Park before shooting Bill.
------------------------------
Date: 5 Jul 1999 17:18:02 -0400
From: davet@angel.uunet.ca (Dave Till)
Subject: Re: Stat Function and File Test Operators
Message-Id: <7lr7ea$cbo$1@angel.uunet.ca>
In article <x7eminx8qm.fsf@home.sysarch.com>,
Uri Guttman <uri@sysarch.com> wrote:
>you would still do better with any decent book from o'reilly. the
>author's rebuttals are wimpy at best. he thinks that modules are too
>difficult for 21 days?
No. What I did say was that it is difficult to explain modules in
Perl without explaining objects and classes. And objects and classes
are difficult to explain to someone with limited programming
experience. (It can be done - any intelligent reader can grasp
these concepts, even without significant experience - but it's
more of a challenge for the writer.)
The increase in the number and usefulness of modules over the last
few years means that it would probably be worthwhile for a
beginner-level book to show how to use modules quite early on.
Perhaps the best solution would be to treat modules as a
"black box" for the first few chapters of an introductory text,
and then fill in the details later on.
The Perl 5 edition of TYP21D was updated in the fall of 1995,
back when there were fewer modules and fewer essential modules.
I had originally planned to have a longer section on modules
in the book, but scheduling issues (it's a long story - don't ask)
meant that the book didn't have a detailed enough treatment of modules.
Had I it to do over again, I would emphasize the use of modules
much more.
>if a book has, as you say inconsistant names, obvious bugs (even if you
>can work around them), and a condescending attitude that you can learn
>real stuff but only kiddie perl, i would stay away from it.
I think a beginner book can, and should, contain all the "real stuff".
But certain Perl concepts can't be understood until other concepts
have been understood. For example, you can't really understand
modules until you understand packages.
A book that is structured as a tutorial guide should present one
concept at a time, and should present the easier stuff before
getting to the harder stuff. This is why modules are tricky to
describe in a beginner book (IMHO): they are useful to people who are
new to Perl - especially since there are so many handy modules
in both the distribution and CPAN - but they can't be fully understood
without grasping somewhat more advanced programming concepts.
It's part of the general problem of any introductory programming
text: how do you provide the user with enough practical information
to make it possible for him or her to start solving problems
right away, and yet not overload the user with too much
unnecessary detail?
This, BTW, is my main objection to Tom Grydeland's review of
my book: he doesn't understand that a reference manual and
a tutorial guide are different, and require different approaches.
--
--Dave Till, dilettante (documents, CGI scripts, web pages, oh my)
email: davet (at) uunet.ca WWW: http://www.net/~davet/
Disclaimer: these are my opinions. Someday, they may be yours.
"UNIX remains rooted in the culture of the word." - Thomas Scoville
------------------------------
Date: 05 Jul 1999 18:14:33 -0400
From: Uri Guttman <uri@sysarch.com>
Subject: Re: Stat Function and File Test Operators
Message-Id: <x7yaguwxpy.fsf@home.sysarch.com>
>>>>> "DT" == Dave Till <davet@angel.uunet.ca> writes:
>> if a book has, as you say inconsistant names, obvious bugs (even if you
>> can work around them), and a condescending attitude that you can learn
>> real stuff but only kiddie perl, i would stay away from it.
DT> I think a beginner book can, and should, contain all the "real stuff".
DT> But certain Perl concepts can't be understood until other concepts
DT> have been understood. For example, you can't really understand
DT> modules until you understand packages.
then why call it 21 days. it took me months to learn perl and longer to
learn it well and i am an experienced computer professional. lying in
your title is very sleazy. and packages are very easy. they may be hard
to you. they are just prefixes to all you global symbol names. one
sentence. big whoop.
DT> A book that is structured as a tutorial guide should present one
DT> concept at a time, and should present the easier stuff before
DT> getting to the harder stuff. This is why modules are tricky to
DT> describe in a beginner book (IMHO): they are useful to people who are
DT> new to Perl - especially since there are so many handy modules
DT> in both the distribution and CPAN - but they can't be fully understood
DT> without grasping somewhat more advanced programming concepts.
but solving something using an existing module is easier than rolling
your own. i have not seen your book but one comment in the review is
worth noting. why claim CGI stuff when you only have a paragraph on it?
DT> It's part of the general problem of any introductory programming
DT> text: how do you provide the user with enough practical information
DT> to make it possible for him or her to start solving problems
DT> right away, and yet not overload the user with too much
DT> unnecessary detail?
DT> This, BTW, is my main objection to Tom Grydeland's review of
DT> my book: he doesn't understand that a reference manual and
DT> a tutorial guide are different, and require different approaches.
does that give you (or any tutorial) any excuse for outright incorrect
statements about perl or broken code. most of the review's negative
comments were on the bugs and most of those have not been posted to your
errata page.
my favorite one is this (not fixed on the errata page):
$endchars = "END";
$longstring = <<"$endchars"
Here is the first part of the string.
Here is the last part of the string.
END
# here is the next statement
boy is that good code to teach newbies! no semicolon after the
assignment. but even worse i get the error:
Can't find string terminator "$endchars" anywhere before EOF at - line 2.
do you know that the token after << is a literal token? and it is not
interpolated? where did you get the idea to do that and even worse why?
why would you EVER want a here doc's ending token to be dynamically
determined? then you would have to have the compiler run your code
before it could see which token was ending the here doc. perl is smart
but not prescient!
fun stuff!!
if you can't even get something as simple and fundamental as here docs
correct, why should we trust you on more complex stuff or on how to
teach newbies. that code is so bad and broken, i can't believe you claim
to know perl at all.
introductory is one thing, incorrect is another. and don't blame the
publisher and copy editors on that one. and if they are so stupid as to
change your code to suit their moronic views of typesetting, change
publishers.
another fun one is hardcoding numbers in socket calls. do you know that
solaris doesn't use the same values as most other OS's? a simple use
Socket would solve all your problems, even for newbies? your priorites
are wrong. if you assume they can't leanr something real, they
won't. this is how matt's crap code get spread around. some kiddie gets
your book and praises it to his newbie friends and all of them learn bad
perl. then this newsgroup has to clean up after them. you have the
chutzpah to post here and defend yourself but do you have any shame in
releasing such a buggy book?
if your followup author has cleaned up your mess, have them send me a
copy and i will write a review on my perl books page. but i doubt such a
poor publisher will do so or even have the new author fix things as long
as newbies buy it, what do they care.
uri
--
Uri Guttman ----------------- SYStems ARCHitecture and Software Engineering
uri@sysarch.com --------------------------- Perl, Internet, UNIX Consulting
Have Perl, Will Travel ----------------------------- http://www.sysarch.com
The Best Search Engine on the Net ------------- http://www.northernlight.com
"F**king Windows 98", said the general in South Park before shooting Bill.
------------------------------
Date: Tue, 6 Jul 1999 03:04:15 +0100
From: "Troy Knight" <troyknight@troyknight.eurobell.co.uk>
Subject: Re: Stat Function and File Test Operators
Message-Id: <7lro2b$2pl7$1@slrn.eurobell.net>
> then why call it 21 days.
> it took me months to learn perl and longer to
> learn it well and i am an experienced computer professional. lying in
> your title is very sleazy.
I think that's more a book series thing! David wouldn't have any control
over that. Have you seen the "Teach Yourself Something In 10 Minutes" book
series, the books are about 500 pages long! I think you should have a go at
the publisher more than any thing else!
------------------------------
Date: 05 Jul 1999 23:16:23 -0400
From: Uri Guttman <uri@sysarch.com>
Subject: Re: Stat Function and File Test Operators
Message-Id: <x7hfniwjqw.fsf@home.sysarch.com>
>>>>> "TK" == Troy Knight <troyknight@troyknight.eurobell.co.uk> writes:
>> then why call it 21 days.
>> it took me months to learn perl and longer to
>> learn it well and i am an experienced computer professional. lying in
>> your title is very sleazy.
TK> I think that's more a book series thing! David wouldn't have any
TK> control over that. Have you seen the "Teach Yourself Something In
TK> 10 Minutes" book series, the books are about 500 pages long! I
TK> think you should have a go at the publisher more than any thing
TK> else!
but the author is responsible for the main text. and in this case ho
wrote buggy and incorrect code. and he had the gaul to post here and
defend it. i had to do what needed to be done and hoist him on his own
petard of perl ignorance.
the here doc code was laughable if it weren't in a book aimed at
newbies. i have to browse a new version to see if it is still that
bad. i wonder if he will take me up on my offer and get me a copy. i
won't spend a dime on getting it.
uri
--
Uri Guttman ----------------- SYStems ARCHitecture and Software Engineering
uri@sysarch.com --------------------------- Perl, Internet, UNIX Consulting
Have Perl, Will Travel ----------------------------- http://www.sysarch.com
The Best Search Engine on the Net ------------- http://www.northernlight.com
"F**king Windows 98", said the general in South Park before shooting Bill.
------------------------------
Date: Tue, 6 Jul 1999 00:55:08 -0400
From: rjk@linguist.dartmouth.edu (Ronald J Kimball)
Subject: Re: Stat Function and File Test Operators
Message-Id: <1duhx1n.s2izlyxn6a5mN@p218.tc1.state.ma.tiac.com>
Uri Guttman <uri@sysarch.com> wrote:
> if your followup author has cleaned up your mess, have them send me a
> copy and i will write a review on my perl books page. but i doubt such a
> poor publisher will do so or even have the new author fix things as long
> as newbies buy it, what do they care.
"I'm being rather a jerk to you and your publisher, and I've already
decided that I'll give it a bad review, but I wonder if you would send
me a free copy of the new book..."
--
_ / ' _ / - aka -
( /)//)//)(//)/( Ronald J Kimball rjk@linguist.dartmouth.edu
/ http://www.tiac.net/users/chipmunk/
"It's funny 'cause it's true ... and vice versa."
------------------------------
Date: 06 Jul 1999 01:44:58 -0400
From: Uri Guttman <uri@sysarch.com>
Subject: Re: Stat Function and File Test Operators
Message-Id: <x7vhbyuyat.fsf@home.sysarch.com>
>>>>> "RJK" == Ronald J Kimball <rjk@linguist.dartmouth.edu> writes:
RJK> Uri Guttman <uri@sysarch.com> wrote:
>> if your followup author has cleaned up your mess, have them send me a
>> copy and i will write a review on my perl books page. but i doubt such a
>> poor publisher will do so or even have the new author fix things as long
>> as newbies buy it, what do they care.
RJK> "I'm being rather a jerk to you and your publisher, and I've already
RJK> decided that I'll give it a bad review, but I wonder if you would send
RJK> me a free copy of the new book..."
not exactly. if the new version is better, then i will gladly give it a
positive review. in fact i would praise its cleanup. but being a called jerk is
strong words. care to say that to my face when we are in front of a hot
grill with some jerk sauce in my bowl? :-)
i am just pissed at the low level of quality that this author seems to
think his readers want. it shows a great disrespect for his
readership. if that makes me a jerk, what does it make him? a good
tutorial book on perl can be written (the llama being proof) so what
excuse does he have? that he is not randal, tom, et al?
i know tech writing is very hard having done some myself. but there is
no excuse for multiple blatant errors.
uri
--
Uri Guttman ----------------- SYStems ARCHitecture and Software Engineering
uri@sysarch.com --------------------------- Perl, Internet, UNIX Consulting
Have Perl, Will Travel ----------------------------- http://www.sysarch.com
The Best Search Engine on the Net ------------- http://www.northernlight.com
"F**king Windows 98", said the general in South Park before shooting Bill.
------------------------------
Date: 6 Jul 1999 10:45:27 -0400
From: davet@angel.uunet.ca (Dave Till)
Subject: Re: Stat Function and File Test Operators
Message-Id: <7lt4q7$2rc$1@angel.uunet.ca>
In article <x7yaguwxpy.fsf@home.sysarch.com>,
Uri Guttman <uri@sysarch.com> wrote:
>and packages are very easy. they may be hard
>to you. they are just prefixes to all you global symbol names. one
>sentence. big whoop.
A person without significant computer experience wouldn't
know what a global symbol name was.
>but solving something using an existing module is easier than rolling
>your own. i have not seen your book but one comment in the review is
>worth noting. why claim CGI stuff when you only have a paragraph on it?
I didn't control the design of the cover - that was a SAMS
marketing decision.
> DT> This, BTW, is my main objection to Tom Grydeland's review of
> DT> my book: he doesn't understand that a reference manual and
> DT> a tutorial guide are different, and require different approaches.
>
>does that give you (or any tutorial) any excuse for outright incorrect
>statements about perl or broken code.
No, but that's a separate issue. I was commenting on a particular
objection in Tom's review.
>most of the review's negative
>comments were on the bugs and most of those have not been posted to your
>errata page.
By the time his review came out, the book had stopped going into
new printings, so I didn't log all of his comments. My bad.
(I must confess that I didn't finish reading his review, because
his unnecessarily sarcastic comments are bad for my blood pressure. :-))
>another fun one is hardcoding numbers in socket calls. do you know that
>solaris doesn't use the same values as most other OS's?
Yep. That one's in the errata page.
>you have the
>chutzpah to post here and defend yourself but do you have any shame in
>releasing such a buggy book?
I wasn't actually defending myself - just claiming that there is
a difference between a tutorial guide and a reference manual.
Whether my book is a good tutorial guide or not is a separate issue.
And I do wish I'd gotten some of the nastier technical errors fixed
up. Contrary to what you might think, I was interested in trying
to produce the best product that I could. Had there been another
printing of the book, I would have made a note to fix the errors
noted by Tom and others.
>if your followup author has cleaned up your mess, have them send me a
>copy and i will write a review on my perl books page.
I don't have any connection with SAMS any more, so you'll either
have to contact SAMS or the author yourself, or buy a copy.
I expect that the new book will have fewer technical errors than
mine did, as it looks like they got more people to review it, and
I suspect that the author was given more time to write it than I was.
--
--Dave Till, dilettante (documents, CGI scripts, web pages, oh my)
email: davet (at) uunet.ca WWW: http://www.net/~davet/
Disclaimer: these are my opinions. Someday, they may be yours.
"UNIX remains rooted in the culture of the word." - Thomas Scoville
------------------------------
Date: Sat, 03 Jul 1999 10:25:15 -0700
From: Steve Laybourn <laughingotter@foxinternet.net>
Subject: stat() for local item?
Message-Id: <377E477A.E6E1481B@foxinternet.net>
Hello again!
The solution provided to me for the Image::Size workaround was
brilliant, simple, and easily implemented! (Boy, were the server techs
MAD that I got around having to pay an additional $85 for them to
install Image::Size. Screw 'em, I sez.)
But now I have another related problem...
Is it possible to check to see if a file exists on the local system
and to get its size (in bytes) before uploading it to the server? I have
tried a -e solution, and I have tried stat(), but apparently I didn't do
it right, because it didn't work.
I am trying to do this so that I can see if someone is trying to
upload some 400KB .JPG image file before it goes up and we have to pick
up the pieces after the server crashes.
Sorry to bother you people with what might be a trivial thing...
Be seeing you...
Steve Laybourn
------------------------------
Date: Sat, 03 Jul 1999 15:07:17 -0700
From: David Cassell <cassell@mail.cor.epa.gov>
To: Steve Laybourn <laughingotter@foxinternet.net>
Subject: Re: stat() for local item?
Message-Id: <377E8995.9B28C8CA@mail.cor.epa.gov>
[courtesy cc mailed to poster]
Steve Laybourn wrote:
>
> Hello again!
> The solution provided to me for the Image::Size workaround was
> brilliant, simple, and easily implemented! (Boy, were the server techs
> MAD that I got around having to pay an additional $85 for them to
> install Image::Size. Screw 'em, I sez.)
$85 ?!?! Maybe you need a new ISP. BTW, don't p!$$ off sys
admin people if you don't have to - some day you'll need their
cooperation, and then they'll pay you back...
> But now I have another related problem...
> Is it possible to check to see if a file exists on the local system
> and to get its size (in bytes) before uploading it to the server? I have
> tried a -e solution, and I have tried stat(), but apparently I didn't do
> it right, because it didn't work.
> [snip]
Well, since you're doing this on some server, within a CGI
script, you'll need to remember that your web server is quite
likely to be using a different environment than you are..
including a different starting directory. You won't want to
use relative paths. Use absolute paths to the directory and
the files.
Then make sure that you use -e on the right file in the right
directory. If you work in directory $dir and check file $fil2,
-e $fil2
doesn't do what you want. You have to do this:
-e $dir/$fil2
so the right file in the right dir gets checked.
After that check, you can test the filesize with -s too.
I would also check that it *is* a file [that's -f] and that
it is readable by the effective uid/gid [that's -r].
You can read about all these and more in the perlfunc
manpage, under -X .
HTH,
David
--
David Cassell, OAO cassell@mail.cor.epa.gov
Senior computing specialist
mathematical statistician
------------------------------
Date: 3 Jul 1999 18:59:42 -0500
From: abigail@delanet.com (Abigail)
Subject: Re: stat() for local item?
Message-Id: <slrn7nt8ur.31h.abigail@alexandra.delanet.com>
David Cassell (cassell@mail.cor.epa.gov) wrote on MMCXXXII September
MCMXCIII in <URL:news:377E8995.9B28C8CA@mail.cor.epa.gov>:
?? [courtesy cc mailed to poster]
??
?? Steve Laybourn wrote:
?? >
?? > Hello again!
?? > The solution provided to me for the Image::Size workaround was
?? > brilliant, simple, and easily implemented! (Boy, were the server techs
?? > MAD that I got around having to pay an additional $85 for them to
?? > install Image::Size. Screw 'em, I sez.)
??
?? $85 ?!?! Maybe you need a new ISP. BTW, don't p!$$ off sys
?? admin people if you don't have to - some day you'll need their
?? cooperation, and then they'll pay you back...
Yes, and if they are real sysadmins, they will make sure that the
day you need them is soon.
Be afraid. Be very afraid.
Abigail
--
perl -wle\$_=\<\<EOT\;y/\\n/\ /\;print\; -eJust -eanother -ePerl -eHacker -eEOT
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
------------------------------
Date: Sun, 04 Jul 1999 05:55:29 GMT
From: nospam.newton@gmx.net (Philip 'Yes, that's my address' Newton)
Subject: Re: stat() for local item?
Message-Id: <377ef57c.1469280@news.nikoma.de>
On Sat, 03 Jul 1999 15:07:17 -0700, David Cassell
<cassell@mail.cor.epa.gov> wrote:
> Steve Laybourn wrote:
>> Is it possible to check to see if a file exists on the local system
>> and to get its size (in bytes) before uploading it to the server? I have
>> tried a -e solution, and I have tried stat(), but apparently I didn't do
>> it right, because it didn't work.
>> [snip]
>
>Well, since you're doing this on some server, within a CGI
>script, you'll need to remember that your web server is quite
>likely to be using a different environment than you are..
>including a different starting directory. You won't want to
>use relative paths. Use absolute paths to the directory and
>the files.
I think he wants to check the size of a file on the system of the chap
with the browser. Unfortunately, -e "http://${REMOTE_ADDR}/$filename"
doesn't work. It that's really what Steve wants, he's out of luck.
Server-side scripts can't AFAIK find out anything about the client
side, beyond what gets passed in as environment variables.
Cheers,
Philip
--
Philip Newton <nospam.newton@gmx.net>
------------------------------
Date: 1 Jul 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 1 Jul 99)
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.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
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.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
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 V9 Issue 49
************************************
