[13876] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 1286 Volume: 9

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Nov 4 21:15:38 1999

Date: Thu, 4 Nov 1999 18:15:29 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <941768128-v9-i1286@ruby.oce.orst.edu>
Content-Type: text

Perl-Users Digest           Thu, 4 Nov 1999     Volume: 9 Number: 1286

Today's topics:
    Re: localtime object y2k compliant? (Craig Berry)
    Re: localtime object y2k compliant? <cassell@mail.cor.epa.gov>
    Re: localtime object y2k compliant? (Martien Verbruggen)
    Re: localtime object y2k compliant? (Kragen Sitaker)
    Re: localtime object y2k compliant? <cassell@mail.cor.epa.gov>
    Re: localtime object y2k compliant? <lr@hpl.hp.com>
    Re: mod_php and mod_perl problems.... jomagam@yahoo.com
        newbie filehandle question <glenn@icarus.usanetworks.com>
    Re: newbie filehandle question <makkulka@cisco.com>
    Re: newbie filehandle question <jeffp@crusoe.net>
    Re: newbie filehandle question lee.lindley@bigfoot.com
    Re: newbie filehandle question <lr@hpl.hp.com>
    Re: Newbie help <cassell@mail.cor.epa.gov>
        password question ardit@my-deja.com
    Re: password question <rootbeer@redcat.com>
        Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Thu, 04 Nov 1999 23:37:02 GMT
From: cberry@cinenet.net (Craig Berry)
Subject: Re: localtime object y2k compliant?
Message-Id: <s2464uaehpc93@corp.supernews.com>

kenkhouri@my-deja.com wrote:
: I am trying to find out if the perl localtime class is y2k compliant.

My condolences on having lost your online documentation in a tragic disk
failure.  Still, one might presume it would be easier to reload perl,
thereby getting a new copy of the doc, or even look on the web at

http://www.perl.com/pub/doc/manual/html/pod/perlfaq4.html#Does_Perl_have_a_year_2000_probl

rather than troubling us here and possibly getting a less definitive -- or
even entirely incorrect -- answer, after waiting hours or days to get it.

: I would like to assume that it is,

There is no need to assume, other than False Laziness.

: however, the following code example
: (from O'reilly:  Programming Perl) looks questionable.

What about it do you find questionable?

: If you know the answer, I would be interested in hearing it and also
: where you might have learned it.  Although the O'reilly book
: provides information on the class, it does not specify what
: happens after 2000!  It's surprising to me that you should add
: 1900 to the year to get a 4 digit year.  Thanks!

Many people (including myself) have agreed that this was a suboptimal
design from a human-engineering point of view.  However, it is a perfectly
consistent way to represent the year, and will continue to operate across
the y2k boundary without incident *if* your programmers are using it
properly.

:  use Time::localtime ;
:  $tm = localtime ;
: 
:  $dt_str = sprintf("%04d%02d%02d",
:         $tm->year+1900,
:         ($tm->mon) + 1,
:         ($tm->mday) - 1) ;

-- 
   |   Craig Berry - cberry@cinenet.net
 --*--  http://www.cinenet.net/users/cberry/home.html
   |   "They do not preach that their God will rouse them
      a little before the nuts work loose." - Kipling


------------------------------

Date: Thu, 04 Nov 1999 15:56:07 -0800
From: David Cassell <cassell@mail.cor.epa.gov>
Subject: Re: localtime object y2k compliant?
Message-Id: <38221D17.3C3A409F@mail.cor.epa.gov>

Jocelyn Amon wrote:
[my snip of Cameron's post]
> When will you 'experts' and know-it-alls get it. No amount of
> patronising put-downs, abuse or be-littling of others is going to change
> a thing.

I fear you are right there.  But you have missed a point as well.
Please see below.  And using _ad_hominem_ arguments to protest
_ad_hominem_ attacks is not an effective strategy.

>  Programmers use logic.  This programmer has applied logic to
> the situation and he, logically, assumes that adding 1900 to the year
> value will not give him the correct 4 digit year value after 1999. Seems
> very logical to me!  So maybe he should have run a test to see.  But
> that is a failing of many programmers - don't run tests, jump to
> conclusions or let users find the bugs.

I believe you are talking about code-mungers, not programmers.
Programmers know that when in doubt, one looks in the docs.
Then one experiments with the tokens in question.  A real
programmer does not make a guess, refuse to try more than
one value, and ignore all documentation.

However, you *are* right that there are lots of such people
out there, and they need help.

> You can't change programmer thinking but ranting on about 'shoulds'! The
> many queries to this newsgroup re localtime is proof of this.  Localtime
> usage is ill-conceived and will be the cause of a lot of Y2K failures

It will only be the cause of Y2K failures on websites where
people have snitched cargo-cult code or whipped up ugly kludges
without bothering to read the docs first.  That's why your
webpage - which shows hundreds of webpages with Y2K errors -
only has a handful of *different* Perl errors, and they're not
in important places.

> regardless of all the 'shoulds' you very clever Perl people 'in the
> know' like to repeat ad-infinitum.  Just give the guy the right answer
> or leave it to someone else to respond reasonably.
> 
> Sarcasm does not help - you only do it to show how clever you are and
> how stupid you consider others to be.  If you were in fact clever people
> you would be more understanding of this problem and why it keeps
> recurring.  Get in touch with the real world.

No, the sarcasm is because people here are frustrated that no 
one will read the documentation or the FAQs or even search
past threads of this newsgroup to get the right answers.  Answering
one person doesn't solve anything in a global sense, as you should
know.
 
> At least this programmer is asking the right questions re Y2K.  Many
> programmers have not given Y2K a second thought.  Unfortunately not
> enough questions are asked in our profession because of put-downs by
> others.  Perhaps it is this attitude more than any other that has been
> the cause of the Y2K problem in the first place.

Real programmers *have* dealt with Y2K issues already.  The
noncompliant websites are not those of serious coders.  And if
you really believe that "it is this attitude more than any 
other that has been the cause of the Y2K problem in the first place"
then you too need to get in touch with the real world.

Not enough questions are asked because too few people want to
do the work needed to become serious programmers.

> If anyone would like to read further on the Y2K and Perl problem, check
> out the booby-trap code article at URL:
> http://www.ts.co.nz/~finsol/y2k_articles.htm
> 
> The article on programmer denial, also at this URL, may be of interest
> to some of you.

Actually, her article listing some 300 non-compliant webpages
may be of interest to some members of this newsgroup.

David
-- 
David Cassell, OAO                     cassell@mail.cor.epa.gov
Senior computing specialist
mathematical statistician


------------------------------

Date: Fri, 05 Nov 1999 01:13:52 GMT
From: mgjv@verbruggen.comdyn.com.au (Martien Verbruggen)
Subject: Re: localtime object y2k compliant?
Message-Id: <slrn824bqh.apq.mgjv@verbruggen.comdyn.com.au>

On Thu, 04 Nov 1999 20:14:06 GMT,
	Jocelyn Amon <finsol@ts.co.nz> wrote:

> When will you 'experts' and know-it-alls get it. No amount of
> patronising put-downs, abuse or be-littling of others is going to change
> a thing.  Programmers use logic.  This programmer has applied logic to
> the situation and he, logically, assumes that adding 1900 to the year
> value will not give him the correct 4 digit year value after 1999. Seems
> very logical to me!  So maybe he should have run a test to see.  But
> that is a failing of many programmers - don't run tests, jump to
> conclusions or let users find the bugs.

I fail to see how all that is logical. Why is it more logical to
assume that adding 1900 to a number is wrong than it is to assume that
it is right? I really fail to see it. Especially if you include that
it is really very logical to consult the documentation when in doubt
about implementation details. _That_ is programmer logic.

But then, we already know your logic, don't we? :)

Martien
-- 
Martien Verbruggen              | 
Interactive Media Division      | +++ Out of Cheese Error +++ Reinstall
Commercial Dynamics Pty. Ltd.   | Universe and Reboot +++
NSW, Australia                  | 


------------------------------

Date: Fri, 05 Nov 1999 01:14:02 GMT
From: kragen@dnaco.net (Kragen Sitaker)
Subject: Re: localtime object y2k compliant?
Message-Id: <ubqU3.29566$23.1534872@typ11.nn.bcandid.com>

In article <38221D17.3C3A409F@mail.cor.epa.gov>,
David Cassell  <cassell@mail.cor.epa.gov> wrote:
>Jocelyn Amon wrote:
>[my snip of Cameron's post]
>>  Programmers use logic.  This programmer has applied logic to
>> the situation and he, logically, assumes that adding 1900 to the year
>> value will not give him the correct 4 digit year value after 1999. Seems
>> very logical to me!  So maybe he should have run a test to see.  But
>> that is a failing of many programmers - don't run tests, jump to
>> conclusions or let users find the bugs.
>
>I believe you are talking about code-mungers, not programmers.
>Programmers know that when in doubt, one looks in the docs.
>Then one experiments with the tokens in question.  A real
>programmer does not make a guess, refuse to try more than
>one value, and ignore all documentation.
>
>However, you *are* right that there are lots of such people
>out there, and they need help.

I fervently hope that, in the near future, 'programmer' will be a title
as little used, and as widely applicable, as 'driver' or 'telephone
user'.

Casual programmers, like casual drivers, will probably never be able to
do really impressive things.  They may have a hard time writing
anything that works reliably.  But they will do it anyhow, because they
want it done and nobody else is going to do it for them.  And other
people will use their code.

I think we cannot and should not require people to be licensed
professional programmers before we allow them to use Perl, just as we
do not require people to be licensed professional welders before we
allow them to buy welding rigs.  In both cases, some bad results ensue
from our leniency.

Typical implementations of C constitute decent working environments for
serious programmers writing small to medium-sized programs.  They do
not constitute decent working environments for casual programmers; the
ways things can fail are too difficult to track down and too hard to
avoid, and doing fairly basic things, like appending strings, is
difficult.

This is not nearly as true as Perl, but it is true of the year element
of the return value of the localtime() and gmtime() function.

>> You can't change programmer thinking but ranting on about 'shoulds'! The
>> many queries to this newsgroup re localtime is proof of this.  Localtime
>> usage is ill-conceived and will be the cause of a lot of Y2K failures
>
>It will only be the cause of Y2K failures on websites where
>people have snitched cargo-cult code or whipped up ugly kludges
>without bothering to read the docs first.  That's why your
>webpage - which shows hundreds of webpages with Y2K errors -
>only has a handful of *different* Perl errors, and they're not
>in important places.

That is very interesting.  I wonder if we could get an analysis of
where these bugs were cut and pasted from.  Perhaps Jocelyn would be
willing to do it?  She could even email the authors of the bugs to ask
-- surely most of them would be happy to pass the blame.

>> regardless of all the 'shoulds' you very clever Perl people 'in the
>> know' like to repeat ad-infinitum.  Just give the guy the right answer
>> or leave it to someone else to respond reasonably.
>> 
>> Sarcasm does not help - you only do it to show how clever you are and
>> how stupid you consider others to be.  If you were in fact clever people
>> you would be more understanding of this problem and why it keeps
>> recurring.  Get in touch with the real world.
>
>No, the sarcasm is because people here are frustrated that no 
>one will read the documentation or the FAQs or even search
>past threads of this newsgroup to get the right answers.  Answering
>one person doesn't solve anything in a global sense, as you should
>know.

It is very frustrating.  But it will not change.

>> At least this programmer is asking the right questions re Y2K.  Many
>> programmers have not given Y2K a second thought.  Unfortunately not
>> enough questions are asked in our profession because of put-downs by
>> others.  Perhaps it is this attitude more than any other that has been
>> the cause of the Y2K problem in the first place.
>
>Real programmers *have* dealt with Y2K issues already.  The
>noncompliant websites are not those of serious coders.  And if
>you really believe that "it is this attitude more than any 
>other that has been the cause of the Y2K problem in the first place"
>then you too need to get in touch with the real world.

I still think localtime() and gmtime() should return a 0-based year,
not a 1900-based year.  The bugs would have been avoided altogether.

>Not enough questions are asked because too few people want to
>do the work needed to become serious programmers.

Bingo.  What do you propose to do about it?

I think the best solution is to make life easier for casual
programmers.  It won't solve the problem altogether, of course --
casual programmers will write buggy code no matter what we do.  But the
least we can do is give them environments where the most likely bugs
are more obvious.  This benefits us too.
-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
Tue Nov 02 1999
6 days until the Internet stock bubble bursts on Monday, 1999-11-08.
<URL:http://www.pobox.com/~kragen/bubble.html>


------------------------------

Date: Thu, 04 Nov 1999 17:39:23 -0800
From: David Cassell <cassell@mail.cor.epa.gov>
Subject: Re: localtime object y2k compliant?
Message-Id: <3822354B.27217820@mail.cor.epa.gov>

Kragen Sitaker wrote:
> In article <38221D17.3C3A409F@mail.cor.epa.gov>,
> David Cassell  <cassell@mail.cor.epa.gov> wrote:
> >Jocelyn Amon wrote:
[snip]
> >It will only be the cause of Y2K failures on websites where
> >people have snitched cargo-cult code or whipped up ugly kludges
> >without bothering to read the docs first.  That's why your
> >webpage - which shows hundreds of webpages with Y2K errors -
> >only has a handful of *different* Perl errors, and they're not
> >in important places.
> 
> That is very interesting.  I wonder if we could get an analysis of
> where these bugs were cut and pasted from.  Perhaps Jocelyn would be
> willing to do it?  She could even email the authors of the bugs to ask
> -- surely most of them would be happy to pass the blame.

Her table has all the URLs given.  Tracking down the guilty
parties seems feasible.

I did a little web-searching too, and I plan to put my
results together in a (hopefully) useful post to this newsgroup
in a couple weeks on "HOW TO FIX Y2K BUGS IN YOUR PERL CODE"
or some similar stupid title designed to snag clouded corneas.

[more snippage]
> >No, the sarcasm is because people here are frustrated that no
> >one will read the documentation or the FAQs or even search
> >past threads of this newsgroup to get the right answers.  Answering
> >one person doesn't solve anything in a global sense, as you should
> >know.
> 
> It is very frustrating.  But it will not change.

Agreed.  And we might as well realize that, or else go the
way of LarryW and TomC.
 
[more snips]
> I still think localtime() and gmtime() should return a 0-based year,
> not a 1900-based year.  The bugs would have been avoided altogether.

Well, after 2000 this won't be as much of an issue.. I hope.

> >Not enough questions are asked because too few people want to
> >do the work needed to become serious programmers.
> 
> Bingo.  What do you propose to do about it?

Electroshock.  I'm trying to write a module based on 
PSI::Telekinesis which crawls the web and attacks people who
code wretchedly.  Sort of like a bad Wes Craven movie starring
Mitch Pileggi.  :-)
 
> I think the best solution is to make life easier for casual
> programmers.  It won't solve the problem altogether, of course --
> casual programmers will write buggy code no matter what we do.  But the
> least we can do is give them environments where the most likely bugs
> are more obvious.  This benefits us too.

Logical, captain.  How do you plan to do this?

David
-- 
David Cassell, OAO                     cassell@mail.cor.epa.gov
Senior computing specialist
mathematical statistician


------------------------------

Date: Thu, 4 Nov 1999 17:43:54 -0800
From: Larry Rosler <lr@hpl.hp.com>
Subject: Re: localtime object y2k compliant?
Message-Id: <MPG.128bd6362642869c98a1af@nntp.hpl.hp.com>

In article <7vspea$9su$1@nnrp1.deja.com> on Thu, 04 Nov 1999 20:14:06 
GMT, Jocelyn Amon <finsol@ts.co.nz> says...

I wonder what your career plans are for 2000 and after.

What did Jeremiah do after the Babylonian Exile?

What did Cassandra do after the fall of Troy?

And those people were right!  What will you do?

-- 
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com


------------------------------

Date: Fri, 05 Nov 1999 01:38:18 GMT
From: jomagam@yahoo.com
Subject: Re: mod_php and mod_perl problems....
Message-Id: <7vtcea$o4l$1@nnrp1.deja.com>



From what you write I suspect that you installed mod_perl and mod_php
from RPMs or some other package. You cannot use both unless the package
is specificly built to contain apache+mod_perl+mod+php. I'd just
download the sources to all 3 and build them by hand; there is planty of
documentation on how to build them all into one server.

Hope it helped: Balazx


Sent via Deja.com http://www.deja.com/
Before you buy.


------------------------------

Date: Thu, 4 Nov 1999 18:57:15 -0500
From: Glenn Becker <glenn@icarus.usanetworks.com>
To: Glenn Becker <glenn@icarus.usanetworks.com>
Subject: newbie filehandle question
Message-Id: <Pine.GSO.4.10.9911041849210.9561-100000@icarus.usanetworks.com>

Hi,

I am working my way through Jon Orwant's Perl 5 Interactive Course ... the
interactive online component of which is being scuttled by the publishers
- thus, my post here.

One of the book's examples, titled nextline, is an illustration of
how to use filehandles, and more specifically the seek() and tell()
functions, to move around in a file.

Here is the code:

#!/usr/bin/perl 

($position, $filename) = @ARGV;
open(FILE, $filename) or die "Can't open $filename: $! \n";

# move to $position bytes from the beginning of $filename.
seek(FILE, $position, 0) or die "Can't seek: $! \n";

$trash    = <FILE>;              # Get the rest of the line

$realpos  = tell(FILE);          # find out the current file position

# grab the next line
$nextline = <FILE>;

print "The next line of $filename is $nextline.\n";
print "It actually starts at $realpos.\n";


My question concerns the line $trash = <FILE>;. The author writes "Unless
you get lucky, $position is now somewhere in the middle of a line. You
want to advance to the next line, so nextline disposes of the remainder of
the line with $trash = <FILE>."

I'm sorry to be dense -- but why does this work? Should I just accept that
it does and forget about it?

Any light shed on this subject would be welcome.

Thanks,

Glenn

_________________________________________________________________________
                                                                         |
//G l e n n  B e c k e r                                                 |
//"Whom we dreamt was a shaddo, sure, he's lightseyes, the laddo!"       |
//glenn@scifi.com                                                        |
_________________________________________________________________________|



------------------------------

Date: Thu, 04 Nov 1999 16:25:44 -0800
From: Makarand Kulkarni <makkulka@cisco.com>
Subject: Re: newbie filehandle question
Message-Id: <38222408.865771A7@cisco.com>

Glenn Becker wrote:

> My question concerns the line $trash = <FILE>;. The author writes "Unless
> you get lucky, $position is now somewhere in the middle of a line. You
> want to advance to the next line, so nextline disposes of the remainder of
> the line with $trash = <FILE>."
> I'm sorry to be dense -- but why does this work? Should I just accept that
> it does and forget about it?

From perldoc perlop

     Evaluating a filehandle in angle brackets yields the next
     line from that file (newline, if any, included), or undef at
     end of file.

So unless the special variable $/ was redefined this is
the behavious or <> operator.
--



------------------------------

Date: Thu, 4 Nov 1999 19:38:45 -0500
From: Jeff Pinyan <jeffp@crusoe.net>
Subject: Re: newbie filehandle question
Message-Id: <Pine.GSO.4.10.9911041935110.4538-100000@crusoe.crusoe.net>

[posted & mailed]

> seek(FILE, $position, 0) or die "Can't seek: $! \n";
> $trash    = <FILE>;              # Get the rest of the line
> $realpos  = tell(FILE);          # find out the current file position

> I'm sorry to be dense -- but why does this work? Should I just accept that
> it does and forget about it?

The comment helps explain.  When you seek to a file, and you end up
anywhere on the line, the <FILEHANDLE> operator returns to you the rest of
that "line" (a line is considered to be the least number of characters up
to and including the $/ character (defaulting to "\n") from the current
position).

The '^' here indicate where in the line you seek()ed to, and the resulting
value of <FILE> is given (it returns the characters from your current
position in the file to the first end-of-line it comes across):

  Once I saw a puddy tat.
     ^
    "e I saw a puddy tat.\n"

  Once I saw a puddy tat.
            ^
           " a puddy tat.\n"

Do you see how it works now?  The <FILEHANDLE> moves you to the next line,
giving you the option of saving the line you were just at.

-- 

  MIDN 4/C PINYAN, USNR, NROTCURPI
  jeff pinyan      japhy@pobox.com
  perl stuff       japhy+perl@pobox.com
  CPAN ID: PINYAN  http://www.perl.com/CPAN/authors/id/P/PI/PINYAN/



------------------------------

Date: 5 Nov 1999 01:15:33 GMT
From: lee.lindley@bigfoot.com
Subject: Re: newbie filehandle question
Message-Id: <7vtb3l$27$1@rguxd.viasystems.com>

Glenn Becker <glenn@icarus.usanetworks.com> wrote:
:>#!/usr/bin/perl 

:>($position, $filename) = @ARGV;
:>open(FILE, $filename) or die "Can't open $filename: $! \n";

:># move to $position bytes from the beginning of $filename.
:>seek(FILE, $position, 0) or die "Can't seek: $! \n";

:>$trash    = <FILE>;              # Get the rest of the line

:>$realpos  = tell(FILE);          # find out the current file position

:># grab the next line
:>$nextline = <FILE>;

:>print "The next line of $filename is $nextline.\n";
:>print "It actually starts at $realpos.\n";


:>My question concerns the line $trash = <FILE>;. The author writes "Unless
:>you get lucky, $position is now somewhere in the middle of a line. You
:>want to advance to the next line, so nextline disposes of the remainder of
:>the line with $trash = <FILE>."

:>I'm sorry to be dense -- but why does this work? Should I just accept that
:>it does and forget about it?

Of course not.  Understand why it works and why under a certain
condition it will get the line *after* the one you really want.

<FILE> reads up to and including the next end-of-record marker.
For talking purposes let's call that a newline character in the
datastream (it gets more complex when you use seek in a file
where Perl is doing magic with multi-character end-of-record
markers like in MS world).

If your seek happened to have positioned you on one of those
end-of-record markers ("on" meaning that the next read will
read the char after that one), then

$trash    = <FILE>;              

would actually suck down the line you wanted!  But most of the
time, given a random seek offset, you will be sitting in the
middle of a record somewhere.  So this trick will advance
the file I/O pointer to the end of the current record.

A better way might be to seek to one less than the asked
for position, do a getc(), check if that char is "\n",
then depending on the answer, either suck down the trash
or go directly to reading the line you want.

That would be a good extension to the excercise you are
working on anyway.  If it doesn't work like you expect,
please come back and let us know what you find.

-- 
// Lee.Lindley   /// I used to think that being right was everything.
// @bigfoot.com  ///  Then I matured into the realization that getting
////////////////////   along was more important.  Except on usenet.


------------------------------

Date: Thu, 4 Nov 1999 17:51:37 -0800
From: Larry Rosler <lr@hpl.hp.com>
Subject: Re: newbie filehandle question
Message-Id: <MPG.128bd8058981294a98a1b0@nntp.hpl.hp.com>

In article <Pine.GSO.4.10.9911041935110.4538-100000@crusoe.crusoe.net> 
on Thu, 4 Nov 1999 19:38:45 -0500, Jeff Pinyan <jeffp@crusoe.net> 
says...

 ...

> The comment helps explain.  When you seek to a file, and you end up
> anywhere on the line, the <FILEHANDLE> operator returns to you the rest of
> that "line" (a line is considered to be the least number of characters up
> to and including the $/ character (defaulting to "\n") from the current
> position).
                          ^^^^^^^^^
                          string

-- 
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com


------------------------------

Date: Thu, 04 Nov 1999 15:18:44 -0800
From: David Cassell <cassell@mail.cor.epa.gov>
Subject: Re: Newbie help
Message-Id: <38221454.3E39408F@mail.cor.epa.gov>

kevin montuori wrote:
> 
> >>> kb9nvh  writes:
>   ts> The code below prints the $i variable and then the text "+1".  I
>   ts> want 1 to be added to $i and the sum printed.  What do I do
>   ts> Please?  Any help is appreciated...  Todd Snyder
> 
> among other possibilities:
> 
> my $i = 5;
> 
> print <<"EOF";
> this is the number @{[ $i + 1 ]}
> EOF

As you say, this is 'among other possibilities'.  But usually
one wnats to abuse a scalar like this instead:

print <<"EOF";
this is the number ${\( $i + 1 )}
EOF

But it is much clearer if one just does the sum outside
the here-doc so there is no mucking about with expansion
of function calls.  Like others in this thread proposed
already.

David
-- 
David Cassell, OAO                     cassell@mail.cor.epa.gov
Senior computing specialist
mathematical statistician


------------------------------

Date: Fri, 05 Nov 1999 00:33:23 GMT
From: ardit@my-deja.com
Subject: password question
Message-Id: <7vt8kj$ld1$1@nnrp1.deja.com>

I have a perl script that gets news from the internet, one of the
websites I'm trying to access is password protected, the problem is
that I don't know how to put the password and the username in my perl
script in order to retrieve news from that site, I get news with out a
problem from other sites that are not protected by a password. Is there
any code I should use in the script?

please help

thank you
ardit


Sent via Deja.com http://www.deja.com/
Before you buy.


------------------------------

Date: Thu, 4 Nov 1999 17:16:34 -0800
From: Tom Phoenix <rootbeer@redcat.com>
Subject: Re: password question
Message-Id: <Pine.GSO.4.10.9911041709450.29670-100000@user2.teleport.com>

On Fri, 5 Nov 1999 ardit@my-deja.com wrote:

> I have a perl script that gets news from the internet, one of the
> websites I'm trying to access is password protected, the problem is
> that I don't know how to put the password and the username in my perl
> script in order to retrieve news from that site, I get news with out a
> problem from other sites that are not protected by a password. Is there
> any code I should use in the script?

Yes.

If you're using a module, see its docs to discover how to pass a username
and password. If you're not using a module, get one from CPAN and see its
docs.

Also, please consider using the punctuation mark period (".") when you
reach the end of a declarative sentence, since that makes your text easier
to read.

Cheers!

-- 
Tom Phoenix       Perl Training and Hacking       Esperanto
Randal Schwartz Case:     http://www.rahul.net/jeffrey/ovs/



------------------------------

Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Digest Administrivia (Last modified: 16 Sep 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.  

| NOTE: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.

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 V9 Issue 1286
**************************************


home help back first fref pref prev next nref lref last post