[18721] in Perl-Users-Digest
Perl-Users Digest, Issue: 889 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun May 13 14:10:31 2001
Date: Sun, 13 May 2001 11:10:12 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <989777412-v10-i889@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Sun, 13 May 2001 Volume: 10 Number: 889
Today's topics:
Re: Posting Guidelines for comp.lang.perl.misc ($Revisi (Tad McClellan)
Re: Posting Guidelines for comp.lang.perl.misc ($Revisi (Tad McClellan)
Segmentation fault (core dumped) (reader of news)
Re: Segmentation fault (core dumped) (reader of news)
Re: Segmentation fault (core dumped) <keesh@users.pleaseremovethisbit.sourceforge.net>
Re: sorting filenames alphanumerically <dodger@necrosoft.net>
Re: Taint (Tad McClellan)
Re: Taint <dodger@necrosoft.net>
Re: Taint (M.J.T. Guy)
Re: testing offline <dan@nospam_dtbakerprojects.com>
Re: Wierd behavior from a Perl array in a function (Andrew J. Perrin)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 13 May 2001 08:09:42 -0400
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: Posting Guidelines for comp.lang.perl.misc ($Revision: 1.1 $)
Message-Id: <slrn9fsuc6.c5t.tadmc@tadmc26.august.net>
Andras Malatinszky <andras@mortgagestats.com> wrote:
>tadmc@augustmail.com wrote:
>Somewhere in these guidelines you should explicitly list a few topics that are
>not appropriate for this group but people tend to bring up anyway.
How about the:
"the two most frequent ones are CGI and Operating System related"
that is already in there?
>You might also
>mention topics that are not strictly about using the Perl programming language
>but are tolerated anyway, such as conference and seminar announcements.
If the conference/seminar is a Perl event, then it is on-topic.
No "tolerated" about it.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Sun, 13 May 2001 08:50:13 -0400
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: Posting Guidelines for comp.lang.perl.misc ($Revision: 1.1 $)
Message-Id: <slrn9ft0o5.c5t.tadmc@tadmc26.august.net>
[ Please limit your line lengths to the conventional 70-72 chars/line,
else they get hard to read after a few generations of quoting.
Thanks.
]
Andras Malatinszky <andras@mortgagestats.com> wrote:
>Tad McClellan wrote:
>> Andras Malatinszky <andras@mortgagestats.com> wrote:
>> >tadmc@augustmail.com wrote:
>> >> Before posting to comp.lang.perl.misc
>> >> Must
>> >
>> >Should.
>>
>> I cannot make the change you suggest.
>> I do not want to alienate the audience, of course.
>>
>> I also do not want to misinform them.
>>
>> What change would accomplish both of those objectives?
>I think you should try to avoid creating the impression that you are bossing
>people around
>How about simply expanding the
>first sentence in the "Must" along the lines of:
>
>"This section describes things that you *must* do before posting to clpmisc, in
>order to maximize your chances of getting meaningful replies to your inquiry and to
>avoid getting flamed for being lazy and trying to have others do your work."
That seems a change that would accomplish both objectives, I'll work
something like that into the intro part of the Must section.
>Maybe I'm unreasonably sensitive about this. It's just that I always preferred
>rules that had a clear reason behind them to rules that I was supposed to obey
>because some guy said so.
I am making a conscious effort to say What is expected while avoiding
explaining the Why of the expectations.
The posting would double in size if reasons were given for each point.
If it gets that big, folks won't read it.
I do not want to put Whys in here. We might make a stand-off article
(not autoposted) that presents the reasons for each point...
>I still think you might want to include a URL in the corresponding
>section of the document.
I do not want to do that. I will make some mention of finding the
standard docs installed along with perl though.
>> As another followup pointed out, I should make some mention of
>> _using_ perldoc. Right now, I mention it, but never "define" it.
>>
>> I will make some change mentioning that perldoc is for accessing
>> the docs.
Hopefully, adding an explanation of perldoc will be "enough" without a URL.
>What I mean is this:
>I believe that a major segment of the intended audience of this document is
>clueless about the documentation that perl distributions normally come with. If you
>tell this lot to "check the other standard Perl docs (*.pod)" their response is
>likely to be "what's that?" I think you should be a little more verbose here and
>explain what these docs are (yes, despite the fact that it is also explained
>elsewhere). If you follow my advice, you will increase the chance of people
>actually finding and reading/perusing that documentation and you will decrease the
>number of "Does perl have a random function?" type postings -- which, to me at
>least, is the main purpose of the document you are developing.
Let's see if the "using perldoc" change covers that. Bring it up again
after you see the revision if you think it doesn't cover it.
>I believe that inserting a book list
>(which maybe just a severely abridged version of perlbook) would increase the
>effectiveness of this document.
In the interests of keeping the article to a "reasonable" size, we
need to remove something to make room for additions (it is already
a little bigger than desired).
Is adding a book list important enough to remove some other part?
Which part should go to make room?
We're not going to get "everything we want" in a single post. We
need to jealously guard against it bloating to such a size that
it becomes ignored.
>> Examples of "bad" ones seems a waste of space.
>
>I wonder. If you know about specific resources that give bad advice to beginners,
>you can do them a big favor by warning them to stay away from those resources. But
>I realize that this can be a very contentious issue -- potential courtroom
>material, in fact.
Right. Much as I would like to warn them off from Matt's scripts,
I don't think it would be worth it.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Sun, 13 May 2001 16:54:03 GMT
From: newsreader@mediaone.net (reader of news)
Subject: Segmentation fault (core dumped)
Message-Id: <slrn9ftf2f.5h6.newsreader@dragon.universe>
What is the cause of a perl
script core dumping? I'm completely
baffled with this one. I
will search the archive and google
but just in case someone has a quick
answer...
Here is the cpan module list
I'm using
use Crypt::IDEA;
use LWP::UserAgent;
use DBI;
use HTTP::Request::Common;
use strict;
Also has a few other
personal modules.
The syntax is checked to
be correct with perl -c
------------------------------
Date: Sun, 13 May 2001 17:14:26 GMT
From: newsreader@mediaone.net (reader of news)
Subject: Re: Segmentation fault (core dumped)
Message-Id: <slrn9ftg8m.5kr.newsreader@dragon.universe>
I've figured it out.
wrong sql statment is the culprit.
die $dbh->errstr did not work.
------------------------------
Date: Sun, 13 May 2001 18:17:30 +0100
From: "Ciaran McCreesh" <keesh@users.pleaseremovethisbit.sourceforge.net>
Subject: Re: Segmentation fault (core dumped)
Message-Id: <9dmff6$711$1@newsg4.svr.pol.co.uk>
In article <slrn9ftf2f.5h6.newsreader@dragon.universe>, "reader of news"
<newsreader@mediaone.net> wrote:
> What is the cause of a perl
> script core dumping? I'm completely
> baffled with this one. I
> will search the archive and google
> but just in case someone has a quick
> answer...
[snip]
> Also has a few other
> personal modules.
Do you still get the error if you remove these modules? What's the rest
of the script? Does just use ing the CPAN modules with a print "Hello
World\n"; still cause the core dump?
> The syntax is checked to
> be correct with perl -c
That doesn't mean it won't dump core, only that it probably doesn't have
any syntax errors.
Please be more specific...
--
Ciaran McCreesh
mail: keesh@users.sourceforge.net
web: http://www.opensourcepan.com/
------------------------------
Date: Sun, 13 May 2001 16:59:30 GMT
From: "Dodger" <dodger@necrosoft.net>
Subject: Re: sorting filenames alphanumerically
Message-Id: <S3zL6.7750$LJ4.2654586@news1.rdc2.pa.home.com>
"Benjamin Goldberg" <goldbb2@earthlink.net> wrote in message
news:3AFE46CE.405B8916@earthlink.net...
> You don't need to use the transform in this case.
>
> @loadfiles = sort { $a cmp $b } @loadfiles;
>
> Should work fine.
This is the default behaviour of sort. You don't need the block in there.
@loadfiles = sort @loadfiles;
--
Dodger
www.dodger.org
www.necrosoft.net
www.gothic-classifieds.com
------------------------------
Date: Sun, 13 May 2001 09:01:00 -0400
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: Taint
Message-Id: <slrn9ft1cc.c5t.tadmc@tadmc26.august.net>
phookie <phookie@xmission.com> wrote:
>anyone know where i can get any good information on untainting ENV
>variables
I would start with the documentation for the software that you are
using. Tainting is covered in:
perldoc perlsec
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Sun, 13 May 2001 17:10:09 GMT
From: "Dodger" <dodger@necrosoft.net>
Subject: Re: Taint
Message-Id: <RdzL6.7767$LJ4.2657761@news1.rdc2.pa.home.com>
"phookie" <phookie@xmission.com> wrote in message
news:3AFDF6CE.F6B1CFD@xmission.com...
> anyone know where i can get any good information on untainting ENV
> variables used in forms which capture info via cgi , web server
> forms/cgi scripts...
everyone has referred you to perldoc perlsec. I do, too, but here's a bit
more:
$ENV{some_env_var} =~ s/^(.*)$/$1/; # now it's clean.
This works as a sub easily enough:
sub untaint ($) { my $val = shift; $val =~ s/^(.*)$/$1/; return $val }
Please note that if you screw yourself by using this stuff, I accept no
responsibility. There's a REASON they make you hunt.
--
Dodger
www.dodger.org
www.necrosoft.net
www.gothic-classifieds.com
------------------------------
Date: 13 May 2001 17:22:12 GMT
From: mjtg@cus.cam.ac.uk (M.J.T. Guy)
Subject: Re: Taint
Message-Id: <9dmfs4$al3$1@pegasus.csx.cam.ac.uk>
Dodger <dodger@necrosoft.net> wrote:
>
>everyone has referred you to perldoc perlsec. I do, too, but here's a bit
>more:
>
>$ENV{some_env_var} =~ s/^(.*)$/$1/; # now it's clean.
There's a good reason why people refer to perlsec - the exaples there
work. Your example of course does not.
Please do not post untested, incorrect code. It wastes everyones
time.
Mike Guy
------------------------------
Date: Sun, 13 May 2001 15:02:52 GMT
From: Dan Baker <dan@nospam_dtbakerprojects.com>
Subject: Re: testing offline
Message-Id: <3AFEA0B1.596D149E@nospam_dtbakerprojects.com>
Rudolf Polzer wrote:
>
> Dan Baker <dan@nospam_dtbakerprojects.com> wrote:
> >
> >
> > Amelia Clarke wrote:
> > >
> > > I'm fairly new to perl and have been using it to make cgi scripts - the
> > > only thing is, I'd like to be able to test them fully offline. Is there
> > > a (free) program I can download to allow me to do this?
> > ----------------
> >
> > I use a simple free webserver that runs great on win98 from
> > www.xitami.com
>
> Does it support PATH_INFO? Could you try to execute some CGI script with an
> appended '/test.path'?
-------------------------------
I'm not positive I understand your question....
I does load typical ENV variable and the perl follows all its normal env
vars as well. The only thing the free version doesnt support is SSL.
Otherwise it is a fully functional webserver running on your PC. Its
nice because its such a small executable that doesnt hog resources, and
WAY easier to configure than Apache or IIS.
D
------------------------------
Date: 13 May 2001 13:10:03 -0500
From: andrew_perrin@unc.edu (Andrew J. Perrin)
Subject: Re: Wierd behavior from a Perl array in a function
Message-Id: <87lmo1ktms.fsf@nujoma.perrins>
falc2199@aol.comNOJUNK (Falc2199) writes:
> I have the following function which I use to print the contents of an array
> (along with some JavaScript code)....
>
> sub putDataInArr
> {
> print $_[0];
>
> @temp = $_[1];
>
> foreach $question (@temp)
> {
> chomp ($question);
>
> print " $question,";
>
> }
>
> print $_[2];
>
> }
>
> and call it like this...
>
> putDataInArr('threadQ = [', @Tarray, ']');
>
> But this only prints the first 'threadQ = [' and then the first 2 elements of
> the Perl array. It does not print any of the remiaining elements or the closing
> ']' ( the last argument).
>
> Can anyone tell me what is wrong?
Sure - you should read up on how perl subroutines work (perldoc
perlsub). In a nutshell, parameters are passed as one big array,
accessed in the sub as @_. You create one list, such that @_ is:
( 'threadQ = [',
$Tarray[0],
$Tarray[1],
...
$Tarray[$#Tarray],
']')
and then you only access elements 0, 1, and 2 of @_.
You can either loop through @_, possibly first snipping off elements 0
and -1, or if you want to use semantics similar to your original ones,
try passing @Tarray as a reference; perldoc perlref for more.
--
----------------------------------------------------------------------
Andrew J Perrin - Ph.D. Candidate, UC Berkeley, Dept. of Sociology
(Soon: Asst Professor of Sociology, U of North Carolina, Chapel Hill)
andrew_perrin@unc.edu - http://www.unc.edu/~aperrin
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 889
**************************************
