[30155] in Perl-Users-Digest
Perl-Users Digest, Issue: 1398 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Mar 27 14:09:44 2008
Date: Thu, 27 Mar 2008 11:09:08 -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 Thu, 27 Mar 2008 Volume: 11 Number: 1398
Today's topics:
Re: bare underscore? <miknrene@drizzle.com>
Re: BEGIN, INIT etc... dummy@phony.info
Re: BEGIN, INIT etc... <pgodfrin@gmail.com>
Re: BEGIN, INIT etc... <uri@stemsystems.com>
Re: BEGIN, INIT etc... <joost@zeekat.nl>
Re: BEGIN, INIT etc... <pgodfrin@gmail.com>
Re: BEGIN, INIT etc... <pgodfrin@gmail.com>
Re: need help on cgi to get multi pages and could sort xhoster@gmail.com
Re: Operator ->() xhoster@gmail.com
perl on pc 104 <test@example.com>
Re: perl on pc 104 <john@castleamber.com>
Re: perl on pc 104 <ben@morrow.me.uk>
ssh ssh <jameslockie@mail.com>
Re: ssh ssh <ben@morrow.me.uk>
Re: The huge amount response data problem <jimsgibson@gmail.com>
Re: using cgi.pm <smallpond@juno.com>
Re: using cgi.pm xhoster@gmail.com
Re: using cgi.pm xhoster@gmail.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 27 Mar 2008 09:42:50 -0700
From: Michael Slass <miknrene@drizzle.com>
Subject: Re: bare underscore?
Message-Id: <m37ifounhx.fsf@drizzle.com>
Sherman Pendley <spamtrap@dot-app.org> writes:
>Michael Slass <miknrene@drizzle.com> writes:
>
>> What does the _ with no sigil before it mean in
>> if (-e $path && ! -d _) {
>>
>> ?
>
>When used with a file test operator, the unadorned _ re-uses the information
>returned from the preceding test or stat() call. This can avoid race condi-
>tions that might cause stat() to return different results from one test to
>the next. It can also be a big win where stat() is relatively expensive,
>such as network shares.
>
Thanks to both of you; I was looking in the perlvar manpage for a
magic variable; I hadn't guessed it was magic in the -d operator.
Thanks again,
--
Mike Slass
------------------------------
Date: Thu, 27 Mar 2008 09:31:22 -0700
From: dummy@phony.info
Subject: Re: BEGIN, INIT etc...
Message-Id: <qginu3tg2foe2tnjb7ffaej0427e354s1c@4ax.com>
On Thu, 27 Mar 2008 03:26:31 GMT, Uri Guttman <uri@stemsystems.com>
wrote:
>>>>>> "p" == pgodfrin <pgodfrin@gmail.com> writes:
>
> p> On Mar 26, 5:37 pm, xhos...@gmail.com wrote:
> >> pgodfrin <pgodf...@gmail.com> wrote:
> >> > On Mar 26, 3:49 pm, Gunnar Hjalmarsson <nore...@gunnar.cc> wrote:
> >> > > pgodfrin wrote:
> >> > > > Anyone know of a good article that discusses when and why you would
> >> > > > use the BEGIN, UNITCHECK, CHECK, INIT and END code blocks?
> >>
> p> Sorry - didn't mean to impugn the quality of the docs. All I was
> p> looking for is some sort of article from a trade rag, for instance,
> p> that discussed the utility of those code blocks. You know, maybe some
> p> sort of article where a really good Perl programmer describes how he
> p> (or she :) ) uses those code blocks in an effective manner.
>
>simple answer is to ignore INIT, CHECK and the new UNITCHECK. they are
>only for specialized modules and newbies should never need to go near
>them. they fall into the rule (which covers symrefs and string eval)
>that you shouldn't use them until you know when you don't need them.
>
>BEGIN and END are much more useful and you seem to know about them.
>
>they are commonly used when you need to do something as soon as that
>block of code is parsed (BEGIN) or when the program is exiting
>(END). and the above rule applies as you don't know when you need or not
>need them so don't bother to learn them yet. once you get into perl
>deeper you will know more about initialization, compile vs runtime and
>destruction. but now you don't know those so ignore BEGIN/END until you
>need to learn them.
>
>uri
You don't need to know it until you know it? How does that work?
Something like not learning how to drive on ice until after a fatal
skid?
I also would like to learn this topic in advance of need.
------------------------------
Date: Thu, 27 Mar 2008 09:50:27 -0700 (PDT)
From: pgodfrin <pgodfrin@gmail.com>
Subject: Re: BEGIN, INIT etc...
Message-Id: <a72b33d0-1b6a-4cde-94f9-0cf2cec29d23@d4g2000prg.googlegroups.com>
On Mar 27, 11:31 am, du...@phony.info wrote:
> On Thu, 27 Mar 2008 03:26:31 GMT, Uri Guttman <u...@stemsystems.com>
> wrote:
>
>
>
> >>>>>> "p" == pgodfrin <pgodf...@gmail.com> writes:
>
> > p> On Mar 26, 5:37 pm, xhos...@gmail.com wrote:
> > >> pgodfrin <pgodf...@gmail.com> wrote:
> > >> > On Mar 26, 3:49 pm, Gunnar Hjalmarsson <nore...@gunnar.cc> wrote:
> > >> > > pgodfrin wrote:
> > >> > > > Anyone know of a good article that discusses when and why you would
> > >> > > > use the BEGIN, UNITCHECK, CHECK, INIT and END code blocks?
>
> > p> Sorry - didn't mean to impugn the quality of the docs. All I was
> > p> looking for is some sort of article from a trade rag, for instance,
> > p> that discussed the utility of those code blocks. You know, maybe some
> > p> sort of article where a really good Perl programmer describes how he
> > p> (or she :) ) uses those code blocks in an effective manner.
>
> >simple answer is to ignore INIT, CHECK and the new UNITCHECK. they are
> >only for specialized modules and newbies should never need to go near
> >them. they fall into the rule (which covers symrefs and string eval)
> >that you shouldn't use them until you know when you don't need them.
>
> >BEGIN and END are much more useful and you seem to know about them.
>
> >they are commonly used when you need to do something as soon as that
> >block of code is parsed (BEGIN) or when the program is exiting
> >(END). and the above rule applies as you don't know when you need or not
> >need them so don't bother to learn them yet. once you get into perl
> >deeper you will know more about initialization, compile vs runtime and
> >destruction. but now you don't know those so ignore BEGIN/END until you
> >need to learn them.
>
> >uri
>
> You don't need to know it until you know it? How does that work?
> Something like not learning how to drive on ice until after a fatal
> skid?
>
> I also would like to learn this topic in advance of need.
OK - I can stay away from INIT, CHECK and UNITCHECK. But your point
about learning about initialization, compile vs runtime and
destruction is pretty much what I'm trying to do - learn about it. So
I will re-iterate my question - is there any information out there -
an article, a book, perl's documentation - that discusses:
How exactly would you use BEGIN and END code blocks for
initialization, compile time, runtime and destruction issues?
I've been using END as a centralized exit point, so that when my code
executes die() or exit() I can still cleanup and do other things. Is
there more to know about that?
I also came across a glitch when using CGI and DBI modules, where some
variables lose scope when the BEGIN code block is completed (which is
clearly alluded to in perlmod). But in plain old Perl I can still
refer to variables assigned in BEGIN in later parts of the code. So
there is a corollary between these code blocks and scope. It would
seem to me that a good discussion about scope (perldoc ???) is in
order too...
thanks,
pg
------------------------------
Date: Thu, 27 Mar 2008 17:00:11 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: BEGIN, INIT etc...
Message-Id: <x77ifo3xwk.fsf@mail.sysarch.com>
>>>>> "d" == dummy <dummy@phony.info> writes:
d> On Thu, 27 Mar 2008 03:26:31 GMT, Uri Guttman <uri@stemsystems.com>
d> wrote:
>> they are commonly used when you need to do something as soon as that
>> block of code is parsed (BEGIN) or when the program is exiting
>> (END). and the above rule applies as you don't know when you need or not
>> need them so don't bother to learn them yet. once you get into perl
>> deeper you will know more about initialization, compile vs runtime and
>> destruction. but now you don't know those so ignore BEGIN/END until you
>> need to learn them.
>>
>> uri
d> You don't need to know it until you know it? How does that work?
d> Something like not learning how to drive on ice until after a fatal
d> skid?
no, you learn to drive on ice only after you have mastered general
driving and have a need or desire to learn more. most newbies have no
need for BEGIN/END and so don't need to know about them. as they learn
more perl and get to know modules, scoping and compile vs runtime then
those concepts will help them learn how and when to use BEGIN/END. my
point is that they are not needed by newbies and shouldn't be taught as
they will just confuse them.
d> I also would like to learn this topic in advance of need.
do you write modules? do you have subtle initialization or destruction
needs? if not, you don't need to learn them yet. read perlmod more times
and if you don't grasp the concepts then get a good perl book. i can
explain them but it would require a decent sized post or small
article. it makes a good topic and i may do it one day. i already have
seen a need for a definitive article on lists vs arrays and i have been
writing it in my head. but too many things are higher priority for me
now to do that.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Thu, 27 Mar 2008 18:09:23 +0100
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: BEGIN, INIT etc...
Message-Id: <87fxuc856k.fsf@zeekat.nl>
pgodfrin <pgodfrin@gmail.com> writes:
> OK - I can stay away from INIT, CHECK and UNITCHECK. But your point
> about learning about initialization, compile vs runtime and
> destruction is pretty much what I'm trying to do - learn about it. So
> I will re-iterate my question - is there any information out there -
> an article, a book, perl's documentation - that discusses:
>
> How exactly would you use BEGIN and END code blocks for
> initialization, compile time, runtime and destruction issues?
BEGIN is there to run code before the later code gets compiled. This is
useful in a few cases, mainly to manually define subroutines & packages
up-front so that the perl compiler knows about them (indirect object
notation relies on this, IIRC). It may also be useful to force some
initialization before use()ing a module that relies on it.
END blocks are useful to "guarantee" that code gets run when the program
ends, even if for example an exception is thrown. Useful for system
resources that may not get freed properly otherwise.
Those two are what you normally need. The others are more esotheric.
INIT, CHECK and UNITCHECK blocks are there to be able to manipulate the
compiled op tree before it gets run and they're IIRC mainly used by the
B backend modules. See for instance, perlguts, B and O.
> I've been using END as a centralized exit point, so that when my code
> executes die() or exit() I can still cleanup and do other things. Is
> there more to know about that?
Not really.
> I also came across a glitch when using CGI and DBI modules, where some
> variables lose scope when the BEGIN code block is completed (which is
> clearly alluded to in perlmod). But in plain old Perl I can still
> refer to variables assigned in BEGIN in later parts of the code. So
> there is a corollary between these code blocks and scope. It would
> seem to me that a good discussion about scope (perldoc ???) is in
> order too...
I think you're mistaken, that always happens:
$ perl -Mstrict -w -e'BEGIN { my $f = 1;} print $f'
Global symbol "$f" requires explicit package name at -e line 1.
HTH,
Joost.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: Thu, 27 Mar 2008 11:04:10 -0700 (PDT)
From: pgodfrin <pgodfrin@gmail.com>
Subject: Re: BEGIN, INIT etc...
Message-Id: <6e68c6a3-fe57-425e-b627-93eca3c5a6f9@s8g2000prg.googlegroups.com>
On Mar 27, 12:00 pm, Uri Guttman <u...@stemsystems.com> wrote:
> >>>>> "d" == dummy <du...@phony.info> writes:
>
> d> On Thu, 27 Mar 2008 03:26:31 GMT, Uri Guttman <u...@stemsystems.com>
>
> d> wrote:
>
> >> they are commonly used when you need to do something as soon as that
> >> block of code is parsed (BEGIN) or when the program is exiting
> >> (END). and the above rule applies as you don't know when you need or not
> >> need them so don't bother to learn them yet. once you get into perl
> >> deeper you will know more about initialization, compile vs runtime and
> >> destruction. but now you don't know those so ignore BEGIN/END until you
> >> need to learn them.
> >>
> >> uri
>
> d> You don't need to know it until you know it? How does that work?
> d> Something like not learning how to drive on ice until after a fatal
> d> skid?
>
> no, you learn to drive on ice only after you have mastered general
> driving and have a need or desire to learn more. most newbies have no
> need for BEGIN/END and so don't need to know about them. as they learn
> more perl and get to know modules, scoping and compile vs runtime then
> those concepts will help them learn how and when to use BEGIN/END. my
> point is that they are not needed by newbies and shouldn't be taught as
> they will just confuse them.
>
> d> I also would like to learn this topic in advance of need.
>
> do you write modules? do you have subtle initialization or destruction
> needs? if not, you don't need to learn them yet. read perlmod more times
> and if you don't grasp the concepts then get a good perl book. i can
> explain them but it would require a decent sized post or small
> article. it makes a good topic and i may do it one day. i already have
> seen a need for a definitive article on lists vs arrays and i have been
> writing it in my head. but too many things are higher priority for me
> now to do that.
>
> uri
>
> --
> Uri Guttman ------ u...@stemsystems.com -------- http://www.sysarch.com--
> ----- Perl Code Review , Architecture, Development, Training, Support ------
> --------- Free Perl Training ---http://perlhunter.com/college.html---------
> --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com---------
cool - please let us know when you've written these articles. Where do
those articles get published, btw?
pg
------------------------------
Date: Thu, 27 Mar 2008 11:05:34 -0700 (PDT)
From: pgodfrin <pgodfrin@gmail.com>
Subject: Re: BEGIN, INIT etc...
Message-Id: <af2ad8dc-832f-44fc-95e4-e58d72bc3a21@i7g2000prf.googlegroups.com>
On Mar 27, 12:09 pm, Joost Diepenmaat <jo...@zeekat.nl> wrote:
> pgodfrin <pgodf...@gmail.com> writes:
> > OK - I can stay away from INIT, CHECK and UNITCHECK. But your point
> > about learning about initialization, compile vs runtime and
> > destruction is pretty much what I'm trying to do - learn about it. So
> > I will re-iterate my question - is there any information out there -
> > an article, a book, perl's documentation - that discusses:
>
> > How exactly would you use BEGIN and END code blocks for
> > initialization, compile time, runtime and destruction issues?
>
> BEGIN is there to run code before the later code gets compiled. This is
> useful in a few cases, mainly to manually define subroutines & packages
> up-front so that the perl compiler knows about them (indirect object
> notation relies on this, IIRC). It may also be useful to force some
> initialization before use()ing a module that relies on it.
>
> END blocks are useful to "guarantee" that code gets run when the program
> ends, even if for example an exception is thrown. Useful for system
> resources that may not get freed properly otherwise.
>
> Those two are what you normally need. The others are more esotheric.
>
> INIT, CHECK and UNITCHECK blocks are there to be able to manipulate the
> compiled op tree before it gets run and they're IIRC mainly used by the
> B backend modules. See for instance, perlguts, B and O.
>
> > I've been using END as a centralized exit point, so that when my code
> > executes die() or exit() I can still cleanup and do other things. Is
> > there more to know about that?
>
> Not really.
>
> > I also came across a glitch when using CGI and DBI modules, where some
> > variables lose scope when the BEGIN code block is completed (which is
> > clearly alluded to in perlmod). But in plain old Perl I can still
> > refer to variables assigned in BEGIN in later parts of the code. So
> > there is a corollary between these code blocks and scope. It would
> > seem to me that a good discussion about scope (perldoc ???) is in
> > order too...
>
> I think you're mistaken, that always happens:
>
> $ perl -Mstrict -w -e'BEGIN { my $f = 1;} print $f'
> Global symbol "$f" requires explicit package name at -e line 1.
>
> HTH,
> Joost.
>
> --
> Joost Diepenmaat | blog:http://joost.zeekat.nl/| work:http://zeekat.nl/
Thanks Joost, I will look at the perlguts doc and cleanup my
concepts...
regards,
pg
------------------------------
Date: 27 Mar 2008 15:55:54 GMT
From: xhoster@gmail.com
Subject: Re: need help on cgi to get multi pages and could sort by column from Oracle
Message-Id: <20080327115555.858$es@newsreader.com>
"robertchen117@gmail.com" <robertchen117@gmail.com> wrote:
> hi, please help me on:
>
> I want to find like 1000+ records from Oracle database using dbi, but
> the view could sort by column and could display by multi pages.
>
> Anyone has this kind of experience?
Yes. There are a lot of ways to do it, with a lot of accompanying trade
offs.
Are you an Oracle developer that uses Perl, or Perl programmer that uses
Oracle? What is more heavily loaded, the CGI server or the Oracle server?
How efficient is the underlying query that returns the 1000+ records?
Are you using CGI sessions or doing sessionless CGI?
Why multiple pages at all? My browser has a scroll bar--let me use it.
How dynamic is the underlying data? What if a database entry that is
currently being displayed on "page one" gets deleted (and committed) from
the database? Now, when the person changes to "page two", everything has
slid up a row, and what would have been the first thing on page two is
missed altogether, because it now would show up on page one but the user
doesn't know that, because they went to the next page rather than
refreshing the current page.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: 27 Mar 2008 16:01:46 GMT
From: xhoster@gmail.com
Subject: Re: Operator ->()
Message-Id: <20080327120147.630$nu@newsreader.com>
Subra <mailursubbu@gmail.com> wrote:
> Can some one pls tell me wts the meaning of "$topIter->next()" ?
It invokes method "next" on the object contained in $topIter.
> I know "->" is used for hash refs, but dont know when to use ->( ) !!!
Your example is not ->(), it is ->next(), or more generically, ->$method().
They are quite different. The first is used on code-refs, the second on
objects.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Thu, 27 Mar 2008 17:11:29 GMT
From: Ron Eggler <test@example.com>
Subject: perl on pc 104
Message-Id: <5zQGj.746$9X3.730@edtnps82>
Hi,
I need to get perl5 on our little pc104 (with goede) system in order to get
ssh-keygen( openSSH) - which depends on openSSL which depends on perl5 -
running.
When I'm trying to compile (configure) it, I get this messages:
[shell]
I used the command:
cc -o
try -O2 -fno-strict-aliasing -pipe -I/usr/local/include -L/usr/local/lib
try.c -lnsl -ldb -ldl -lm -lcrypt -lutil -lc
./try
and I got the following output:
/usr/lib/gcc/i586-linux-uclibc/3.4.4/../../../libdb.so: undefined reference
to `pthread_condattr_setpshared'
/usr/lib/gcc/i586-linux-uclibc/3.4.4/../../../libdb.so: undefined reference
to `pthread_mutexattr_destroy'
/usr/lib/gcc/i586-linux-uclibc/3.4.4/../../../libdb.so: undefined reference
to `pthread_mutexattr_setpshared'
/usr/lib/gcc/i586-linux-uclibc/3.4.4/../../../libdb.so: undefined reference
to `pthread_mutexattr_init'
/usr/lib/gcc/i586-linux-uclibc/3.4.4/../../../libdb.so: undefined reference
to `pthread_mutex_trylock'
collect2: ld returned 1 exit status
I can't compile the test program.
(The supplied flags or libraries might be incorrect.)
You have a BIG problem. Shall I abort Configure [y] y
Ok. Stopping Configure.
[root@NEMS perl-5.10.0]# find / -name "libdb.so"
/usr/lib/libdb.so
[/shell]
Any ideawhat I would be doing wrongly and what that exactly is, as you can
see, i made a find on the bottom and i do have the libdb.so available
in /usr/lib.
Thanks for any help!
--
chEErs roN
------------------------------
Date: 27 Mar 2008 17:19:53 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: perl on pc 104
Message-Id: <Xns9A6E7346865DEcastleamber@130.133.1.4>
Ron Eggler <test@example.com> wrote:
[..]
> /usr/lib/gcc/i586-linux-uclibc/3.4.4/../../../libdb.so: undefined
> reference to `pthread_mutexattr_setpshared'
> /usr/lib/gcc/i586-linux-uclibc/3.4.4/../../../libdb.so: undefined
> reference to `pthread_mutexattr_init'
> /usr/lib/gcc/i586-linux-uclibc/3.4.4/../../../libdb.so: undefined
[..]
> Any ideawhat I would be doing wrongly and what that exactly is, as you
> can see, i made a find on the bottom and i do have the libdb.so
> available in /usr/lib.
But do you have pthread.so (I assume it's called like that).
(Unless I am not entirely awake and read the messages wrong...)
--
John
http://johnbokma.com/perl/
------------------------------
Date: Thu, 27 Mar 2008 17:38:30 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: perl on pc 104
Message-Id: <ml2tb5-c36.ln1@osiris.mauzo.dyndns.org>
Quoth Ron Eggler <test@example.com>:
>
> I need to get perl5 on our little pc104 (with goede) system in order to get
> ssh-keygen( openSSH) - which depends on openSSL which depends on perl5 -
> running.
> When I'm trying to compile (configure) it, I get this messages:
> [shell]
> I used the command:
>
> cc -o
> try -O2 -fno-strict-aliasing -pipe -I/usr/local/include -L/usr/local/lib
> try.c -lnsl -ldb -ldl -lm -lcrypt -lutil -lc
> ./try
>
> and I got the following output:
>
> /usr/lib/gcc/i586-linux-uclibc/3.4.4/../../../libdb.so: undefined reference
> to `pthread_condattr_setpshared'
<snip>
>
> Any ideawhat I would be doing wrongly and what that exactly is, as you can
> see, i made a find on the bottom and i do have the libdb.so available
> in /usr/lib.
The problem is not libdb.so, it's that libdb.so requires the pthread
functions, which aren't getting loaded. Do you have a version of
libdb.so which doesn't require threads, and can you persuade Configure
to use it?
Alternatively, can you Configure perl with -Duseithreads? I wouldn't
normally recommend this on a Unix machine (perl threads are practically
useless when you have fork(2)), but it may be an easy way to pull the
thread libraries in.
Otherwise, you may have more luck asking perl5-porters@perl.org: they
are the people who maintain perl, and they will certainly be interested
in situations where perl won't configure.
Ben
------------------------------
Date: Thu, 27 Mar 2008 09:39:54 -0700 (PDT)
From: jammer <jameslockie@mail.com>
Subject: ssh ssh
Message-Id: <52f55c8c-c6f3-4639-abd3-02aca9c5a4d6@d4g2000prg.googlegroups.com>
I am trying to write a script that takes a list of hosts and sshs into
the first one and then can ssh to other ones. I can only ssh to the
other hosts from the first host.
Here is what I tried:
I think it is waiting for the ssh to the first host to finish.
I guess I could scp a partial hostlist and a program to *.domain and
then run the program remotely.
Am I on a right track?
#!/bin/perl
use strict;
open( HL, '<hostlist3.txt' ) || die "can't open hostlist3";
#!/bin/perl
use strict;
open( HL, '<hostlist3.txt' ) || die "can't open hostlist3";
my $newCC;
my $line;
while ($line = <HL>) {
chop $line;
if ($line eq '') {
$newCC = 1;
}
if ($newCC == 1) {
if ($line ne '') {
$newCC = 0;
print "ssh $line\n";
# print `ssh $line`;
}
} else {
print "ssh $line uname -a\n";
# print`ssh $line uname -a`;
}
}
close( HL );
For example, if hostlist3.txt contains:
host1.domain
host2
host3.domain
host4
I need to ssh into host1.domain to ssh to host2
Then I need to ssh to host3.domain ro ssh to host4
The goal is to run 'uname' on a bunch of machines that are only
accessible from the *.domain machine.
The machine running the program can access all the *.domain machines
but not the others.
------------------------------
Date: Thu, 27 Mar 2008 17:02:18 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: ssh ssh
Message-Id: <qh0tb5-d32.ln1@osiris.mauzo.dyndns.org>
Quoth jammer <jameslockie@mail.com>:
> I am trying to write a script that takes a list of hosts and sshs into
> the first one and then can ssh to other ones. I can only ssh to the
> other hosts from the first host.
>
> Here is what I tried:
> I think it is waiting for the ssh to the first host to finish.
>
> I guess I could scp a partial hostlist and a program to *.domain and
> then run the program remotely.
> Am I on a right track?
No. Step back a minute and consider how you would do this without Perl:
what you want to end up running is
ssh host1.domain ssh host2 uname -a
assuming ssh is in your default PATH on host1.domain. What you actually
end up running, here (or would if it weren't commented),
> # print `ssh $line`;
is
ssh host1.domain
with no command specified. This will give you a shell; while it would be
possible to remote-control that shell, it's much easier to use ssh's
ability to run a command directly. You want something like
open my $HOSTLIST, '<', 'hostlist3.txt'
or die "can't open hostlist3.txt: $!";
$/ = ''; # this will read a paragraph at a time
$\ = "\n"; # avoids needing to print it all the time
while (<$HOSTLIST>) {
my $cmd = join ' ', map "ssh $_", split /\n/;
$cmd .= ' uname -a';
print "executing '$cmd'";
print `$cmd`;
}
which will cope with any number of intervening hosts automatically. Note
that this assumes none of the items in hostlist3.txt have spaces in:
annoyingly, there isn't a form of backticks corresponding to system
LIST, so that would be rather harder to deal with.
Ben
------------------------------
Date: Thu, 27 Mar 2008 11:07:14 -0700
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: The huge amount response data problem
Message-Id: <270320081107147176%jimsgibson@gmail.com>
In article
<c776f49d-4eb1-4765-a617-c2e4b1e125c8@s19g2000prg.googlegroups.com>,
<"falconzyx@gmail.com"> wrote:
> Here is my refactor code, which still at a very slow speed, please
> advice me how to improve it, thanks very much:
>
> require LWP::Parallel::UserAgent;
> use HTTP::Request;
> use LWP::Simple;
> use threads;
>
> # display tons of debugging messages. See 'perldoc LWP::Debug'
> #use LWP::Debug qw(+);
> my $reqs = [
> HTTP::Request->new('GET',"http://www...."),
> HTTP::Request->new('GET', "......"
> ..............# about nearly 200000 url here
>
> ];
[ rest snipped ]
You are flooding the web with 200_000 URL requests (but only 7-35 at a
time according to the LWP::Parallel documentation). Of course that is
going to be very slow. How slow is it? You should start with a small
number and see how long it takes, then add more URLs and see if it
scales OK.
The bottleneck is going to be waiting for a response from each of your
URLs. There is no way any amount of Perl programming efficiency can
make up for that slowness.
You should consider caching your results. How often do you have to run
this program to get all 200_000 URLs? How often do they change content?
Does your list vary every time you run the program?
--
Jim Gibson
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
------------------------------
Date: Thu, 27 Mar 2008 08:55:05 -0700 (PDT)
From: smallpond <smallpond@juno.com>
Subject: Re: using cgi.pm
Message-Id: <10a08276-56d9-43a2-bc48-9e4ab6382d8c@d62g2000hsf.googlegroups.com>
On Mar 27, 10:31 am, "Ela" <e...@yantai.org> wrote:
> "Joost Diepenmaat" <jo...@zeekat.nl> wrote in message
>
> news:877ifotgms.fsf@zeekat.nl...
>
> > In general, you just don't do that. If you want to put processing code
> > in separate files, just use those files from the same CGI program. IOW,
> > use modules. That's more efficient and less error prone than trying
> > to invoke stand-alone scripts from each other (not to mention that doing
> > that will probably not work out of the box for CGI scripts that read
> > POST data).
>
> > HTH,
> > Joost.
>
> But in the sense of putting the search and fetch functions in the same cgi,
> how come results can be generated after accepting users' input parameters? A
> simple example based on my simplified codes will be appreciated~
>
> #!/usr/bin/perl
>
> use CGI qw(:standard);
>
> $query = new CGI;
>
> print $query->header;
>
> print $query->startform;
> print "Title: ",$query->textfield(-name=>'title', -justification=>'RIGHT');
>
> print $query->submit(-name=>'button_name', -value=>'Get !');
> print $query->endform;
> print $query->end_html;
>
> #the following print can be executed successfully but the resultant page is
> just wield....
> print $query->param('title');
> print "<BR>";
The process that prints out a web page form is not the same process
that gets the result of filling it out and pressing the submit
button. They don't have to have any connection and don't have to
be on the same web server. I can create a search form on my website
and submit it to google, for example.
It is sometimes convenient to do them both from one cgi and sort
out which call is being made from the params, but if you are just
getting started try making the form with a static web page and
handling only the submit in the cgi. Work up from there.
--S
------------------------------
Date: 27 Mar 2008 16:11:25 GMT
From: xhoster@gmail.com
Subject: Re: using cgi.pm
Message-Id: <20080327121126.929$Zv@newsreader.com>
"Ela" <ela@yantai.org> wrote:
> After studying:
>
> http://search.cpan.org/src/LDS/CGI.pm-3.34/cgi_docs.html#checkbox_group
>
> I still don't understand how to tell one cgi to call another cgi to
> handle the information of a submited form, after a user has submited his
> form with some choices selected. Could anybody shed some light?
If you want one CGI to create the form and a second CGI to process the
submitted data based on that form, then the first CGI doesn't call the
second one. It tells the client browser to call the second one. You
arrange for this in the start_form function/method.
In first.cgi:
print $q->start_form(-action = 'second.cgi');
If you don't specify an action, then the action defaults to using same
script which is generating the form in the first place.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: 27 Mar 2008 16:16:44 GMT
From: xhoster@gmail.com
Subject: Re: using cgi.pm
Message-Id: <20080327121646.045$4O@newsreader.com>
"Ela" <ela@yantai.org> wrote:
>
> #!/usr/bin/perl
>
> use CGI qw(:standard);
>
> $query = new CGI;
>
> print $query->header;
>
> print $query->startform;
> print "Title: ",$query->textfield(-name=>'title',
> -justification=>'RIGHT');
>
> print $query->submit(-name=>'button_name', -value=>'Get !');
> print $query->endform;
> print $query->end_html;
You shouldn't lie like that. You told it that this is the end of the html,
but then you go on to send more html. Most browsers will handle this
deception gracefully, but it is still bad practice.
>
> #the following print can be executed successfully but the resultant page
> # is just wield....
> print $query->param('title');
> print "<BR>";
What is weird about it? It does exactly what I thought it would do, the
misplaced end_html not withstanding. First it shows the form,
unconditionally, then it shows the results from the just-submitted form,
if any. That is what you told it to do. What did you want it to do?
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
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.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
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 V11 Issue 1398
***************************************
