[21733] in Perl-Users-Digest
Perl-Users Digest, Issue: 3937 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Oct 8 21:06:26 2002
Date: Tue, 8 Oct 2002 18:05:10 -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 Tue, 8 Oct 2002 Volume: 10 Number: 3937
Today's topics:
Re: 96-column punched-card data <goldbb2@earthlink.net>
Dereferencing syntax Q <penny1482@attbi.com>
Re: Dereferencing syntax Q <REMOVEsdnCAPS@comcast.net>
Re: Dereferencing syntax Q (Tad McClellan)
Re: effect of "use <version>" on forward-compatibility? <mjcarman@mchsi.com>
Re: effect of "use <version>" on forward-compatibility? (Tad McClellan)
Re: effect of "use <version>" on forward-compatibility? <vhg@byu.edu>
Re: effect of "use <version>" on forward-compatibility? <goldbb2@earthlink.net>
Re: Flag processing <REMOVEsdnCAPS@comcast.net>
Re: help with perl map??? <REMOVEsdnCAPS@comcast.net>
Not so simple RE problem... <dd@4pro.net>
Re: perl user interface to tar. <mike_constant@yahoo.com>
Posting Guidelines for comp.lang.perl.misc ($Revision: tadmc@augustmail.com
Re: Posting Guidelines for comp.lang.perl.misc ($Revisi <tom.beer@btfinancialgroup.spamfilter.com>
Re: Regexp: Extracting HTML img src (Tad McClellan)
Re: shell/perl question: how processes get invoked? <jayasena@cs.uiuc.edu>
Re: Slow SCript Execution <nobody@nowhere.com>
Re: Slow SCript Execution <REMOVEsdnCAPS@comcast.net>
Re: Slow SCript Execution (Tad McClellan)
Re: Split a string <REMOVEsdnCAPS@comcast.net>
Re: synonymous subroutines <johannes.fuernkranz@t-online.de>
tagging Subject header (was Re: TM:2 DBI questions) (Tad McClellan)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 08 Oct 2002 18:35:18 -0400
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: 96-column punched-card data
Message-Id: <3DA35DA6.5562E3C9@earthlink.net>
Robert Brooks wrote:
>
> > There may be more efficient ways to do it, but here's my go:
> >
> > #!perl -ln
> > use integer;
> > use constant TRANSLATE =>
> > (map $_ * 3 + 0, 0..31),
> > (map $_ * 3 + 1, 0..31),
> > (map $_ * 3 + 2, 0..31);
> > print +(split //)[TRANSLATE];
> > __END__
> > [untested]
>
> Sorry - I rushed an earlier reply.
>
> Your code works! Now I just wish I understood how?!
First, the #! line ... the two things on the end, "-nl", are command
line options that get passed to perl. To learn about them and other
such options, type "perldoc perlrun" from your command line.
The 'use constant TRANSLATE => stuff' makes a special token, TRANSLATE,
which which when used, has the same meaning as the stuff on the right
side of the "=>" symbol (which is called a fat comma, since it acts
mostly like a normal comma, but it's funny looking...).
You can learn about 'use constant' by typing "perldoc constant", and you
can learn about the => symbol by typing "perldoc perlop"
Perhaps it would have been clearer if I'd done:
@translate =
(map $_ * 3 + 0, 0..31),
(map $_ * 3 + 1, 0..31),
(map $_ * 3 + 2, 0..31);
Except, due to the effects of the "-n" commandline option, this would be
inside the implicit loop that that option creates ... it's almost always
faster to move stuff outside of loops when possible, so by using a
constant, I speed the program up a bit.
The map operator takes a block of code, or an expression, and a list,
and applies that block to each element of the list, and returns a new
list. So:
map $_ * 3 + 0, 0..31
produces a list of the numbers 0, 3, 6, 9, ...
map $_ * 3 + 1, 0..31
produces a list of the numbers 1, 4, 7, 10, ...
map $_ * 3 + 2, 0..31
produces a list of the numbers 3, 5, 8, 11, ...
Running these three lists together, one after the next, produces a list
of the indices of the original string that are wanted in the output
string. (Perl's indices start from 0, not from 1)
It's sortof as if I'd done:
use constant "TRANSLATE",
0, 3, 6, 9 .... 90, 93,
1, 4, 7, 10 .... 91, 94,
2, 5, 8, 11 .... 92, 95;
[but of course with the .... things expanded]
This line:
print +(split //)[TRANSLATE];
Could be written more verbosely as:
@temp = split //, $_;
@reordered = @temp[TRANSLATE];
print @reordered;
The split makes a list of strings which are one character each.
The @temp[TRANSLATE] acts as if I'd done:
@reordered = @temp[0, 3, 6, ... 90, 93, 1, 4, ..... 95];
Which is the same as:
@reordered = $temp[0], $temp[3], $temp[6] ...... $temp[95];
And the print, of course, prints it out.
To learn about the split and print operators, type perldoc -f split, and
perldoc -f print.
To learn about how @x[a,b] is like $x[a],$x[b], type perldoc perldata (I
think that's where it is). Note that you don't need a literal list for
the a,b in the "[]" .... you could use something like @x[@translate],
and it will become like $x[$translate[0]], $x[$translate[1]] ....
> After keying in your code to Perl script, I fed it
> a file as if the card reader had transmitted the
> data and it printed out EXACTLY the correct order
> of data.
>
> Wow! Wish I had some years of Perl experience built up
> if only to see what the heck is going on here!
--
my $n = 2; print +(split //, 'e,4c3H r ktulrnsJ2tPaeh'
."\n1oa! er")[map $n = ($n * 24 + 30) % 31, (42) x 26]
------------------------------
Date: Tue, 08 Oct 2002 22:18:43 GMT
From: "Dick Penny" <penny1482@attbi.com>
Subject: Dereferencing syntax Q
Message-Id: <3RIo9.12834$hb4.2743@sccrnsc02>
The 1st snippet demonstrates (to me) that I understand reference &
dereference thingys. However my 2nd snippet where I store and pass the
reference via a hash (in a module) fails. Can someone see why and offer
suggestions?
_________snippet 1
my $ref = \@lines;
print Dumper @lines;
print Dumper $ref;
print Dumper @$ref; # ****
__________snippet 2
$self->{Summry} = \@summry; #created in initialize sub
# other subs using this hash work fine
sub range
{ my $self = shift;
print Dumper $self->{Summry}; #this looks good
print Dumper @$self->{Summry}; #this gives compile error (but **** above
did not)
#so how do I do a foreach over the original entries of @summry?
#I thought of binding order, so I also tried
print Dumper @($self->{Summry}); #no good either
--
Dick Penny
------------------------------
Date: Tue, 08 Oct 2002 18:09:24 CDT
From: "Eric J. Roode" <REMOVEsdnCAPS@comcast.net>
Subject: Re: Dereferencing syntax Q
Message-Id: <Xns92A1C2C752C0sdn.comcast@216.166.71.239>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
"Dick Penny" <penny1482@attbi.com> wrote in
news:3RIo9.12834$hb4.2743@sccrnsc02:
> The 1st snippet demonstrates (to me) that I understand reference &
> dereference thingys. However my 2nd snippet where I store and pass the
> reference via a hash (in a module) fails. Can someone see why and
> offer suggestions?
> _________snippet 1
> my $ref = \@lines;
> print Dumper @lines;
> print Dumper $ref;
> print Dumper @$ref; # ****
>
> __________snippet 2
> $self->{Summry} = \@summry; #created in initialize sub
> # other subs using this hash work fine
>
> sub range
> { my $self = shift;
> print Dumper $self->{Summry}; #this looks good
> print Dumper @$self->{Summry}; #this gives compile error (but ****
> above
> did not)
It's a matter of precedence. In effect, the expression is read left-to-
right, so:
@$self->{foo}
is
@{$self} -> {foo}
not
@{ $self->{foo} }
So your statement is taking $self, and trying to do @$self (ie, treating
it like an array reference) (which it's not, which is why you get a
compiler error) instead of doing $self->{Summry} first and then
dereferencing it.
> #so how do I do a foreach over the original entries of @summry?
foreach $e (@{$self->{Summry}})
> #I thought of binding order, so I also tried
> print Dumper @($self->{Summry}); #no good either
Very close -- you need curly braces:
print Dumper @{$self->{Summry}};
- --
Eric
print scalar reverse sort qw p ekca lre reh
ts uJ p, $/.r, map $_.$", qw e p h tona e;
-----BEGIN xxx SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBPaNlgWPeouIeTNHoEQJcxgCgolRdXVXf+3nIfD/gv5WF82bTp8EAoODo
JhGrppi9lBAVw/9ejd1tCgmi
=otPg
-----END PGP SIGNATURE-----
------------------------------
Date: Tue, 8 Oct 2002 19:44:02 -0500
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: Dereferencing syntax Q
Message-Id: <slrnaq6uui.4eb.tadmc@magna.augustmail.com>
Dick Penny <penny1482@attbi.com> wrote:
> #so how do I do a foreach over the original entries of @summry?
By applying "Use Rule 1" from perlreftut.pod.
1) pretend it is a plain array:
foreach ( @ra ) {
2) replace the array's name with a block:
foreach ( @{} ) {
3) fill in the block with something that returns a reference
to an array:
foreach ( @{ $self->{Summry} } ) {
> #I thought of binding order, so I also tried
> print Dumper @($self->{Summry}); #no good either
Use curly braces instead of parenthesis.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Tue, 08 Oct 2002 16:35:28 -0500
From: Michael Carman <mjcarman@mchsi.com>
Subject: Re: effect of "use <version>" on forward-compatibility?
Message-Id: <anvj26$t6e2@onews.collins.rockwell.com>
On 10/8/02 4:00 PM, Vaughn Gardner wrote:
>
> I'm trying to convince a very conservative operations center to upgrade
> the version of Perl available on our boxes. I'd like to guarantee that
> old code would work on the newer version (we have versions as old as
> 4.0.1.8 with code running against them).
Yikes! Perl4 is terribly old, unsupported and has various bugs and
security holes that have been fixed in later versions.
About the only thing you can do to ensure "forward" compatibility is to
not use anything that has been deprecated when writing your code. Of
course, that doesn't mean that <feature> won't be deprecated/removed in
the future, so you can't really do it. Fortunately, the authors of Perl
have taken great pains to ensure that new versions of Perl are backwards
compatible, which means that most old scripts can run under newer Perls
without changes.
> Does the "use <version>" pragma help with forward compatibility in any
> way? I know that it will make the code fail if run against an earlier
> version...
No, it's just a way to ensure the minimum version of perl needed in
cases where the script depends on something either unavailable or broken
in older versions.
-mjc
------------------------------
Date: Tue, 8 Oct 2002 17:56:43 -0500
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: effect of "use <version>" on forward-compatibility?
Message-Id: <slrnaq6olb.3ur.tadmc@magna.augustmail.com>
Vaughn Gardner <vhg@byu.edu> wrote:
> I'm trying to convince a very conservative operations center to upgrade
> the version of Perl available on our boxes.
Conservative folks would want to plug widely publicized
security holes, I would think.
Point them to the CERT advisories about old Perl versions,
maybe that will be enough to get them to move.
> I'd like to guarantee that
> old code would work on the newer version
You cannot make that guarantee.
All we need is one counter-example to show that, here's one:
$email = "vhg@byu.edu";
works fine in perl4, syntax error in (early) perl5's.
(Perl 5 added the ability to interpolate arrays.)
A very large number of programs should run fine, but "guarantee"
implies "all" rather than just "most".
> (we have versions as old as
> 4.0.1.8 with code running against them).
That is not a Perl version number. I think you mean v4.036.
Are they so conservative that they are still running Windows 3.1
on their PeeCees too? :-)
(Perl4 was contemporary with 3.1)
> Does the "use <version>" pragma help with forward compatibility in any
> way?
No.
But that question is out of left field, given your description
of the situation that preceeds it.
You need help with _backward_ compatibility, as in:
Is v5.8.0 backward compatible with programs written for v4.036
> I know that it will make the code fail if run against an earlier
> version...
"use version" won't help you.
Reviewing all of the perldelta.pod and perltrap.pod between then
and now might help.
But I'd just test them and see first.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Tue, 08 Oct 2002 17:33:52 -0600
From: Vaughn Gardner <vhg@byu.edu>
Subject: Re: effect of "use <version>" on forward-compatibility?
Message-Id: <3DA36B60.2090702@byu.edu>
Thanks for the response!
Benjamin Goldberg wrote:
> Just have your newer version of perl installed somewhere else. The
> scripts with a normal #! line will continue to work, and the ones which
> ask the 'env' program to find them, or else are started with "perl x.pl"
> might possibly break, but they should be small enough in number to find
> them and fix them.
>
> For new scripts, using the newer versions of perl, you just do:
> #!/path/to/newer/perl
> which may be something like:
> #!/usr/bin/perl5.6.1
> or
> #!/usr/bin/perl5.8.0
What I'd really like to do is reduce the confusion among the developers
while also getting them to code against the newer version. Ideally,
they would all have
#! /usr/bin/perl
as their #! line, and it would point to the most recent version. Since
we're already running multiple versions, I guess it's OK to add one more
to the mix.
Would it be worth my time to write a script to point all current scripts
to the previous version before installing the new version? I know that
Larry et al. do their best to maintain backward compatibility, but I'm
not sure that I can convince the operations center of that.
>>Does the "use <version>" pragma help with forward compatibility in any
>>way?
>
>
> Not that I know of.
Darn. Thanks again!
Vaughn
------------------------------
Date: Tue, 08 Oct 2002 20:42:49 -0400
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: effect of "use <version>" on forward-compatibility?
Message-Id: <3DA37B89.40140BDD@earthlink.net>
Vaughn Gardner wrote:
>
> Thanks for the response!
>
> Benjamin Goldberg wrote:
> > Just have your newer version of perl installed somewhere else. The
> > scripts with a normal #! line will continue to work, and the ones
> > which ask the 'env' program to find them, or else are started with
> > "perl x.pl" might possibly break, but they should be small enough in
> > number to find them and fix them.
> >
> > For new scripts, using the newer versions of perl, you just do:
> > #!/path/to/newer/perl
> > which may be something like:
> > #!/usr/bin/perl5.6.1
> > or
> > #!/usr/bin/perl5.8.0
>
> What I'd really like to do is reduce the confusion among the
> developers while also getting them to code against the newer version.
> Ideally, they would all have
> #! /usr/bin/perl
> as their #! line, and it would point to the most recent version.
Most sites have more than one directory in the default $PATH ... often
including something like /usr/local/bin/ or /usr/opt or ... many types
of things.
*That* is where you should install your newer perl.
The old perl4, you leave in /usr/bin/perl, and you leave the old perl4
scripts with #!/usr/bin/perl as their shebang line.
The new perl5, you put in /usr/local/bin/perl (or wherever), and you
have your devopers write perl5 scripts, and put #!/usr/local/bin/perl
(or whatever) as their shebang line.
Because /usr/local/bin comes before /usr/bin, when a developer simply
types 'perl', he gets the newer one, not the older one.
Because the old perl4 scripts have /usr/bin/perl hardcoded, that's what
they get -- the old perl4 program. Which means that they don't have to
be modified to work in spite of your having installed a newer perl.
> Since we're already running multiple versions, I guess it's OK to add
> one more to the mix.
>
> Would it be worth my time to write a script to point all current
> scripts to the previous version before installing the new version? I
> know that Larry et al. do their best to maintain backward
> compatibility, but I'm not sure that I can convince the operations
> center of that.
Have the new perl installed in such a way that the old perl scripts
don't have to be modified. *That* will convince the operations center
that it's ok to do.
--
my $n = 2; print +(split //, 'e,4c3H r ktulrnsJ2tPaeh'
."\n1oa! er")[map $n = ($n * 24 + 30) % 31, (42) x 26]
------------------------------
Date: Tue, 08 Oct 2002 17:50:57 CDT
From: "Eric J. Roode" <REMOVEsdnCAPS@comcast.net>
Subject: Re: Flag processing
Message-Id: <Xns92A1BFA6AD0CCsdn.comcast@216.166.71.239>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
"Teh (tî'pô)" <teh@mindless.com> wrote in
news:f7p5quo2qogn9j3o6vr8kfi9k14h40a8or@4ax.com:
>
> What's the preferred way to do stuff like this?
For anything other than the trivial, I use GetOpt::Long.
But your s/// solution is a good way, too.
- --
Eric
print scalar reverse sort qw p ekca lre reh
ts uJ p, $/.r, map $_.$", qw e p h tona e;
-----BEGIN xxx SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBPaNhLmPeouIeTNHoEQJadgCfUCfcOiNvdpt6vwyl8dBMsklNFJ4AoLN/
4MAl63sLr++jthmRzgJLN7pp
=Ot6c
-----END PGP SIGNATURE-----
------------------------------
Date: Tue, 08 Oct 2002 17:54:31 CDT
From: "Eric J. Roode" <REMOVEsdnCAPS@comcast.net>
Subject: Re: help with perl map???
Message-Id: <Xns92A1C0414516Csdn.comcast@216.166.71.239>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
mdrons@yahoo.com (Mike) wrote in news:19a14a2c.0210080619.104fd9a2
@posting.google.com:
> Can someone please tell me what this is doing?
>
> map {$_ = ['re', $_]} @args;
What this is doing is replacing each element ($_) of @args with a reference
to a two-element array (the first element of which is the string 're', the
second of which is the original array element).
This statement would transform
(1, 2, 3)
into
( ['re', 1], ['re', 2], ['re', 3])
Make sense?
There's nothing really wrong with the above, but map-with-side-effects-and-
no-return-value is usually written as a foreach loop:
$_ = ['re', $_] foreach @args;
- --
Eric
print scalar reverse sort qw p ekca lre reh
ts uJ p, $/.r, map $_.$", qw e p h tona e;
-----BEGIN xxx SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBPaNiA2PeouIeTNHoEQKoggCgtV2EVHPa+tZP6gL1dG+hUzY4TaIAoOXo
5LM8gOJHYz/1pN/WGeZ1vv76
=R3NG
-----END PGP SIGNATURE-----
------------------------------
Date: Tue, 8 Oct 2002 20:57:34 -0400
From: "Domizio Demichelis" <dd@4pro.net>
Subject: Not so simple RE problem...
Message-Id: <anvuuo$hu4d1$1@ID-159100.news.dfncis.de>
I have a problem that I thought was simple to solve, until I tried :-)
I have this string:
$string = << '__EOS__';
aaa {a} bbb {a} ccc {a} XXX {b} XXX {/a} ddd
aaa {b} bbb {b} ccc {a} XXX {/a} ddd
aaa {a}{/a} bbb {a} ccc {a} ddd
__EOS__
I need to replace the "{a}.*?{/a}" and the "{a}" (without the end {/a})
with a "#", so - after the search and replace operation - the $string should
contain this:
"aaa # bbb # ccc # ddd
aaa {b} bbb {b} ccc # ddd
aaa # bbb # ccc # ddd"
Note: $string could contain everything (.+) (and not just the \w that I put
in the example to make it simpler to understand), the lines are not well
organized as they appear in the example, and... I should use the content
between {a} and {/a}. ( as in qr|{a}(.*?){/a}| )
I'm loosing my mind trying very complicated RE and very slow loops.
How could I do it (possibly) fast?
Thank you
--
-.. --- -- .. --.. .. ---
-.. . -- .. -.-. .... . .-.. .. ...
------------------------------
Date: Tue, 8 Oct 2002 17:21:38 -0700
From: "Newbie" <mike_constant@yahoo.com>
Subject: Re: perl user interface to tar.
Message-Id: <anvsr1$i4mrj$1@ID-161864.news.dfncis.de>
"dave" <dmehler@siscom.net> wrote in message
news:3da3467d$0$38592$9a6e19ea@news.newshosting.com...
> Hello,
> Does anyone have a perl UI to the unix tar program? I'm looking for
> something that implements identical functionality to the dump/restore UI
but
> in perl and for tar and optionally gzip.
> Thanks.
> Dave.
This question was answered a few weeks back.
use Archive::Tar;
PS: Please check answers to your post before re-posting the question.
------------------------------
Date: Tue, 08 Oct 2002 19:32:52 CDT
From: tadmc@augustmail.com
Subject: Posting Guidelines for comp.lang.perl.misc ($Revision: 1.2 $)
Message-Id: <5LOcnT6UYuup5D6gXTWcpQ@News.GigaNews.Com>
Outline
Before posting to comp.lang.perl.misc
Must
- Check the Perl Frequently Asked Questions (FAQ)
- Check the other standard Perl docs (*.pod)
Really Really Should
- Lurk for a while before posting
- Search a Usenet archive
If You Like
- Check Other Resources
Posting to comp.lang.perl.misc
Is there a better place to ask your question?
- Question should be about Perl, not about the application area
How to participate (post) in the clpmisc community
- Carefully choose the contents of your Subject header
- Use an effective followup style
- Speak Perl rather than English, when possible
- Ask perl to help you
- Do not re-type Perl code
- Provide enough information
- Do not provide too much information
- Do not post binaries, HTML, or MIME
Social faux pas to avoid
- Asking a Frequently Asked Question
- Asking a question easily answered by a cursory doc search
- Asking for emailed answers
- Beware of saying "doesn't work"
- Sending a "stealth" Cc copy
Be extra cautious when you get upset
- Count to ten before composing a followup when you are upset
- Count to ten after composing and before posting when you are upset
-----------------------------------------------------------------
Posting Guidelines for comp.lang.perl.misc ($Revision: 1.2 $)
This newsgroup, commonly called clpmisc, is a technical newsgroup
intended to be used for discussion of Perl related issues (except job
postings), whether it be comments or questions.
As you would expect, clpmisc discussions are usually very technical in
nature and there are conventions for conduct in technical newsgroups
going somewhat beyond those in non-technical newsgroups.
This article describes things that you should, and should not, do to
increase your chances of getting an answer to your Perl question. It is
available in POD, HTML and plain text formats at:
http://mail.augustmail.com/~tadmc/clpmisc.shtml
For more information about netiquette in general, see the "Netiquette
Guidelines" at:
http://andrew2.andrew.cmu.edu/rfc/rfc1855.html
A note to newsgroup "regulars":
Please do not use the existence of these guidelines as a
"license to flame" or other meanness. It is possible that
a poster is not aware of the things discussed here. Let's
give them the benefit of the doubt, and just help them learn
how to post, rather than assume that they do know and are
being the "bad kind" of Lazy.
A note about technical terms used here:
In this document, we use words like "must" and "should" in the
very precise sense that they're used in technical conversation
(such as you're likely to encounter in this newsgroup). When
we say that you *must* do something, we mean that if you don't
do that something, then it's very unlikely that you're going to
get much benefit from using this group. We're not trying to boss
you around; we're just trying to convey the point without using
a lot of words.
Do *NOT* send email to the maintainer of these guidelines. It will be
discarded unread. The guidelines belong to the newsgroup so all
discussion should appear in the newsgroup. I am just the secretary that
writes down the consensus of the group.
Before posting to comp.lang.perl.misc
Must
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.
The perl distribution includes documentation that is copied to your hard
drive when you install perl. Also installed is a program for looking
things up in that (and other) documentation named 'perldoc'.
You should either find out where the docs got installed on your system,
or use perldoc to find them for you. Type "perldoc perldoc" to learn how
to use perldoc itself. Type "perldoc perl" to start reading Perl's
standard documentation.
Check the Perl Frequently Asked Questions (FAQ)
Checking the FAQ before posting is required in Big 8 newsgroups in
general, there is nothing clpmisc-specific about this requirement.
You are expected to do this in nearly all newsgroups.
You can use the "-q" switch with perldoc to do a word search of the
questions in the Perl FAQs.
Check the other standard Perl docs (*.pod)
The perl distribution comes with much more documentation than is
available for most other newsgroups, so in clpmisc you should also
see if you can find an answer in the other (non-FAQ) standard docs
before posting.
It is *not* required, or even expected, that you actually *read* all of
Perl's standard docs, only that you spend a few minutes searching them
before posting.
Try doing a word-search in the standard docs for some words/phrases
taken from your problem statement or from your very carefully worded
"Subject:" header.
Really Really Should
This section describes things that you *really should* do before posting
to clpmisc.
Lurk for a while before posting
This is very important and is expected regardless of what newsgroup
you are visiting. Lurking means to simply monitor a newsgroup for a
period of time until you become very familiar with local customs.
Think of a newsgroup as foreign culture. Each newsgroup has its own
specific customs and rituals. Get to know those customs and rituals
well before you participate. This will help you to avoid
embarrassing social situations. Consider yourself to be a foreigner
at first!
Search a Usenet archive
There are tens of thousands of Perl programmers. It is very likely
that your question has already been asked (and answered). See if you
can find where it has already been answered.
One such searchable archive is:
http://groups.google.com/advanced_group_search
If You Like
This section describes things that you *can* do before posting to
clpmisc.
Check Other Resources
You may want to check in books or on web sites to see if you can
find the answer to your question.
But you need to consider the source of such information: there are a
lot of very poor Perl books and web sites, and several good ones
too, of course.
Posting to comp.lang.perl.misc
There can be 200 messages in clpmisc in a single day. Nobody is going to
read every article. They must decide somehow which articles they are
going to read, and which they will skip.
Your post is in competition with 199 other posts. You need to "win"
before a person who can help you will even read your question.
These sections describe how you can help keep your article from being
one of the "skipped" ones.
Is there a better place to ask your question?
Question should be about Perl, not about the application area
It can be difficult to separate out where your problem really is,
but you should make a conscious effort to post to the most
applicable newsgroup. That is, after all, where you are the most
likely to find the people who know how to answer your question.
Being able to "partition" a problem is an essential skill for
effectively troubleshooting programming problems. If you don't get
that right, you end up looking for answers in the wrong places.
It should be understood that you may not know that the root of your
problem is not Perl-related (the two most frequent ones are CGI and
Operating System related), so off-topic postings will happen from
time to time. Be gracious when someone helps you find a better place
to ask your question by pointing you to a more applicable newsgroup.
How to participate (post) in the clpmisc community
Carefully choose the contents of your Subject header
You have 40 precious characters of Subject to win out and be one of
the posts that gets read. Don't waste them. Take care while
composing them, they are the key that opens the door to getting an
answer.
Spend them indicating what aspect of Perl others will find if they
should decide to read your article.
Do not spend them indicating "experience level" (guru, newbie...).
Do not spend them pleading (please read, urgent, help!...).
Do not spend them on non-Subjects (Perl question, one-word
Subject...)
For more information on choosing a Subject see "Choosing Good
Subject Lines":
http://www.perl.com/CPAN-local/authors/Dean_Roehrich/subjects.post
Part of the beauty of newsgroup dynamics, is that you can contribute
to the community with your very first post! If your choice of
Subject leads a fellow Perler to find the thread you are starting,
then even asking a question helps us all.
Use an effective followup style
When composing a followup, quote only enough text to establish the
context for the comments that you will add. Always indicate who
wrote the quoted material. Never quote an entire article. Never
quote a .signature (unless that is what you are commenting on).
Intersperse your comments *following* the sections of quoted text
that your comments apply to. Failure to do this is called "Jeopardy"
posting because the answer comes before the question.
Reversing the chronology of the dialog makes it much harder to
understand (some folks won't even read it if written in that style).
For more information on quoting style, see:
http://www.geocities.com/nnqweb/nquote.html
Speak Perl rather than English, when possible
Perl is much more precise than natural language. Saying it in Perl
instead will avoid misunderstanding your question or problem.
Do not say: I have variable with "foo\tbar" in it.
Instead say: I have $var = "foo\tbar", or I have $var = 'foo\tbar',
or I have $var = <DATA> (and show the data line).
Ask perl to help you
You can ask perl itself to help you find common programming mistakes
by doing two things: enable warnings (perldoc warnings) and enable
"strict"ures (perldoc strict).
You should not bother the hundreds/thousands of readers of the
newsgroup without first seeing if a machine can help you find your
problem. It is demeaning to be asked to do the work of a machine. It
will annoy the readers of your article.
You can look up any of the messages that perl might issue to find
out what the message means and how to resolve the potential mistake
(perldoc perldiag). If you would like perl to look them up for you,
you can put "use diagnostics;" near the top of your program.
Do not re-type Perl code
Use copy/paste or your editor's "import" function rather than
attempting to type in your code. If you make a typo you will get
followups about your typos instead of about the question you are
trying to get answered.
Provide enough information
If you do the things in this item, you will have an Extremely Good
chance of getting people to try and help you with your problem!
These features are a really big bonus toward your question winning
out over all of the other posts that you are competing with.
First make a short (less than 20-30 lines) and *complete* program
that illustrates the problem you are having. People should be able
to run your program by copy/pasting the code from your article. (You
will find that doing this step very often reveals your problem
directly. Leading to an answer much more quickly and reliably than
posting to Usenet.)
Describe *precisely* the input to your program. Also provide example
input data for your program. If you need to show file input, use the
__DATA__ token (perldata.pod) to provide the file contents inside of
your Perl program.
Show the output (including the verbatim text of any messages) of
your program.
Describe how you want the output to be different from what you are
getting.
If you have no idea at all of how to code up your situation, be sure
to at least describe the 2 things that you *do* know: input and
desired output.
Do not provide too much information
Do not just post your entire program for debugging. Most especially
do not post someone *else's* entire program.
Do not post binaries, HTML, or MIME
clpmisc is a text only newsgroup. If you have images or binaries
that explain your question, put them in a publically accessible
place (like a Web server) and provide a pointer to that location. If
you include code, cut and paste it directly in the message body.
Don't attach anything to the message. Don't post vcards or HTML.
Many people (and even some Usenet servers) will automatically filter
out such messages. Many people will not be able to easily read your
post. Plain text is something everyone can read.
Social faux pas to avoid
The first two below are symptoms of lots of FAQ asking here in clpmisc.
It happens so often that folks will assume that it is happening yet
again. If you have looked but not found, or found but didn't understand
the docs, say so in your article.
Asking a Frequently Asked Question
It should be understood that you may have missed the applicable FAQ
when you checked, which is not a big deal. But if the Frequently
Asked Question is worded similar to your question, folks will assume
that you did not look at all. Don't become indignant at pointers to
the FAQ, particularly if it solves your problem.
Asking a question easily answered by a cursory doc search
If folks think you have not even tried the obvious step of reading
the docs applicable to your problem, they are likely to become
annoyed.
If you are flamed for not checking when you *did* check, then just
shrug it off (and take the answer that you got).
Asking for emailed answers
Emailed answers benefit one person. Posted answers benefit the
entire community. If folks can take the time to answer your
question, then you can take the time to go get the answer in the
same place where you asked the question.
It is OK to ask for a *copy* of the answer to be emailed, but many
will ignore such requests anyway. If you munge your address, you
should never expect (or ask) to get email in response to a Usenet
post.
Ask the question here, get the answer here (maybe).
Beware of saying "doesn't work"
This is a "red flag" phrase. If you find yourself writing that,
pause and see if you can't describe what is not working without
saying "doesn't work". That is, describe how it is not what you
want.
Sending a "stealth" Cc copy
A "stealth Cc" is when you both email and post a reply without
indicating *in the body* that you are doing so.
Be extra cautious when you get upset
Count to ten before composing a followup when you are upset
This is recommended in all Usenet newsgroups. Here in clpmisc, most
flaming sub-threads are not about any feature of Perl at all! They
are most often for what was seen as a breach of netiquette. If you
have lurked for a bit, then you will know what is expected and won't
make such posts in the first place.
But if you get upset, wait a while before writing your followup. I
recommend waiting at least 30 minutes.
Count to ten after composing and before posting when you are upset
After you have written your followup, wait *another* 30 minutes
before committing yourself by posting it. You cannot take it back
once it has been said.
AUTHOR
Tad McClellan <tadmc@augustmail.com> and many others on the
comp.lang.perl.misc newsgroup.
------------------------------
Date: Wed, 9 Oct 2002 11:03:10 +1000
From: "Tom Beer" <tom.beer@btfinancialgroup.spamfilter.com>
Subject: Re: Posting Guidelines for comp.lang.perl.misc ($Revision: 1.2 $)
Message-Id: <anvv8f$cth$1@merki.connect.com.au>
tadmc@augustmail.com wrote in message
<5LOcnT6UYuup5D6gXTWcpQ@News.GigaNews.Com>...
> Social faux pas to avoid
> - Sending a "stealth" Cc copy
What is a "stealth" cc copy and why should I avoid it?
Thanks,
Tom.
------------------------------
Date: Tue, 8 Oct 2002 17:35:50 -0500
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: Regexp: Extracting HTML img src
Message-Id: <slrnaq6ne6.3ur.tadmc@magna.augustmail.com>
nibl <nibl@onlinehome.de> wrote:
> I'm extracting HTML image
> tags.
No you're not, you are extracting angle-brackety looking text.
If you tackle HTML processing with pattern matching, then you
are not treating it as HTML data.
>It only gets the last image on each line
And it does not get images that span lines:
<IMG SRC
="path1">
nor images with other quotes:
<IMG SRC='path1'>
nor images with optional spaces:
<IMG SRC = "path1">
nor [a large list of others]
> my (@images) = ($output =~ m#.*<img\s+.*src="(.*)">.*#gi);
^^ ^^
^^ ^^
You don't need those dot-stars.
You do need non-greedy matching:
m#<img\s+.*?src="(.*?)">#gi
You can tighten it up a bit so that there are only a half million
ways to break it rather than the million that will break the
pattern above:
m#<img\s+[^>]*src\s*=\s*"([^"]*)">#gi
But that doesn't even handle all of the cases above.
> I know I could use HTML or XML::Parser, but that's a lot of bulk just
> for this.
That should be "that's a lot of bulk just for working properly",
since there is all kinds of legal HTML where your code will
not Do The Right Thing...
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Tue, 08 Oct 2002 19:05:23 -0500
From: "V. Sanath D. Jayasena" <jayasena@cs.uiuc.edu>
Subject: Re: shell/perl question: how processes get invoked?
Message-Id: <3DA372C3.8F4E8683@cs.uiuc.edu>
> I run the executable shell script at Unix prompt as: "> run-xyz.sh".
> BUT, the shell script invokes the perl script within the loop
> and DOES NOT wait until it is over; it simply goes around
> and start the next loop and repeats the same. So I have many
> "xyz" processes running concurrently. I don't want that because
> each input file causes "xyz" to be really CPU- and memory-intensive.
> I want one "xyz" process to run at a time (i.e., sequentially).
> My assumption was: a shell script would do things sequentially.
> The two scripts are given below. Any ideas/hints?
>
> --------------------------------------------------
> #!/usr/bin/sh
> #
> # run-xyz.sh
> #
> FILELIST=`ls *.dat`
> for infile in $FILELIST
> do
> perl run-xyz.pl $infile
> done
> --------------------------------------------------
> #!/local/all/perl
> #
> # run-xyz.pl
> #
> $INFILE = $ARGV[0];
> open(XYZ,"|xyz") || die "Can't start xyz\n" ;
> printf XYZ "read_dat $INFILE; ";
> # process data here by giving more commands to XYZ
> # each command terminated by ";"
> printf XYZ "write_dat $INFILE.result ; " ;
> printf XYZ "quit; ";
Thanks to Barry Margolin (from comp.unix.shell),
I found the problem: when I add the forgotten "close(XYZ);" at the
end of the Perl script, it works.
He also suggested the following method to do the job
with a single Perl Script (which works for me).
<quote>
Why not start a separate xyz session for each file in the perl script:
foreach $INFILE (@ARGV) {
open(XYZ, "|xyz") || die "Can't start xyz\n";
...
close(XYZ);
}
Then you can do:
run-xyz.pl *.dat
<end quote>
Sanath
------------------------------
Date: Wed, 9 Oct 2002 08:09:54 +1000
From: "Gregory Toomey" <nobody@nowhere.com>
Subject: Re: Slow SCript Execution
Message-Id: <BAIo9.48885$g9.140903@newsfeeds.bigpond.com>
Al C wrote in message ...
>I've got a script that strips and formats sniffer files. I've noticed that
>on long files the script gets slower and slower as it goes deeper into the
>file. Can someone explain this to me?
>
>thanks, Al.
>
Possibly your algorithm is non-linear ie not O(n).
Or perhaps your memory usage is increasing and swapping/garbage collection
is slowing things down.
gtoomey
------------------------------
Date: Tue, 08 Oct 2002 18:04:26 CDT
From: "Eric J. Roode" <REMOVEsdnCAPS@comcast.net>
Subject: Re: Slow SCript Execution
Message-Id: <Xns92A1C1F025Esdn.comcast@216.166.71.239>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
"Al C" <carriera@nortelnetworks.com> wrote in
news:anvgti$2tb$1@bcarh8ab.ca.nortel.com:
> I've got a script that strips and formats sniffer files. I've noticed
> that on long files the script gets slower and slower as it goes deeper
> into the file. Can someone explain this to me?
Sounds like your script slows down as it gets deeper into the file.
Seriously, your question has very little content to it -- almost no clues
as to what's going on. Care to provide more details?
- --
Eric
print scalar reverse sort qw p ekca lre reh
ts uJ p, $/.r, map $_.$", qw e p h tona e;
-----BEGIN xxx SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBPaNkWGPeouIeTNHoEQISYwCgkq1FKqhAC6jQEHC+9nvNu1+o0FIAoKld
5EQbGoeByox347dzUjNnXy5+
=xssa
-----END PGP SIGNATURE-----
------------------------------
Date: Tue, 8 Oct 2002 18:13:57 -0500
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: Slow SCript Execution
Message-Id: <slrnaq6pll.3ur.tadmc@magna.augustmail.com>
Al C <carriera@nortelnetworks.com> wrote:
> I've got a script that strips and formats sniffer files. I've noticed that
> on long files the script gets slower and slower as it goes deeper into the
> file. Can someone explain this to me?
No.
Show us your program if you want your program's behavior explained.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Tue, 08 Oct 2002 17:39:32 CDT
From: "Eric J. Roode" <REMOVEsdnCAPS@comcast.net>
Subject: Re: Split a string
Message-Id: <Xns92A1BDB731A23sdn.comcast@216.166.71.239>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
Dmitry_Babich@icomverse.com (Dmitry) wrote in
news:f21990ff.0210072219.6b8295f@posting.google.com:
> The question is not just theoretical.
> Consider utility that receives a string and should display it
> on the screen with 5 columns. We don't want the utility
> to split words, hence thus 2 condition. First condition is obvious.
How about the fine Text::Wrap module?
- --
Eric
print scalar reverse sort qw p ekca lre reh
ts uJ p, $/.r, map $_.$", qw e p h tona e;
-----BEGIN xxx SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBPaNegWPeouIeTNHoEQKF/gCgneyNmKzao7Zw5+0mqG/tuV3vdKMAnAqh
NBvYRetm8/5tWRdjk3I8G2zu
=6apV
-----END PGP SIGNATURE-----
------------------------------
Date: Wed, 09 Oct 2002 02:02:49 +0200
From: =?ISO-8859-1?Q?Johannes_F=FCrnkranz?= <johannes.fuernkranz@t-online.de>
Subject: Re: synonymous subroutines
Message-Id: <anvrqn$h4n$03$1@news.t-online.com>
Benjamin Goldberg wrote:
>
> I'm not surprised at your head-scratching. :)
> *Any* time a typeglob is used, something slightly magical happens.
> *Always*.
Well, you took away some of the magic. Thanks! :-)
> I really wish that there were documents, "perldoc perltypeglob" and
> "perldoc perlsymboltable", describing *typeglobs and %symbol::tables::
The pointer to perlmonth that Bart provided (thx Bart) is pretty good,
but unfortunately not part of perldoc.
Juffi
------------------------------
Date: Tue, 8 Oct 2002 18:03:59 -0500
From: tadmc@augustmail.com (Tad McClellan)
Subject: tagging Subject header (was Re: TM:2 DBI questions)
Message-Id: <slrnaq6p2v.3ur.tadmc@magna.augustmail.com>
Jeff Zucker <jeff@vpservices.com> wrote:
> [just a personal peeve, but I find the TM: in your subject lines
> distracting since it is only relevant to you]
I added it to my scorefile when I saw it, under the
"cutsie tricks in Subject" category, along with
"???" and "L@@K" etc. :-(
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
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 3937
***************************************
