[9094] in Perl-Users-Digest
Perl-Users Digest, Issue: 2712 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon May 25 01:08:07 1998
Date: Sun, 24 May 98 22:00:23 -0700
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 24 May 1998 Volume: 8 Number: 2712
Today's topics:
Re: An unwelcome and undeserved slap <tchrist@mox.perl.com>
Re: An unwelcome and undeserved slap (Fergus Henderson)
Re: Clearly define "free software" (le Fanttme)
Re: Clearly define "free software" (le Fanttme)
Re: Clearly define "free software" (Ilya Zakharevich)
Re: Fastest way to read the last 'n' records in a file (Kevin Reid)
Re: GNU attacks on the open software community (Fergus Henderson)
Re: GPL documentation == unspeakable evil <stuartc@ind.tansu.com.au>
Re: GPL documentation == unspeakable evil (le Fanttme)
Re: GPL documentation == unspeakable evil <stuartc@ind.tansu.com.au>
how to install CPAN modules (LWP)? brz@hotmail.com
Re: how to install CPAN modules (LWP)? <rootbeer@teleport.com>
Re: how to make a Perl program receive email under Unix <zenin@bawdycaste.org>
Re: Perl and Web.pl, Gd Library, dmake question on NT (Gurusamy Sarathy)
Re: PERL Newbie Question <totengraber@geocities.com>
Re: TIP: watching for disk overruns <mgregory@asc.sps.mot.com>
Re: UW213: mkstemp out of PERL's DBfile? (Larry Rosenman)
Re: What is wrong with this FileHandle code? <mgregory@asc.sps.mot.com>
Re: while, each & assoc array (Paul David Fardy)
Digest Administrivia (Last modified: 8 Mar 97) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 25 May 1998 03:33:54 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: An unwelcome and undeserved slap
Message-Id: <6kaor2$5u$1@csnews.cs.colorado.edu>
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc, Stuart Cooper <stuartc@ind.tansu.com.au> writes:
:But their action in calling for free documentation for Perl is welcome.
No, it is not. More than merely unwelcome, such a calling is the pinnacle
of arrogance and folly: arrogance for their myopic misrepresentation of
our work, folly for aggravating a community whom they should in a just
world perceive as their allies. And one does not slap one's allies in
the face.
That web page and the subsequent commentary offered by their attendant
sycophants constitute nothing short of a veiled yet viscious insult
hurled at those of us who've worked incredibly hard for more a decade
to produce the free 1,000 page book that *is* the Perl documentation.
They can play their games of petty sophistry all they like, but the
bottom line remains that they have callously denigrated the efforts of
the Perl development community--a community, I shall note, in which
they have never played any role. It is not ``GNU Perl'', you know.
To date, they have made no move to recant, nor even to offer us a simple
explanation for this overs(l)ight. Mark my words: the FSF shall never write
anything on Perl that can even *begin* to compare with the 1,000-page
free book which they so condescendingly disregard.
Never.
--tom
--
[End of diatribe. We now return you to your regularly scheduled
programming...]
--Larry Wall in Configure from the perl distribution
------------------------------
Date: 25 May 1998 04:53:26 GMT
From: fjh@cs.mu.oz.au (Fergus Henderson)
Subject: Re: An unwelcome and undeserved slap
Message-Id: <6katg7$4br$1@mulga.cs.mu.OZ.AU>
Tom Christiansen <tchrist@mox.perl.com> writes:
...[various flames elided]...
>To date, they [the FSF] have made no move to recant, nor even to offer
>us a simple explanation for this overs(l)ight.
Have you tried a polite email?
I think you might get better results with than that
by continuing to flame in gnu.misc.discuss.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
------------------------------
Date: Mon, 25 May 1998 02:53:59 GMT
From: fantome/@/usa/./net (le Fanttme)
Subject: Re: Clearly define "free software"
Message-Id: <D363F84AEEDB050D.47792E6AF3AC8129.AD47EFCBF5A3BFAE@library-proxy.airnews.net>
On Mon, 25 May 1998 01:00:07 GMT, Barry Margolin
<barmar@bbnplanet.com> wrote:
>In article <B84A40540D3CC8E1.AECBB570ADA7C61A.53DD91CBD7941E65@library-proxy.airnews.net>,
>le Fanttme <fantome/@/usa/./net> wrote:
>>On Fri, 22 May 1998 04:54:08 GMT, Barry Margolin
>><barmar@bbnplanet.com> wrote:
>>>Because your right to distribute this would interfere with the recipient's
>>>right to modify. You can't both win, so one of you has to lose, and it's
>>>the one who wants to make a proprietary version.
>>
>>Actually, that's not true. The recipient would have the right to
>>modify the GNU GPLed source to work with another proprietary (or free)
>>licensed library/package. If I wrote something which interacted with
>>Oracle, you could possibly make it work with Sybase or maybe even gdbm
>>if you wanted to do so.
>But that's not what I said. The user should have the right to modify the
>entire thing.
Obviously, you're not understanding. You *do* have the right to modify
the whole thing. You can pick a free database engine to make this work
against, or a non-free one because the non-free one has the mission
critical performance you require. So *what* if you can't modify the
Oracle libraries? IMO, at the point when you install them legally on
your system, they are part of your system.
Really, it's not that difficult a concept.
Granted, it's also not the way that the GNU GPL works, but then again,
the GNU GPL doesn't work with other open source licenses that add any
level of restriction.
-f
--
austin ziegler * fantome*@*vnet*.*net * http://fantome.vnet.net/
---------------* aziegler*@*vcela*.*com * -------------------------
Remove the stars to email me * Ni bhionn an rath ach
my words my opinions my ideas * mar a mbionn an smacht
-- I Argue Ideas, Not Beliefs: Give Up Your Dogma --
------------------------------
Date: Mon, 25 May 1998 02:58:06 GMT
From: fantome/@/usa/./net (le Fanttme)
Subject: Re: Clearly define "free software"
Message-Id: <3045F8D552759C1B.D698F9CC85BB48D1.879890B1412A7B73@library-proxy.airnews.net>
On Mon, 25 May 1998 00:55:20 GMT, Barry Margolin
<barmar@bbnplanet.com> wrote:
>In article <E4C813D06F3694DA.29DFDB455831A2D5.8709D32254F36E8C@library-proxy.airnews.net>,
>le Fanttme <fantome/@/usa/./net> wrote:
>>On Fri, 22 May 1998 04:25:04 GMT, Barry Margolin
>><barmar@bbnplanet.com> wrote:
>>>You can link with proprietary libraries, but you can't redistribute the
>>>result. That's because the recipient would be restricted in what *he*
>>>could do with it. Giving you the rights you want means depriving someone
>>>else of their rights. RMS chose to preserve the users' rights over those
>>>of the people who want to make a proprietary derived works.
>>
>>Would the recipient be restricted? Those who need the modified package
>>would probably have the proprietary library, anyway.
>
>Why is that so probable?
>
>You keep using Oracle as an example. So you write a program that uses
>Oracle libraries, and I want to use it. But I don't have Oracle. So
>before I could use your program, I would have to buy Oracle.
It is likely you wouldn't have a desire to use the program unless you
had a database manager; just because I have chosen Oracle as my dbm
does not mean that it is meant to work against data in a relational
database.
>The GPL doesn't allow you to distribute incomplete derived works that
>require the user to buy other, proprietary software to use them. This
>would permit you to create a derived work that's *almost* functional, but
>then require the user to purchase a little "enabler" from you that makes
>the program work. In order to prohibit these end-runs around the rules,
>the GPL has to prohibit all such combinations.
No, you'd have to modify the code of my program to work with your
chosen SQL-based DBM. If I did it right, you could even copy my
"oracle-calls.pc" into a separate file (maybe "postgres.c") and modify
it to work with postgres and the modify my Makefile so that the
database of choice could be specified.
Programs which link against most proprietary libraries (such as the
Oracle ones) are not wholly bound to that proprietary library --
instead they are adaptable to other libraries which provide similar
functionality -- as the user needs and chooses.
-f
--
austin ziegler * fantome*@*vnet*.*net * http://fantome.vnet.net/
---------------* aziegler*@*vcela*.*com * -------------------------
Remove the stars to email me * Ni bhionn an rath ach
my words my opinions my ideas * mar a mbionn an smacht
-- I Argue Ideas, Not Beliefs: Give Up Your Dogma --
------------------------------
Date: 25 May 1998 04:03:40 GMT
From: ilya@math.ohio-state.edu (Ilya Zakharevich)
Subject: Re: Clearly define "free software"
Message-Id: <6kaqis$e70$1@mathserv.mps.ohio-state.edu>
[A complimentary Cc of this posting was sent to robert havoc pennington
<hp@pobox.com>],
who wrote in article <wsnu36fv7sl.fsf@harper.uchicago.edu>:
> > On all the platforms I know the details of, the dynamic linking is a
> > linking with a *name*. You cannot link with a "particular
> > implementation". You link with a library named "BLAH", the library
> > itself does not need to be even present at the time of linking (all
> > what is needed by linker is the name of the library, and names of
> > entry points).
> >
>
> What the FSF actually says about this, I believe, is that if there is
> another implementation available then linking does not make your
> program a derived work, but if the GPL library is the only
> implementation, then linking can only be considered linking *with that
> implementation* and thus you are creating a derived work and must GPL
> your program.
So I distribute readline.dll which contains the entry point named the
same as with GNU readline, but which are all forwarders to abort().
Do you think that after this it is OK to dynamically link with GNU
readline?
If yes, then the FSF position is silly.
If not, then it is look-and-feel copyrighting.
> Of course the LGPL is generally used for FSF libraries, with a few
> exceptions, so it doesn't matter.
In my communications with RMS about the above issue he stated that
they tried LGPL as an experiment, and consider this experiment as
failed.
Ilya
------------------------------
Date: Sun, 24 May 1998 23:54:47 -0400
From: kpreid@ibm.net (Kevin Reid)
Subject: Re: Fastest way to read the last 'n' records in a file
Message-Id: <1d9jotw.1lfxtiq1f2tfxsN@slip166-72-108-177.ny.us.ibm.net>
Phil Taylor <phil@ackltd.demon.co.uk> wrote:
> I want to add a new record to the start of a file, so that later, I
> can read the most recently stored 'n' records quickly. What is the
> most efficient way of doing this?
Make sure your records are all the same byte count; add records to the
end of the file; and then to read the most recent 'n' records:
seek FILE, -($n * $record_length), 2;
for ($i = 0; $i < $n; $i++) {
read FILE, $rec, $record_length;
# ... code here ...
}
--
Kevin Reid. | Macintosh.
"I'm me." | Think different.
------------------------------
Date: 25 May 1998 04:46:45 GMT
From: fjh@cs.mu.oz.au (Fergus Henderson)
Subject: Re: GNU attacks on the open software community
Message-Id: <6kat3l$3tu$1@mulga.cs.mu.OZ.AU>
pudge@pobox.com (Chris Nandor) writes:
>fjh@cs.mu.oz.au (Fergus Henderson) wrote:
>
># Why do you think Tom C. would lose?
>
>I have posted several times on why. Three main reasons: one, the license
>allows putting it on a for-profit CD, as long as no profit is received
>specifically for the perlfaq itself.
But this is a ridiculous position, as shown by John Stanley's
reductio ad absurdum of austin ziegler's continued defence of
this position.
The only way that a for-profit CD vendor can prove that no profit
was received for the perlfaq itself is to sell the whole CD at cost.
>Two, Tom loses his rights if he does
>not protect them, and he has knowingly allowed CDs to distribute
>for-profit CDs with perlfaq on them, and has done nothing to stop it.
>Three, Tom has specifically granted permission to put it on for-profit
>CDs.
OK, these are reasonable points (I don't know about number two, but
I defer to your no doubt better-informed judgement on that one).
Nevertheless it would of course be much better for Tom C. to make these
permissions explicit in his license.
Now, for all those who missed the start of this thread ;-),
here's a quick summary:
1. Tom C. flames F.S.F.
2. Much debate and flamage ensues.
3. Tom C. acknowledges that he needs to change
his licensing conditions.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
------------------------------
Date: 25 May 1998 12:18:45 +1000
From: Stuart Cooper <stuartc@ind.tansu.com.au>
Subject: Re: GPL documentation == unspeakable evil
Message-Id: <yeohg2fytx6.fsf@kudu.ind.tansu.com.au>
The FSF is to be applauded for trying to produce free (in their sense)
documentation for Perl. The O'Reilly Perl books, excellent as they are,
are not free- I can't photocopy them for friends, download them from the
web etc. etc. If the O'Reilly books are indispensable documentation for
Perl as a whole, than Perl as a whole is not free (in the GNU and the
monetary sense).
Of more concern is the "commercialisation" of Perl; with O'Reilly seemingly
becoming the owners of Perl. The Perl Resource Kit (PRK) is the most obvious
example of this trend; with the non-free "commercially enhanced" JPL stuff;
it comes with a Software License Agreement (make one copy only for backup
purposes, register for 30 days free support, special discount offers etc).
People who don't like the GNU Public License can read the PRK license and see
which they prefer.
Volumes 1 and 2 of the PRK I found interesting; straight copies of the
module documentation with a 'compilation copyright' (the compilation doesn't
seem that original either; the chapters are organised in the same order as
a view of CPAN. Maybe CPAN is in violation of ORA's "compilation copyright"?)
My CD with the PRK remains unopened.
The copyrighting of the image of a camel is another interesting issue.
It makes me wonder where Perl is heading. How much of Perl is free, how much
will remain free? Will there be a free Perl 6 and a "commercially enhanced"
Perl 6; available only from ORA, just like the JPL stuff? The "open source"
software model allows for this practice; I read somewhere there may
be differing free and commercial versions of several familiar Internet
programs on the way.
Richard Stallman might ask for our money; but he doesn't sell out his ideals.
>From where I sit, his contribution to free software has been enormous. His
fight to have a computer system running only free software continues. Will
there have to be a GNU-Perl in the future to satisfy this?
Tom C, O'Reilly have made a comfortable living from making non-free
documentation on free GNU software. You shouldn't complain if the FSF now
wishes to write free documentation on Perl. It would be an invaluable resource
to Perl for there to be GNU-free documentation on Perl to the same level as the
O'Reilly books 'Learning Perl', 'Programming Perl' and 'Advanced Perl
Programming'. Of course, there is a huge quantity of free documentation with
the perl*.pod pages; it's just that a book presentation is useful too.
It's a nice turnaround, isn't it? Instead of non-free documentation being
written by O'Reilly about GNU freeware, free documentation will be written
by FSF about an increasing O'Reilly-centric Perl.
Sure, the GNU might be a bit petty in their insistence on calling Linux systems
GNU/Linux systems; sure they might be left behind with their late Hurd.
But their action in calling for free documentation for Perl is welcome.
Stuart Cooper
stuartc@ind.tansu.com.au
------------------------------
Date: Mon, 25 May 1998 02:51:25 GMT
From: fantome/@/usa/./net (le Fanttme)
Subject: Re: GPL documentation == unspeakable evil
Message-Id: <392E8AF883790FB2.47102D500F233DB8.9532F9C163CA3B4F@library-proxy.airnews.net>
On 25 May 1998 12:18:45 +1000, Stuart Cooper
<stuartc@ind.tansu.com.au> wrote:
>The FSF is to be applauded for trying to produce free (in their sense)
>documentation for Perl. The O'Reilly Perl books, excellent as they are,
>are not free- I can't photocopy them for friends, download them from the
>web etc. etc. If the O'Reilly books are indispensable documentation for
>Perl as a whole, than Perl as a whole is not free (in the GNU and the
>monetary sense).
This statement is, of course, silly. People buy the O'Reilly books
because they are so damned good. I don't yet own a copy of anything
except the Perl Reference (for Perl 5) because the on-line
documentation has been quite comprehensive (and the few times when
I've taken the time to compare, has been closely related to the text
in the published books). As an additional note, some of my colleagues
were able to download a .ps or PDF version of the Perl 5.004 Perl
Reference and print it out for anyone who needed a copy at work.
>Of more concern is the "commercialisation" of Perl; with O'Reilly seemingly
>becoming the owners of Perl.
Of more concern to who? Do you just not understand that without some
level of commercial support (by which I mean the ability to use the
software without it necessarily being required to give up your own
intellectual property), free software will end up being mostly
irrelevant? I'm not, as many people think I am, faulting the FSF and
the GNU project for their moral stance -- I think it is stupid, but
more to the point, there are just too many impractical folks in the
FSF who feel that idealism toward this questionable goal far exceeds
the results gained with practicality. The FSF has completely forgotten
that there are carrots to be offered, but far prefers its stick.
>The Perl Resource Kit (PRK) is the most obvious
>example of this trend; with the non-free "commercially enhanced" JPL stuff;
>it comes with a Software License Agreement (make one copy only for backup
>purposes, register for 30 days free support, special discount offers etc).
>People who don't like the GNU Public License can read the PRK license and see
>which they prefer.
You don't have to buy the PRK. Really. You don't. Perl itself remains
free.
>Volumes 1 and 2 of the PRK I found interesting; straight copies of the
>module documentation with a 'compilation copyright' (the compilation doesn't
>seem that original either; the chapters are organised in the same order as
>a view of CPAN. Maybe CPAN is in violation of ORA's "compilation copyright"?)
>My CD with the PRK remains unopened.
Your choice.
>The copyrighting of the image of a camel is another interesting issue.
>It makes me wonder where Perl is heading. How much of Perl is free, how much
>will remain free? Will there be a free Perl 6 and a "commercially enhanced"
>Perl 6; available only from ORA, just like the JPL stuff? The "open source"
>software model allows for this practice; I read somewhere there may
>be differing free and commercial versions of several familiar Internet
>programs on the way.
Do people not understand that the Camel has become a sort of trademark
item for Perl, and it *must* be protected?
>Richard Stallman might ask for our money; but he doesn't sell out his ideals.
He can't find buyers for his ideals -- only zealots.
It'd be nice if you had a few facts before you posted your diatribe.
-f
--
austin ziegler * fantome*@*vnet*.*net * http://fantome.vnet.net/
---------------* aziegler*@*vcela*.*com * -------------------------
Remove the stars to email me * Ni bhionn an rath ach
my words my opinions my ideas * mar a mbionn an smacht
-- I Argue Ideas, Not Beliefs: Give Up Your Dogma --
------------------------------
Date: 25 May 1998 14:30:13 +1000
From: Stuart Cooper <stuartc@ind.tansu.com.au>
Subject: Re: GPL documentation == unspeakable evil
Message-Id: <yeopvh3ug4q.fsf@kudu.ind.tansu.com.au>
> FSF will never write anything for Perl. They don't understand it,
> and they don't like it.
> Furthermore, you once again callously disregard the free, 1,000-page
> book we have already produced.
Here's what I wrote:
================================================================
Tom C, O'Reilly have made a comfortable living from making non-free
documentation on free GNU software. You shouldn't complain if the FSF now
wishes to write free documentation on Perl. It would be an invaluable resource
to Perl for there to be GNU-free documentation on Perl to the same level as the
O'Reilly books 'Learning Perl', 'Programming Perl' and 'Advanced Perl
Programming'. Of course, there is a huge quantity of free documentation with
the perl*.pod pages; it's just that a book presentation is useful too.
================================================================
I leave it to others to decide if the last sentence counts as callous
disregard.
> :But their action in calling for free documentation for Perl is welcome.
> No, it is not. More than merely unwelcome, such a calling is the pinnacle
> of arrogance and folly: arrogance for their myopic misrepresentation of
> our work, folly for aggravating a community whom they should in a just
> world perceive as their allies. And one does not slap one's allies in
> the face.
Here's what it says in the GNU task list:
(www.fsf.org/prep/tasks_3.html)
================================================================
A good free manual for Perl.
(There are proprietary books, but these are no good, because
they are being withheld from our community by their owners.)
================================================================
> That web page and the subsequent commentary offered by their attendant
> sycophants constitute nothing short of a veiled yet viscious insult
> hurled at those of us who've worked incredibly hard for more a decade
> to produce the free 1,000 page book that *is* the Perl documentation.
> They can play their games of petty sophistry all they like, but the
> bottom line remains that they have callously denigrated the efforts of
> the Perl development community--a community, I shall note, in which
> they have never played any role. It is not ``GNU Perl'', you know.
As I read the web page; they are asking for a GNU-free manual. I imagine
they are thinking something in the vein of the GNU Emacs manual, or the
GNU Emacs Lisp reference manual. Something more akin to 'Programming Perl',
containing all the information of the free *.pod pages; but in a book-form.
You can order the GNU manuals from the FSF; once you get them you can share
them with your friends.
Thanks for all the on-line free documentation with Perl, the newsgroup
postings and the FMTYEWTK series. The level of free documentation supplied
with Perl, and in the Perl Modules, is outstanding. I really don't see this
being disputed by the FSF or their lickspittles.
Yes, it's not 'GNU Perl'. Is it "O'Reilly Perl"? Because that's who you need
to turn to for the definitive, 646 page bible of the language; 'Programming
Perl'.
> To date, they have made no move to recant, nor even to offer us a simple
> explanation for this overs(l)ight. Mark my words: the FSF shall never write
> anything on Perl that can even *begin* to compare with the 1,000-page
> free book which they so condescendingly disregard.
I think the simplest explanation is that they don't see the indivdual pod
pages collectively as a 1000 page book. As I read it, the task list item
is calling for such a book; a free equivalent of the book 'Programming Perl'.
In my opinion; there is no single, free Perl manual, 1000 pages or otherwise.
That's my explanation.
Stuart Cooper
stuartc@ind.tansu.com.au
------------------------------
Date: Mon, 25 May 1998 03:35:21 GMT
From: brz@hotmail.com
Subject: how to install CPAN modules (LWP)?
Message-Id: <6kaotq$gp6$1@nnrp1.dejanews.com>
Hi all:
This is a really basic question but I'm at my wits' end.. I read
the README of libwww again and again but still couldn't figure out
how.
Basically I'm trying to install LWP on solaris as a regular user
(not root) and couldn't get it to work. I ran
perl Makefile.PL PREFIX=/export/home/brz
make
make test
make install
Everything was ok but at the last line I got an error:
sh: /export/home/brz/lib/perl5/sun4-solaris/5.003/perllocal.pod: cannot create
*** Error code 1
make: Fatal error: Command failed for target `doc_site_install'
I thought it's not a huge deal if I couldn't get documentation but...
I couldn't get the test programs to work!
I got this error:
Can't locate LWP/UserAgent.pm in @INC at v.pl line 5.
BEGIN failed--compilation aborted at v.pl line 5.
and my program v.pl looks like:
#!/usr/local/bin/perl
BEGIN {
unshift(@INC, "/export/home/brz/lib");
}
use LWP::UserAgent;
$ua = new LWP::UserAgent;
my $req = new HTTP::Request 'GET', 'http://www.netscape.com';
my $res = $ua->request($req);
print $res->as_string;
Can someone tell me what I did wrong? Thanks!!!
Brz
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
------------------------------
Date: Mon, 25 May 1998 04:31:59 GMT
From: Tom Phoenix <rootbeer@teleport.com>
To: brz@hotmail.com
Subject: Re: how to install CPAN modules (LWP)?
Message-Id: <Pine.GSO.3.96.980524212756.12823B-100000@user2.teleport.com>
On Mon, 25 May 1998 brz@hotmail.com wrote:
> Everything was ok but at the last line I got an error:
>
> sh: /export/home/brz/lib/perl5/sun4-solaris/5.003/perllocal.pod: cannot create
It looks as if you don't have write permission in (at least) one of the
directories along that path. Could that be it? (I don't know why that
should be the case, though.)
Are you saying that make test reported no problems?
Are you certain that the module you're building is compatible with 5.003
Perl? Maybe you need to install 5.004. Since it has a number of important
security-related fixes over 5.003, I recommend that you ask your sysadmin
to install it at once. (It's not necessary to remove 5.003 to install
5.004, though.)
Hope this helps!
--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/
------------------------------
Date: 25 May 1998 03:11:21 GMT
From: Zenin <zenin@bawdycaste.org>
Subject: Re: how to make a Perl program receive email under Unix?
Message-Id: <896066323.474832@thrush.omix.com>
[posted & mailed]
Benjamin Geer <benjamin.geer@worldnet.att.net> wrote:
: For a CGI application, I need to write a Perl program (on a Unix
: machine) that receives and processes email. Is there a standard way
: of doing this?
A sendmail alias. Two ways of doing it. If you don't actually
want to create a real account (no /etc/passwd entry), just enter
an alias in the /etc/aliases file like such:
my_name: "|/path/to/my/mail/parsing/program and some arguments"
(remembering to run newaliases afterwards)
Or, if you create an account in /etc/passwd, you can use a .forward
file with the same syntax:
$ cat /usr/home/my_name/.forward
"|/path/to/my/mail/parsing/program and some arguments"
In either case, your program will see the full message (headers
as well) via stdin.
See the sendmail, forward, and aliases man pages for further
details.
: I would also appreciate any recommendations about Perl modules for
: processing email and MIME attachments.
Search CPAN for "MIME". There's a few with differing features.
--
-Zenin
zenin@archive.rhps.org
------------------------------
Date: 25 May 1998 02:29:20 GMT
From: gsar@engin.umich.edu (Gurusamy Sarathy)
Subject: Re: Perl and Web.pl, Gd Library, dmake question on NT
Message-Id: <6kal20$eh1@srvr1.engin.umich.edu>
[ mailed and posted ]
In article <35689A1F.2CF9D4E8@citenet.net>,
Frederic Jeanbart <telenet@citenet.net> wrote:
>1- libraries, modules:
>----------------------
>I am not able to install some modules. One is the GD ver. 1.18 interface
>to Boutel's gd library, for making GIFs "on the fly".
>After "Perl Makefile.PL", which seems ok (makefiles for
>libgd and for GD), "dmake.exe" returns errors.
>Anyone with a clue?
>Here is the dmake output:
>***SNIP******************************************************
>mkdir blib
>mkdir blib\lib
>cp GD.pm blib\lib\GD.pm
>AutoSplitting GD (blib\lib\auto/GD)
>cp qd.pl blib\lib\qd.pl
>DEFINE=''; export DEFINE INC; \
> cd libgd && d:\perl\bin\dmake.exe -S all DEFINE=
>The name specified is not recognized as an
>internal or external command, operable program or batch file.
>dmake.exe: Error code 1, while making 'libgd/libgd.lib'
>***SNIP******************************************************
Apply the attached patch. (cc-ed to Lincoln Stein <lstein@w3.org>)
>2- dmake.exe question
>----------------------
>Every time I se install instructions for modules or libraries, to the
>"make.exe" program, even for modules geared towards Win32 platforms.
>With Gurusamy Sarathy's Perl 5.004_2 port to Win32, supposed to be
>standard Perl, there is a dmake.exe which I use instead. But am I
>missing something, since there is no reference to that make application
>anywhere?
See, for instance: http://www.perl.com/CPAN/modules/INSTALL.html
- Sarathy.
gsar@umich.edu
-----------------------------------8<-----------------------------------
diff -ur GD-1.18/Makefile.PL GD-1.18-w32/Makefile.PL
--- GD-1.18/Makefile.PL Sun May 24 22:25:59 1998
+++ GD-1.18-w32/Makefile.PL Sun May 10 21:40:51 1998
@@ -20,6 +20,8 @@
sub MY::postamble {
my $postamble =<<'END';
$(MYEXTLIB): libgd/Makefile
+END
+ $postamble .= <<'END' unless $^O eq 'MSWin32';
DEFINE='$(DEFINE)'; export DEFINE INC; \
END
diff -ur GD-1.18/libgd/Makefile.PL GD-1.18-w32/libgd/Makefile.PL
--- GD-1.18/libgd/Makefile.PL Sun May 24 22:25:59 1998
+++ GD-1.18-w32/libgd/Makefile.PL Sun May 24 22:28:26 1998
@@ -22,6 +22,7 @@
all :: static
static :: libgd$(LIB_EXT)
+ $(NOOP)
config ::
End of Patch.
------------------------------
Date: Sun, 24 May 1998 22:31:14 -0400
From: Todd & Michelle <totengraber@geocities.com>
To: Ken Adams <kerebrusFSPAM@bigfoot.com>
Subject: Re: PERL Newbie Question
Message-Id: <3568D7F2.12C36521@geocities.com>
What I would do is:
print "Content-type: text/html\n\n"; # Don't forget this line when doing
HTML.
($sec,$min,$hr,$dom,$mon,$yr,$wkd,$doy,$isdst)=localtime(time); # Get the
current time.
# Might consider concatenating $hr and $min before comparing to be more
exact.
if ($hr > 14 && $hr < 18) { #if the hour is greater than 2pm and less than
6pm...
#print HTML code.
} else {
#print other HTML code
}
(Code may need tweking, but it is the general idea.) Hope this helps.
Todd
Ken Adams wrote:
> I haven't done any Perl yet, but I'm wondering how to do this (should
> be fairly simple);
>
> Have a perl script check the server's time, and if the time is between
> 2pm and 6pm, then it prints a line or two of HTML code.
>
> Can anybody give me the quickie solution to this? Thanks!
>
> Ken
------------------------------
Date: 25 May 1998 09:40:06 +0930
From: Martin Gregory <mgregory@asc.sps.mot.com>
Subject: Re: TIP: watching for disk overruns
Message-Id: <r8d8d3us69.fsf@asc.sps.mot.com>
Tom Christiansen <tchrist@mox.perl.com> writes:
> If you're writing a filter that writes to standard output, you
> might accidentally fill up the disk and not know it. One solution
> that doesn't require checking each print statement but still provides
> decent error messages and exit status is adding this to your program:
>
> END { close(STDOUT) || die "can't close stdout: $!" }
Top Tip!
Are these tips archived anywhere? (explicitly, I mean)
Ta,
Martin.
------------------------------
Date: Mon, 25 May 1998 02:29:51 GMT
From: ler@lerami.lerctr.org (Larry Rosenman)
Subject: Re: UW213: mkstemp out of PERL's DBfile?
Message-Id: <EtHqxr.J3s@lerami.lerctr.org>
In article <EtFI2u.1I4@lerami.lerctr.org>,
Larry Rosenman <ler@lerami.lerctr.org> wrote:
>I upgraded to 2.1.3, and now my PERL 5.004.04 stopped working for
>DBfile.
>
>I get an error about mkstemp:
>Can't load '/usr/local/lib/perl5/i386-svr4/5.00404/auto/DB_File/DB_File.so' for
>module DB_File: dynamic linker: /usr/bin/perl: relocation error: symbol not foun
>d: mkstemp at /usr/local/lib/perl5/i386-svr4/5.00404/DynaLoader.pm line 166.
>
> at ./index.pl line 18
>BEGIN failed--compilation aborted at ./index.pl line 18.
>$
>
>Anyone else seen this or know how to fix it (I've tried the obvious
>of rebuilding PERL from scratch, no luck).
>
>Larry Rosenman
>--
>Larry Rosenman http://www.lerctr.org/~ler
>Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
>US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Following up my own post...
The PERL 5.004.04 build doesn't take libc89.a into account for DB_File, which it
should.
I have hacked up the build, and all is well now...
Larry Rosenman
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
------------------------------
Date: 25 May 1998 09:31:04 +0930
From: Martin Gregory <mgregory@asc.sps.mot.com>
Subject: Re: What is wrong with this FileHandle code?
Message-Id: <r8g1hzuslb.fsf@asc.sps.mot.com>
Tom Christiansen <tchrist@mox.perl.com> writes:
> [courtesy cc of this posting sent to cited author via email]
>
> In comp.lang.perl.misc, Martin Gregory <mgregory@asc.sps.mot.com> writes:
> :You have yet to quantify this claim, nor explain why it is true.
>
> It seems subclever to suck in nearly 5,000 lines of code and
> seventeen files merely to say:
>
> $fh = FileHandle->new();
> open($fh, "< $path");
>
> instead of
>
> open(FH, "< $path");
>
Eryq made the point that the most efficient low-level way of doing
things is not necessarily the best way.
Further more, who really cares how long (within reason) it takes to
load? What one generally cares about is how fast the ongoing IO
operations are.
But even more to the point, it is only "subclever" _if_ you could be
expected to know about the inefficiencies. "FileHandle" is included
with perl. There are no warnings to the effect that it is a
inefficient implementation. Indeed, there are numerous suggestions
that it is the way to go. If a person had not read this thread, and
continued to use FileHandle, would that make them "subclever"?
(The only warning I've found relates to the fact that it is poxy
because it is not subclassable: very poxy, but not the point.)
Finally, you comment doesn't explain the claim that my question was
querying :-)
You claimed (I think) that ->getline was 10 times slower than <>. I
find it suprising that any amount of clumsiness in method invocation
could outwiegh the fundamental slowness of the IO operation, and hoped
that you could illuminate the issue.
Thanks,
Martin.
------------------------------
Date: 25 May 1998 04:19:53 GMT
From: pdf@morgan.ucs.mun.ca (Paul David Fardy)
Subject: Re: while, each & assoc array
Message-Id: <6karh9$lks$1@coranto.ucs.mun.ca>
"David A. Lyons" <lyonsd@atl.hp.com> decries the One-True Brace Style
as "sloppy and difficult to read".
Do you think that Kernighan and Ritchie are simply inexperienced?
It's not that they--or Larry--can't be wrong (though I don't think
they are on this point), but every programmer of C-derived languages
should recognize the K&R style and be comfortable with it, even if they
don't prefer it. Your opinion notwithstanding, the style is consistent
and clear.
I don't think that K&R or any seminal work is untouchable. I dislike
Stroustrup's "int* ptr;" and I discourage it's use because it suggests
that "int* ptr1, ptr2;" is a declaration of two pointers.
This isn't good idiom. It's just idiosyncrasy.
Then, again, I think Stroustrup is out to lunch with his use of
variable-width italics is the 3rd edition, so maybe that's just me.
Tom: where do you think Bjarne is headed? Methinks a stopover in
purgatory might be appropriate. :-)
"David A. Lyons" <lyonsd@atl.hp.com> writes:
> It makes a big difference when you start getting into a lot of
> nested blocks.
Indeed, this is is one of the better arguments for using the
one-true brace style: everyone should recognize it; noone should
be confused by it. I think you find it confusing because you've
strayed, perhaps too far, from the path.
>From my own experience, I find that code with "a lot of nested blocks"
can be improved by factoring code for clarity and reuse. Sometimes
deep nesting is simply a sign that your method needs to be redesigned.
--
If you've gotten this far, maybe you aren't completely bored with
the subject. Can anyone explain why some don't like "cuddled
elses"? I find that cuddled elses increase the likelihood that
a particular block of code can be displayed fully in limited space
which usually eases comprehension.
Paul Fardy
--
Paul David Fardy | pdf@morgan.ucs.mun.ca
Computing and Communications | pdf@InfoNET.st-johns.nf.ca
Memorial University of Newfoundland |
St. John's, NF A1C 5S7 |
------------------------------
Date: 8 Mar 97 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 8 Mar 97)
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 V8 Issue 2712
**************************************
