[32073] in Perl-Users-Digest
Perl-Users Digest, Issue: 3337 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Mar 29 06:09:43 2011
Date: Tue, 29 Mar 2011 03:09:06 -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, 29 Mar 2011 Volume: 11 Number: 3337
Today's topics:
Posting Guidelines for comp.lang.perl.misc ($Revision: tadmc@seesig.invalid
Re: REVISED: Variable length array to XML <thepoet_nospam@arcor.de>
Re: REVISED: Variable length array to XML <tadmc@seesig.invalid>
Re: REVISED: Variable length array to XML <jwkrahn@example.com>
Search script to index dynamic pages <rdw204@gmail.com>
Re: Search script to index dynamic pages <kkeller-usenet@wombat.san-francisco.ca.us>
Re: Search script to index dynamic pages <sherm.pendley@gmail.com>
two attempts at DBI connect call <dn.perl@gmail.com>
Re: using File::Find <Uno@example.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 29 Mar 2011 02:14:56 -0500
From: tadmc@seesig.invalid
Subject: Posting Guidelines for comp.lang.perl.misc ($Revision: 1.9 $)
Message-Id: <0qKdnbbBD71tGwzQnZ2dnUVZ5oWdnZ2d@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.9 $)
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.
The article at:
http://www.catb.org/~esr/faqs/smart-questions.html
describes how to get answers from technical people in general.
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://www.rehabitation.com/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":
Do not use these guidelines as a "license to flame" or other
meanness. It is possible that a poster is unaware of things
discussed here. 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" as
they're used in technical conversation (such as you will
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 unlikely that you will benefit much from this group.
We're not bossing you around; we're making the point without
lots 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 expected in all newsgroups. Lurking means
to monitor a newsgroup for a period to become familiar with local
customs. Each newsgroup has specific customs and rituals. Knowing
these before you participate will help 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_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.cpan.org/authors/id/D/DM/DMR/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* each section of quoted text to
which they relate. Unappreciated followup styles are referred to as
"top-posting", "Jeopardy" (because the answer comes before the
question), or "TOFU" (Text Over, Fullquote Under).
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://web.presby.edu/~nnqadmin/nnq/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 and many others on the comp.lang.perl.misc newsgroup.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Mon, 28 Mar 2011 21:05:29 +0200
From: Christian Winter <thepoet_nospam@arcor.de>
Subject: Re: REVISED: Variable length array to XML
Message-Id: <4d90dbfa$0$6764$9b4e6d93@newsspool3.arcor-online.net>
Am 28.03.2011 16:29, schrieb Don Pich:
> I've been messing with this on and off since my last post. Here is my
> current code (cleaned up thanks to advice in this board, and made shorter
> - Took out some unnecessary arrays):
I wouldn't say cleaned up, rather replaced with something even
stranger.
> ___CODE___
>
> #!/usr/bin/perl
> use strict;
> use warnings;
> use Data::Dumper;
> my $infile = '/media/Docs/Scripts/Perl/Putty/TEST.csv';
> open (CSVFILE, $infile) || die ("Could not open $infile! $!");
> my @final = ();
> my @temp1 = ();
> my @temp2 = ();
No need to assign empty lists there.
my @final, @temp1, @temp2;
would suffice, but I'll get to that again...
> while (my $line =<CSVFILE>) {
> $line =~ tr/"\r\n//d;
> $line =~ s/\\/:/g;
If your example input code is really representative for the
whole of it, it doesn't make sense to replace the backslashes
with something else if all you do with it later is splitting
on it.
> (my $C1,my $C2,my $C3,my $C4) = split ',', $line;
> my @temp1 = split (':', $C2);
Here you could as well say
my @temp1 = split /\\/, $C2;
Though now I'm scratching my head why you declare @temp1
outside of the loop without using it and redeclare it
on the inside again.
> shift (@temp1);
> my $tempcount = @temp1;
> for (my $a = 0 ; $a<= $tempcount-1; $a++) {
> push ( @temp2, $temp1[$a] );
> }
That's a rather roundabout way for
@temp2 = @temp1;
> push ( @temp2, $C1 );
> push ( @temp2, $C4 );
The syntax of push is
push ARRAY,LIST
so it lets you say
push @temp2, $C1, $C4;
> my $temp2count = @temp2;
> unshift ( @temp2, $temp2count );
Why are you switching to @temp2 at all, if you don't use
@temp1 anyway? Everything after the "shift (@temp1)" line
could be condensed to
push @temp1, $C1, $C4;
unshift @temp1, scalar(@temp1);
if you write
> push @final, [ @temp2 ];
push @final, [@temp1];
> $temp2count = 0;
Unneccessary, it gets overwritten each loop anyway.
> @temp2 = ();
> @temp1 = ();
And ditto for @temp1, it's defined with "my" inside the scope
of the loop, so when the loop ends it goes out of scope, and in
the next iteration your @temp1 will be a virgin array.
> }
> close $infile;
> exit(0);
All in all, your loop can be reduced to:
while (my $line =<CSVFILE>) {
$line =~ tr/"\r\n//d;
my @c = split /,/, $line;
my @temp1 = split /\\/, $c[1];
shift (@temp1);
push ( @temp1, $c[0], $c[3] );
unshift ( @temp1, scalar @temp1 );
push @final, [ @temp1 ];
}
> ___CODE___
>
> Here is PART of the input
>
> ___ INPUT ___
>
> "Default Settings","Sessions","",""
> "ADMSND70AFC.01","Sessions\NOC-CO\AFC","","172.16.22.34"
> "ARTHND16AFC.01","Sessions\NOC-CO\AFC","","172.16.22.26"
> "CAVWND48AFC.01","Sessions\NOC-CO\AFC","","172.16.22.6"
> "CRYSND04AFC.01","Sessions\NOC-CO\AFC","","172.16.22.46"
> "CVLRND10AFC.01","Sessions\NOC-CO\AFC","","172.16.22.90"
> "PKRVND05AFC.04 GFTN","Sessions\NOC-CO\AFC","","172.16.22.110"
> "PMBNND60AFC.01","Sessions\NOC-CO\AFC","","172.16.22.78"
> "STTMND02AFC.01","Sessions\NOC-CO\AFC","","172.16.22.74"
> "WLCTND67AFC.01","Sessions\NOC-CO\AFC","","172.16.22.114"
> "WVTNMN74AFC.01 DMAX","Sessions\NOC-CO\AFC","","172.16.22.94"
> "WVTNMN74AFC.02 UMC1000","Sessions\NOC-CO\AFC","","172.16.22.102"
> "PKRVND05APMAX.01","Sessions\NOC-CO\APMAX","","apuser@172.16.1.145"
> "PKRVND05APMAX.02","Sessions\NOC-CO\APMAX","","apuser@172.16.1.146"
> "DVN cisco","Sessions\NOC-CO\Cisco","","10.243.255.250"
> "DYTNND01C1924.01","Sessions\NOC-CO\Cisco\1900 Series","","172.16.19.175"
> "PKRVND05C1924.01","Sessions\NOC-CO\Cisco\1900 Series","","172.16.19.171"
>
> ___ INPUT ___
>
> Here is the Output:
>
> I want to ignore the first line ('Default' etc)
You can do that by either reading from <INFILE> once outside
the loop or by adding
next if( $. == 1 );
inside. See "perldoc perlvar" for the exact meaning of "$."
> and remove 'Sessions' as
> putting that into this information is redundant. I also counted how may
> array elements are in each array within the array (i.e. the first line
> has four elements (NOC-CO,AFC,ADMSND70AFC.01,172.16.22.34). Hence, the
> first array element is the count of array elements. Not necessarily sure
> if it's necessary, but it's there.
It isn't, getting the length of the arrays is cheap.
> What I am really having a hard time wrapping my head around is that it's
> obvious that a hash is a better choice for sorting this data. I think
> I'm making a mistake by actually using an array, but I understand
> arrays. Hashes are simpler, but I must be missing the point.
Not neccessarily. Hashes are flexible and save memory if you have
deep structures with identically named branches, and they win out
if you need to access your data by names instead of ordinals.
> My goal is to do as others have posted:
>
> ___ DESIRED RESULTS ___
>
> <SESSION>
> <NOC-CO>
> <AFC>
> <ADMSND70AFC.01>
> <172.16.22.34>
> </ADMSND70AFC.01>
> etc...
The "etc..." is what makes it impossible to suggest a precise solution.
Do you rather want to it read
<SESSION>
<NOC-CO>
<AFC>
<ADMSND70AFC.01>
<172.16.22.34>
</ADMSND70AFC.01>
</AFC>
<NOC-CO>
<NOC-CO>
<AFC>
<ARTHND16AFC.01>
<172.16.22.26>
</ARTHND16AFC.01>
</AFC>
<NOC-CO>
</SESSION>
or do you want to get
<SESSION>
<NOC-CO>
<AFC>
<ADMSND70AFC.01>
<172.16.22.34>
</ADMSND70AFC.01>
<ARTHND16AFC.01>
<172.16.22.26>
</ARTHND16AFC.01>
</AFC>
<NOC-CO>
</SESSION>
? Both are xml.
If you want to go for the first one, arrays are just fine.
If you want the second one, a hash may be more fitting, as its
structure already reflects what the output will be - and there
are xml modules that can take a hash and output xml in one go.
> ___ DESIRED RESULTS ___
>
> The code below should be what I need.
>
> ___ PROPOSED ADDITIONAL CODE ___
>
> print qq(<SESSION>\n);
> foreach my $k1 (sort keys %session)
> {
> print qq(<$k1>\n);
> foreach my $k2 (sort keys %{$session{$k1}})
> {
> print qq(<$k2>\n);
> foreach my $k3 (sort keys %{$session{$k1}{$k2}})
> {
> print qq(<$k3>\n);
> print qq( $session{$k1}{$k2}{$k3}\n);
> print qq(</$k3>\n);
> }
> print qq(</$k2>\n);
> }
> print qq(</$k1>\n);
> }
> print qq(</SESSION>\n);
>
> ___ PROPOSED ADDITIONAL CODE ___
Or might not be what you want, considering that it can only
handle data with fixed depth.
> I'm having a hard time wrapping my head around populating the hash.
You can either do as I showed in my other reply, populate your leaf's
hash structure bottom up and merge it with the main hash by using a
module, or you've got to work a lot with references and give yourself
a serious headache ;)
I'll try to put together a small working piece of code (and I'm
assuming there's no element count in the arrays):
First thing is to iterate over all the leafs, but the hash has
to be defined outside, so I'll start with
my %hash;
foreach my $leaf (@final)
{
// $leaf is a reference to an array
// the work goes here
}
Now I know already that I need to work on varying deepth inside
the hash. Unless I want a really deeply nested set of if-clauses
and to repeat my code again and again, I need some kind of pointer
variable that lets me work with a single name.
my $ptr = \%hash;
$ptr now stores a reference to my hash and can be changed to
point somewhere else without destroying the hash.
Next thing would be to iterate of all the elements of the leaf,
but meditating over my structure a bit, I find that I have to
take care of two distinct cases:
For one, there are nodes that point to other nodes, or, in terms
of a hash, that hold another hash reference. And then there's
the end node which points to a plain scalar. It's the second to
last element in the array, so I'll stop my loop there and take
care of the special case in an if clause.
foreach my $i ( 0 .. $#$leaf - 1 ) {
my $node = $leaf->[$i];
if( $i != $#$leaf - 1 ) {
// code when we have a middle node
} else {
// the end node
}
}
That's well and good, now the tricky part begins - to move the
$ptr reference forward in the hash structure while constructing
that. The code for that would need to make the current hash key in
our current depth point to a hash again and then make $ptr point
to that deeper hash instead of the current one.
$ptr->{$node} = {};
But wait - that would overwrite existing elements in the hash.
So I change that to
$ptr->{$node} = {}
unless( exists $ptr->{$node} );
And to move the pointer forward:
$ptr = $ptr->{$node};
My inner loop now looks like this:
foreach my $i ( 0 .. $#$leaf - 1 ) {
my $node = $leaf->[$i];
if( $i != $#$leaf - 1 ) {
$ptr->{$node} = {}
unless( exists $ptr->{$node} );
$ptr = $ptr->{$node};
} else {
// the end node
}
}
Adding the end node is rather straight forward now:
$ptr->{$node} = $leaf->[$i + 1];
So here's the complete code:
my %hash;
foreach my $leaf (@final) {
my $ptr = \%hash;
foreach my $i ( 0 .. $#$leaf - 1 ) {
my $node = $leaf->[$i];
if( $i != $#$leaf - 1 ) {
$ptr->{$node} = {}
unless( exists $ptr->{$node} );
$ptr = $ptr->{$node};
} else {
$ptr->{$node} = $leaf->[$i + 1];
}
}
}
HTH
-Chris
------------------------------
Date: Mon, 28 Mar 2011 14:44:45 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: REVISED: Variable length array to XML
Message-Id: <slrnip1p05.fto.tadmc@tadbox.sbcglobal.net>
Don Pich <dpich@polartel.com> wrote:
> (my $C1,my $C2,my $C3,my $C4) = split ',', $line;
Yuk!
One declaration with 4 variables is easier to read than 4 declarations.
A regular expression should *look like* a regular expression.
my($C1, $C2, $C3, $C4) = split /,/, $line;
But sequentially-numbered variable names are almost always a
red flag that indicates you should be using an array instead.
my @columns = split /,/, $line;
> my @temp1 = split (':', $C2);
> shift (@temp1);
What a worthless choice of variable name!
Choose a more valuable name.
Above you use split without parens, and here you use split with parens.
Decide if you like parens or not, then consistently always use them or
don't use them.
If you don't want the 1st element, then don't save the first element:
my(undef, @session_parts) = split /:/, $columns[1];
> my $tempcount = @temp1;
> for (my $a = 0 ; $a <= $tempcount-1; $a++) {
Yet another poorly chosen variable name.
$a is used for sort()ing, so you should not use it for other purposes.
Take the time to come up with _meaningful_ names, it will help
you understand and debug your code more easily.
You should let perl do the indexing for you:
foreach my $i ( 0..@session_parts ) {
> push ( @temp2, $temp1[$a] );
> }
Even better, don't do any indexing at all!
foreach my $part (@session_parts) {
push @temp2, $part;
}
Best is to not even use unnecessary loops:
@temp2 = @session_parts;
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Mon, 28 Mar 2011 17:06:26 -0700
From: "John W. Krahn" <jwkrahn@example.com>
Subject: Re: REVISED: Variable length array to XML
Message-Id: <7o9kp.1157$BF3.724@newsfe22.iad>
Christian Winter wrote:
>
> All in all, your loop can be reduced to:
>
> while (my $line =<CSVFILE>) {
> $line =~ tr/"\r\n//d;
> my @c = split /,/, $line;
> my @temp1 = split /\\/, $c[1];
> shift (@temp1);
> push ( @temp1, $c[0], $c[3] );
> unshift ( @temp1, scalar @temp1 );
> push @final, [ @temp1 ];
> }
And reduce it further:
while ( my $line = <CSVFILE> ) {
$line =~ tr/"\r\n//d;
my @c = split /,/, $line;
my ( undef, @temp1 ) = split /\\/, $c[ 1 ];
push @final, [ 2 + @temp1, @temp1, @c[ 0, 3 ] ];
}
John
--
Any intelligent fool can make things bigger and
more complex... It takes a touch of genius -
and a lot of courage to move in the opposite
direction. -- Albert Einstein
------------------------------
Date: Mon, 28 Mar 2011 15:52:43 -0700 (PDT)
From: Rob <rdw204@gmail.com>
Subject: Search script to index dynamic pages
Message-Id: <02fa1ae1-cb93-4b27-816c-af2c91a01610@q12g2000prb.googlegroups.com>
I recently tried to add a downloaded CGI script to my site, before
realising that it would naturally only index static pages on the site
(i.e. only files that it could open using Perl routines). I have
altered the indexing routine so that it does not crawl all directories
and index all files. Instead it opens a file containing a specified
list of files, and indexes only those instead.
As the majority of the content on the website is dynamic content, does
anybody know of any search CGI scripts that will index pages with
dynamic CGI content? (e.g. "website.com/cgi-bin/viewpage.cgi?id=100" )
If such a script is not available, is there a way to return content
from a dynamic page to a CGI script (for indexing purposes)? I could
alter the indexing routine so that it does not just open the files it
is told to, but to return the content (that the script would output to
the server) to the indexing routine instead. This would then suit the
needs of the website perfectly.
Apologies if this has already been covered elsewhere, I have had no
success in finding a solution online. Any help with this would be much
appreciated.
Best Regards
Rob
------------------------------
Date: Mon, 28 Mar 2011 16:00:35 -0700
From: Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us>
Subject: Re: Search script to index dynamic pages
Message-Id: <jhg768xbur.ln2@goaway.wombat.san-francisco.ca.us>
On 2011-03-28, Rob <rdw204@gmail.com> wrote:
>
> As the majority of the content on the website is dynamic content, does
> anybody know of any search CGI scripts that will index pages with
> dynamic CGI content? (e.g. "website.com/cgi-bin/viewpage.cgi?id=100" )
Not directly, but you might consider using something like KinoSearch,
which can create an index of anything you feed to it. You'd need to
code up the indexer yourself, but it's fairly straightforward, assuming
you have access to the backend content you're trying to index.
--keith
--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
------------------------------
Date: Mon, 28 Mar 2011 20:22:53 -0400
From: Sherm Pendley <sherm.pendley@gmail.com>
Subject: Re: Search script to index dynamic pages
Message-Id: <m2zkoezsf6.fsf@sherm.shermpendley.com>
Rob <rdw204@gmail.com> writes:
> I recently tried to add a downloaded CGI script to my site, before
> realising that it would naturally only index static pages on the site
> (i.e. only files that it could open using Perl routines). I have
> altered the indexing routine so that it does not crawl all directories
> and index all files. Instead it opens a file containing a specified
> list of files, and indexes only those instead.
>
> As the majority of the content on the website is dynamic content, does
> anybody know of any search CGI scripts that will index pages
Surely it's not the CGI script that's doing the indexing? Normally,
there would be a separate script that's scheduled to run periodically
via cron (or similar) that creates the index. The CGI simply reads the
index and returns the requested pages.
> with
> dynamic CGI content? (e.g. "website.com/cgi-bin/viewpage.cgi?id=100" )
You could adapt the index-building script to use WWW::Mechanize to fetch
and index a collection of URLs instead of file names:
<http://search.cpan.org/perldoc?WWW::Mechanize>
Once the contents of each URL are fetched, indexing it should be the
same as doing so with the contents of a file, so that part of the indexing
script shouldn't need many changes. The CGI to read the index & find the
requested search term might not need to be changed at all.
Of course, all this assumes that you're reasonably comfortable with Perl,
or at least willing to learn it. There is no step-by-step procedure for
making this kind of conversion.
sherm--
--
Sherm Pendley
<http://camelbones.sourceforge.net>
Cocoa Developer
------------------------------
Date: Mon, 28 Mar 2011 21:08:55 -0700 (PDT)
From: "dn.perl@gmail.com" <dn.perl@gmail.com>
Subject: two attempts at DBI connect call
Message-Id: <b09981aa-5322-4154-8108-aa9e72b7cf47@22g2000prx.googlegroups.com>
I have two tns-connection-strings with me. Only one of them is active
at any given time.
Same schema, usernames, passwords apply to both.
I would like to try to connect via string-1, and if it fails connect
via string-2. But the program just aborts when a dbi->connect call
fails. No second chance allowed.
Sample code:
my $dbh ;
$dbh = DBI->connect("dbi:Oracle:tns-string1 etc etc etc");
if (!$dbh ) {
$dbh = DBI->connect("dbi:Oracle:tns-string2 etc etc etc");
}
## die if both attempts fail
die $dbh->errstr if !$dbh ; ## I can live without this statement
return $dbh ;
I suspect there must be some internal variable set by default to make
a program exit if DBI->connect fails.
How can I make the above code work?
TIA.
------------------------------
Date: Tue, 29 Mar 2011 01:09:02 -0600
From: Uno <Uno@example.invalid>
Subject: Re: using File::Find
Message-Id: <8vdeseFmj9U1@mid.individual.net>
On 03/28/2011 02:51 AM, Peter J. Holzer wrote:
> On 2011-03-27 23:44, Mladen Gogala<mgogala@no.address.invalid> wrote:
>> On Sat, 26 Mar 2011 23:17:52 -0400, Uri Guttman wrote:
>>> and why do you like bareword file handles?
>>
>> Because I use Perl since 1993, when it was still version 4, and I have a
>> bunch of old scripts for which perlcritic now tells me that they're badly
>> written. Compatibility is the reason.
>
> Compatibility with Perl4? Who's still running Perl4 (Or Perl 5.005 -
> lexical file handles were only introduced in 5.6)? And you are only
> compatible if you don't use *any* newer feature - just avoiding one
> particular feature doesn't make your scripts compatible.
>
>> I use lexicals in my newer scripts but every now and then someone runs
>> one of my old scripts through perlcritic and starts nagging.
>
> There is a simple answer to those people:
>
> "I like the idea. Send patches!"
>
> They want something changed. They have the source. They can change it
> themselves.
>
>> Simply, bareword file handles used to be The Perl Way(TM) and I don't
>> think it's right to now flag them as bad programming.
>
> There are now better ways and bareword file handles really are bad
> programming. They were bad programming in 1993, there just wasn't an
> alternative (except using a different programming language).
As near as I can tell, this issue, which is, demonstrably, not even
close to the subject that this OP wrote, is remedied by using "my."
For us new people, we wouldn't even think about doing it otherwise,
since it draws an exception when you use strict.
--
Uno
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 V11 Issue 3337
***************************************
