[28989] in Perl-Users-Digest
Perl-Users Digest, Issue: 233 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Mar 16 21:10:37 2007
Date: Fri, 16 Mar 2007 18:09:21 -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 Fri, 16 Mar 2007 Volume: 11 Number: 233
Today's topics:
How to decompose nested objects <rfdunn@hotmail.com>
Re: new CGI::Session creates a new session every visit. <paduille.4060.mumia.w+nospam@earthlink.net>
Re: new CGI::Session creates a new session every visit. <kingskippus@gmail.com>
Re: new CGI::Session creates a new session every visit. <kingskippus@gmail.com>
Re: new CGI::Session creates a new session every visit. <paduille.4060.mumia.w+nospam@earthlink.net>
Re: new CGI::Session creates a new session every visit. <paduille.4060.mumia.w+nospam@earthlink.net>
Re: new CGI::Session creates a new session every visit. <paduille.4060.mumia.w+nospam@earthlink.net>
Re: new CGI::Session creates a new session every visit. <paduille.4060.mumia.w+nospam@earthlink.net>
Re: new CGI::Session creates a new session every visit. <kingskippus@gmail.com>
Re: new CGI::Session creates a new session every visit. xhoster@gmail.com
Re: new CGI::Session creates a new session every visit. xhoster@gmail.com
Re: output confusion <"v.niekerk at hccnet.nl">
Re: output confusion <spamtrap@dot-app.org>
Re: output confusion <"v.niekerk at hccnet.nl">
Re: output confusion <tadmc@augustmail.com>
trying to determine gethostbyaddr call issues doesnt ap j.greg.k@gmail.com
Re: trying to determine gethostbyaddr call issues doesn <marora@gmail.com>
Re: trying to determine gethostbyaddr call issues doesn <glex_no-spam@qwest-spam-no.invalid>
Re: Urgent requirement in perl for a US based CMM Level <tadmc@augustmail.com>
Re: What is abriviationfor CHR(4) usenet@DavidFilmer.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 16 Mar 2007 16:39:10 -0700
From: "TahoeKid" <rfdunn@hotmail.com>
Subject: How to decompose nested objects
Message-Id: <1174088350.174531.298330@l77g2000hsb.googlegroups.com>
I've created nested objects in perl, but having a problem extracting
the nested objects. I also haven't found any sample code in books or
groups... Any help would be great.
------------------------------
Date: Fri, 16 Mar 2007 18:32:27 GMT
From: "Mumia W." <paduille.4060.mumia.w+nospam@earthlink.net>
Subject: Re: new CGI::Session creates a new session every visit. GRRR!!!
Message-Id: <%oBKh.13321$tD2.3399@newsread1.news.pas.earthlink.net>
On 03/16/2007 11:54 AM, TonyV wrote:
>
> I just tried this. I now have the following lines in my program:
>
> my $cgi = new CGI;
> my $session = new CGI::Session(undef, $cgi, {Directory=>'/websessions/
> test'}) or die CGI::Session->errstr;
> my $cookie = $cgi->cookie(CGISESSID => $session->id );
>
> It does exactly the same thing: creates a new session every time the
> page is loaded. >:-( [...]
>
> Any other ideas? It's still driving me crazy.
>
I tried your original code with one modification: the one suggested in
CGI::Session::Tutorial, and it worked. It only created one session even
though I hit Reload several times in Firefox.
Here is a simpler script that works on my system:
use strict;
use warnings;
use CGI::Session;
use CGI;
my $cgi = new CGI;
my $session = new CGI::Session (undef, $cgi,
{ Directory => '/tmp/websessions' });
my $name = $session->param('name') || $cgi->param('first_name');
$session->param('name',$name) if ($name);
print $cgi->header(
'-content-type' => 'text/html',
-expires => '+20s'
);
print $cgi->start_html('CGI::Session Test Page'),
$cgi->h1("Hello user: $name"),
$cgi->end_html;
__END__
The script does not consider "0" to be a valid name :-) , but I think it
demonstrates the technique simply.
I'm using this:
Debian 3.1
CGI 3.04
CGI::Session 3.95
------------------------------
Date: 16 Mar 2007 12:51:06 -0700
From: "TonyV" <kingskippus@gmail.com>
Subject: Re: new CGI::Session creates a new session every visit. GRRR!!!
Message-Id: <1174074666.707109.12660@l77g2000hsb.googlegroups.com>
First of all, thanks for all of your replies.
Second of all, I'm not crazy, and I'm still experiencing problems. My
tests worked, but when I went back to my original program and made
changes, it was still doing the same thing, creating a new session on
every load.
After some more poking and LOTS of commenting out my original code,
slowly making it into my test case, I narrowed down the problem, and
it seems to be something screwy with a combination of DBI and global
variables. Weird, huh? Let me explain.
If I take Mumia W.'s code above and tweak it with my websessions
directory and the addition of the cookie, I get this:
------------------------------------------------------------
use strict;
use warnings;
use CGI;
use CGI::Session;
my $cgi = new CGI;
my $session = new CGI::Session (undef, $cgi,
{ Directory => '/websessions/test' });
my $name = $cgi->param('name') || $session->param('name');
$session->param('name',$name) if ($name);
my $cookie = $cgi->cookie(CGISESSID => $session->id);
print $cgi->header(
'-content-type' => 'text/html',
-expires => '+20s',
-cookie=> $cgi->cookie(CGISESSID=>$session->id)
);
print $cgi->start_html('CGI::Session Test Page'),
$cgi->h1("Hello user: $name"),
$cgi->end_html;
------------------------------------------------------------
This works like a charm. However, I need database functionality, so I
add DBI so that my use section looks like this:
use strict;
use warnings;
use CGI;
use CGI::Session;
use DBI;
So far, so good, and everything still works fine. So now, I want to
make my program a little more modular, so I put a lot of that stuff
into a Main function. I want my $cgi and $session variables to be
global, though. So now my program looks like this:
------------------------------------------------------------
use strict;
use warnings;
use CGI;
use CGI::Session;
use DBI;
my $cgi;
my $session;
Main();
sub Main
{
$cgi = new CGI;
$session = new CGI::Session (undef, $cgi,
{ Directory => '/websessions/test' });
my $name = $cgi->param('name') || $session->param('name');
$session->param('name',$name) if ($name);
my $cookie = $cgi->cookie(CGISESSID => $session->id);
print $cgi->header(
'-content-type' => 'text/html',
-expires => '+20s',
-cookie=> $cgi->cookie(CGISESSID=>$session->id)
);
print $cgi->start_html('CGI::Session Test Page'),
$cgi->h1("Hello user: $name"),
$cgi->end_html;
}
------------------------------------------------------------
BOOM!!! Now, it starts creating session after session after session.
If I remove the use DBI, everything works fine again. If I remove the
global $cgi and $session variables and make them local within Main
instead, everything works fine. I even thought that maybe DBI had
some kind of global variables that conflict with $cgi and/or $session,
so I renamed them to $zxcvb and $asdfg, but it still creates new
sessions only. Even if I specifically *tell* it the session ID, it
*still* creates new sessions only.
Am I doing something syntactically wrong, or is this a genuine bug?
------------------------------
Date: 16 Mar 2007 12:53:16 -0700
From: "TonyV" <kingskippus@gmail.com>
Subject: Re: new CGI::Session creates a new session every visit. GRRR!!!
Message-Id: <1174074796.465551.133640@b75g2000hsg.googlegroups.com>
On Mar 16, 1:58 pm, Sherm Pendley <spamt...@dot-app.org> wrote:
> Actually, you shouldn't be looking at cpan.org for docs at all. The docs
> that are included with the module itself, right on your own computer, are
> guaranteed to always be for the version you have.
>
> sherm--
You're right, but I don't really have much choice. Perl isn't
actually installed on my computer; it's installed on the server and I
don't have easy access to them there.
------------------------------
Date: Fri, 16 Mar 2007 19:58:30 GMT
From: "Mumia W." <paduille.4060.mumia.w+nospam@earthlink.net>
Subject: Re: new CGI::Session creates a new session every visit. GRRR!!!
Message-Id: <GFCKh.10496$PL.3239@newsread4.news.pas.earthlink.net>
On 03/16/2007 01:32 PM, Mumia W. wrote:
>
> Here is a simpler script that works on my system:
> [...]
Scratch that. The program is not working. Details at 11.
------------------------------
Date: Fri, 16 Mar 2007 20:33:08 GMT
From: "Mumia W." <paduille.4060.mumia.w+nospam@earthlink.net>
Subject: Re: new CGI::Session creates a new session every visit. GRRR!!!
Message-Id: <8aDKh.13373$tD2.1606@newsread1.news.pas.earthlink.net>
On 03/16/2007 02:58 PM, Mumia W. wrote:
> On 03/16/2007 01:32 PM, Mumia W. wrote:
>>
>> Here is a simpler script that works on my system:
>> [...]
>
> Scratch that. The program is not working. Details at 11.
Okay, my program failed because I was leaving out the session cookie. Doh!
------------------------------
Date: Fri, 16 Mar 2007 20:33:10 GMT
From: "Mumia W." <paduille.4060.mumia.w+nospam@earthlink.net>
Subject: Re: new CGI::Session creates a new session every visit. GRRR!!!
Message-Id: <aaDKh.13374$tD2.4922@newsread1.news.pas.earthlink.net>
On 03/16/2007 02:51 PM, TonyV wrote:
> First of all, thanks for all of your replies.
>
> Second of all, I'm not crazy, and I'm still experiencing problems. My
> tests worked, but when I went back to my original program and made
> changes, it was still doing the same thing, creating a new session on
> every load.
>
> After some more poking and LOTS of commenting out my original code,
> slowly making it into my test case, I narrowed down the problem, and
> it seems to be something screwy with a combination of DBI and global
> variables. Weird, huh? Let me explain.
>
> If I take Mumia W.'s code above and tweak it with my websessions
> directory and the addition of the cookie, I get this:
>
> ------------------------------------------------------------
> use strict;
> use warnings;
> use CGI;
> use CGI::Session;
>
> my $cgi = new CGI;
> my $session = new CGI::Session (undef, $cgi,
> { Directory => '/websessions/test' });
>
> my $name = $cgi->param('name') || $session->param('name');
> $session->param('name',$name) if ($name);
>
> my $cookie = $cgi->cookie(CGISESSID => $session->id);
>
> print $cgi->header(
> '-content-type' => 'text/html',
> -expires => '+20s',
> -cookie=> $cgi->cookie(CGISESSID=>$session->id)
> );
>
> print $cgi->start_html('CGI::Session Test Page'),
> $cgi->h1("Hello user: $name"),
> $cgi->end_html;
> ------------------------------------------------------------
>
> This works like a charm. However, I need database functionality, so I
> add DBI so that my use section looks like this:
>
> use strict;
> use warnings;
> use CGI;
> use CGI::Session;
> use DBI;
>
> So far, so good, and everything still works fine. So now, I want to
> make my program a little more modular, so I put a lot of that stuff
> into a Main function. I want my $cgi and $session variables to be
> global, though. So now my program looks like this:
>
> ------------------------------------------------------------
> use strict;
> use warnings;
> use CGI;
> use CGI::Session;
> use DBI;
>
> my $cgi;
> my $session;
>
> Main();
>
> sub Main
> {
> $cgi = new CGI;
> $session = new CGI::Session (undef, $cgi,
> { Directory => '/websessions/test' });
>
> my $name = $cgi->param('name') || $session->param('name');
> $session->param('name',$name) if ($name);
>
> my $cookie = $cgi->cookie(CGISESSID => $session->id);
>
> print $cgi->header(
> '-content-type' => 'text/html',
> -expires => '+20s',
> -cookie=> $cgi->cookie(CGISESSID=>$session->id)
> );
>
> print $cgi->start_html('CGI::Session Test Page'),
> $cgi->h1("Hello user: $name"),
> $cgi->end_html;
> }
> ------------------------------------------------------------
>
> BOOM!!! Now, it starts creating session after session after session.
> If I remove the use DBI, everything works fine again. If I remove the
> global $cgi and $session variables and make them local within Main
> instead, everything works fine. I even thought that maybe DBI had
> some kind of global variables that conflict with $cgi and/or $session,
> so I renamed them to $zxcvb and $asdfg, but it still creates new
> sessions only. Even if I specifically *tell* it the session ID, it
> *still* creates new sessions only.
>
> Am I doing something syntactically wrong, or is this a genuine bug?
>
The program above works perfectly on my system. I used copy and paste,
and the only thing I changed was the sessions directory.
BTW, you can simplify the program by reusing the cookie object when you
print the HTTP header:
-cookie => $cookie,
HTH
------------------------------
Date: Fri, 16 Mar 2007 21:27:53 GMT
From: "Mumia W." <paduille.4060.mumia.w+nospam@earthlink.net>
Subject: Re: new CGI::Session creates a new session every visit. GRRR!!!
Message-Id: <tZDKh.128170$_73.117252@newsread2.news.pas.earthlink.net>
On 03/16/2007 02:51 PM, TonyV wrote:
> [...]
> BOOM!!! Now, it starts creating session after session after session.
> If I remove the use DBI, everything works fine again. If I remove the
> global $cgi and $session variables and make them local within Main
> instead, everything works fine. I even thought that maybe DBI had
> some kind of global variables that conflict with $cgi and/or $session,
> so I renamed them to $zxcvb and $asdfg, but it still creates new
> sessions only. Even if I specifically *tell* it the session ID, it
> *still* creates new sessions only.
>
> Am I doing something syntactically wrong, or is this a genuine bug?
>
I don't know what environment you're running under, but mod_perl seems
to complicate things. This script works on my Apache2, mod_perl_2 system:
use strict;
use warnings;
use CGI;
use DBI;
use Cwd;
use CGI::Session;
use File::Basename;
use Data::Dumper;
my $cgi;
my $session;
chdir(dirname($ENV{SCRIPT_FILENAME}));
my ($dsn, $user, $pass) = @{require 'dsn.pl'};
my $dbh = DBI->connect($dsn, $user, $pass) or die $DBI::errstr;
my $Main = sub {
$cgi = new CGI;
$session = new CGI::Session ('driver:MySQL', $cgi,
{ Handle => $dbh }) or die $CGI::Session::errstr;
my $name = $cgi->param('name') || $session->param('name');
$session->param('name',$name) if ($name);
my $cookie = $cgi->cookie(CGISESSID => $session->id);
print $cgi->header(
'-content-type' => 'text/html',
-expires => '+20s',
-cookie=> $cookie,
);
print $cgi->start_html('CGI::Session Test Page'),
$cgi->h1("Hello there user: $name"),
# $cgi->pre(CGI::escapeHTML(Dumper(\%ENV))),
$cgi->end_html;
};
$Main->();
$dbh->disconnect;
undef $dbh;
__END__
I decided to make Main a closure because I saw a warning in the Apache
error_log: "$cgi will not stay shared." And under mod_perl,
disconnecting from the database is a good idea because that won't happen
automatically like it should under true CGI.
I have no doubt that it gets even more complicated as you delve more
into databases, persistent connections and persistent Perl interpreters.
------------------------------
Date: 16 Mar 2007 15:32:40 -0700
From: "TonyV" <kingskippus@gmail.com>
Subject: Re: new CGI::Session creates a new session every visit. GRRR!!!
Message-Id: <1174084360.017914.226850@o5g2000hsb.googlegroups.com>
I think there's been some confusion. I'm not actually storing the
session information in the database; I'm using the default file driver
for it. The database stuff is totally unrelated to the session stuff
I'm trying to get working.
It looks to me like one cannot copy the $session variable without
creating a new session from it. In other words, if you do something
like this:
my $session = new CGI::Session(undef, $cgi);
You're good to go. But if you do something like this:
my $session1 = new CGI::Session(undef, $cgi);
my $session2 = $session1;
This will create a new session. What I'm guessing is happening is
that by declaring my $session in one place and then calling
CGI::Session->new in another, it's "thinking" that you're copying a
session and creating a whole new one.
The thing that is really annoying me is that if I don't use DBI, it
doesn't do that. Only when I use DBI does it start exhibiting this
strange behavior. The DBI I'm using came with ActiveState Perl, and
I've also got DBD-Oracle 1.17 installed.
Just as a temporary hack, I've started using $session as a reference
to the session instead of the session variable itself. Uuuugly, but
at least it works. :-(
------------------------------
Date: 17 Mar 2007 00:10:49 GMT
From: xhoster@gmail.com
Subject: Re: new CGI::Session creates a new session every visit. GRRR!!!
Message-Id: <20070316201053.041$Ub@newsreader.com>
Sherm Pendley <spamtrap@dot-app.org> wrote:
> "TonyV" <kingskippus@gmail.com> writes:
>
> > Unfortunately, it looks like there isn't a CGI-Session-4.20 available
> > for Windows, at least not from ActiveState. :-( Oh well, at any
> > rate, in case anyone else finds this thread through your favorite
> > search engine *here* are the documents you should be looking at:
>
> Actually, you shouldn't be looking at cpan.org for docs at all. The docs
> that are included with the module itself, right on your own computer, are
> guaranteed to always be for the version you have.
Unless you are discussing things with other people (for example, people on
usenet) in which case what is installed on your own computer isn't terribly
relevant to what behavior other people are experiencing. I think that
asking someone to install a different version on their computer so that
they can access the docs to that different versions is doing a bit far.
Going to CPAN seems like exactly the right solution.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 17 Mar 2007 00:16:00 GMT
From: xhoster@gmail.com
Subject: Re: new CGI::Session creates a new session every visit. GRRR!!!
Message-Id: <20070316201604.007$p9@newsreader.com>
"Mumia W." <paduille.4060.mumia.w+nospam@earthlink.net> wrote:
> On 03/16/2007 02:51 PM, TonyV wrote:
> > [...]
> > BOOM!!! Now, it starts creating session after session after session.
> > If I remove the use DBI, everything works fine again. If I remove the
> > global $cgi and $session variables and make them local within Main
> > instead, everything works fine. I even thought that maybe DBI had
> > some kind of global variables that conflict with $cgi and/or $session,
> > so I renamed them to $zxcvb and $asdfg, but it still creates new
> > sessions only. Even if I specifically *tell* it the session ID, it
> > *still* creates new sessions only.
> >
> > Am I doing something syntactically wrong, or is this a genuine bug?
> >
>
> I don't know what environment you're running under, but mod_perl seems
> to complicate things. This script works on my Apache2, mod_perl_2 system:
>
> use strict;
> use warnings;
> use CGI;
> use DBI;
> use Cwd;
> use CGI::Session;
> use File::Basename;
> use Data::Dumper;
>
> my $cgi;
> my $session;
>
> chdir(dirname($ENV{SCRIPT_FILENAME}));
>
> my ($dsn, $user, $pass) = @{require 'dsn.pl'};
> my $dbh = DBI->connect($dsn, $user, $pass) or die $DBI::errstr;
>
> my $Main = sub {
> $cgi = new CGI;
> $session = new CGI::Session ('driver:MySQL', $cgi,
> { Handle => $dbh }) or die $CGI::Session::errstr;
>
> my $name = $cgi->param('name') || $session->param('name');
> $session->param('name',$name) if ($name);
>
> my $cookie = $cgi->cookie(CGISESSID => $session->id);
>
> print $cgi->header(
> '-content-type' => 'text/html',
> -expires => '+20s',
> -cookie=> $cookie,
> );
>
> print $cgi->start_html('CGI::Session Test Page'),
> $cgi->h1("Hello there user: $name"),
> # $cgi->pre(CGI::escapeHTML(Dumper(\%ENV))),
> $cgi->end_html;
> };
>
> $Main->();
>
> $dbh->disconnect;
> undef $dbh;
>
> __END__
>
> I decided to make Main a closure because I saw a warning in the Apache
> error_log: "$cgi will not stay shared."
Wouldn't it be better to move your declaration of $cgi, etc. into the
subroutine (as they aren't used anywhere outside the sub), and move the
$dbh disconnect into the sub as well? Then Main could be changed back
to a regular sub.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Fri, 16 Mar 2007 19:14:34 +0100
From: Huub <"v.niekerk at hccnet.nl">
Subject: Re: output confusion
Message-Id: <45fade8a$0$22668$e4fe514c@dreader14.news.xs4all.nl>
>
> It's pretty close to that. Do the first example at the top of the POD
> for PostScript::Simple. The POD tells you how to set the font and colour.
>
> You can read the POD by doing "perldoc PostScript::Simple"
>
>
OK, thank you. I've been experimenting and got some nice results. One
odd(?) thing that catches my eye is that the text is written bottom -
up, instead of top - down. And I do start at (6, 12) with the next being
(6, 17). Any explanation?
------------------------------
Date: Fri, 16 Mar 2007 17:09:32 -0400
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: output confusion
Message-Id: <m2veh0j3oz.fsf@local.wv-www.com>
Huub <"v.niekerk at hccnet.nl"> writes:
> OK, thank you. I've been experimenting and got some nice results. One
> odd(?) thing that catches my eye is that the text is written bottom -
> up, instead of top - down. And I do start at (6, 12) with the next
> being (6, 17). Any explanation?
That's the PostScript coordinate system. (0,0) is at the bottom left.
sherm--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: Fri, 16 Mar 2007 22:17:40 +0100
From: Huub <"v.niekerk at hccnet.nl">
Subject: Re: output confusion
Message-Id: <45fb0976$0$4389$e4fe514c@dreader21.news.xs4all.nl>
> That's the PostScript coordinate system. (0,0) is at the bottom left.
>
> sherm--
>
Ahh ok...so I have to countdown y to start at top left.
------------------------------
Date: Fri, 16 Mar 2007 19:01:39 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: output confusion
Message-Id: <slrnevmbv3.c6f.tadmc@tadmc30.august.net>
Huub <"v.niekerk at hccnet.nl"> wrote:
> I do this:
>
> open(out,">$FILE");
Don't do that!
Do use UPPER CASE filehandles.
Do use lower case variable names.
Do check the return value from open().
Do use the 3-argument form of open().
Do include the $! variable in your diagnostic message.
Do include the delimited filename in your diagnostic message.
Putting all of that together, you should model your opens like this:
open my $out, '>', $file or die "could not open '$file' $!";
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 16 Mar 2007 13:30:58 -0700
From: j.greg.k@gmail.com
Subject: trying to determine gethostbyaddr call issues doesnt appear to be dns related
Message-Id: <1174077058.220757.294670@l75g2000hse.googlegroups.com>
I have checked the dns ptr records for the example below and the
records exists. also when doing an nslookup from the console on the
system in which perl is installed I get the correct name
$ nslookup a.b.c.d
Server: a.b.c.2
Address: a.b.c.2#53
d.c.b.a.in-addr.arpa name = ccc_dddd_ddddddd_ddd_cc.dom.ain.
Where c = character and d = digit. It's a common naming convention we
use on our internal dns servers:
building_model_serialtag_other-tag_type
I am not allowed to post the ip address or name but since it is
internal and the world cannot resolve the address anyhow it would not
do much good even if I could.
Next is the output when I run the perl program
$ ./hostname.pl
SUB:GETHOSTNAME: Got ccc_dddd_ddddddd_ddd
It truncates the last _ccc for some reason. Here is the code. It works
for all but the cases above in which the last few characters are _sw
and the length of the return value is at or more than 20 places ( I
have about 5 cases so far out of 1200 nodes)
#!/usr/bin/perl
use Socket;
#####################################
# Sub: GetHostname
#####################################
sub gethostname
{
my $target = shift;
$dname = gethostbyaddr(inet_aton($target),AF_INET) or $dname =
'noresolve';
print " SUB:GETHOSTNAME: Got $dname\n";
}
my $target = 'a.b.c.d';
gethostname ($target);
I am running this on an intel system RHES 4
perl -v
This is perl, v5.8.5 built for i386-linux-thread-mult
any ideas?
------------------------------
Date: 16 Mar 2007 15:26:59 -0700
From: "Manish" <marora@gmail.com>
Subject: Re: trying to determine gethostbyaddr call issues doesnt appear to be dns related
Message-Id: <1174084019.171272.246500@l75g2000hse.googlegroups.com>
On Mar 16, 3:30 pm, j.gre...@gmail.com wrote:
> I have checked the dns ptr records for the example below and the
> records exists. also when doing an nslookup from the console on the
> system in which perl is installed I get the correct name
>
> $ nslookup a.b.c.d
> Server: a.b.c.2
> Address: a.b.c.2#53
>
> d.c.b.a.in-addr.arpa name = ccc_dddd_ddddddd_ddd_cc.dom.ain.
>
> Where c = character and d = digit. It's a common naming convention we
> use on our internal dns servers:
> building_model_serialtag_other-tag_type
>
> I am not allowed to post the ip address or name but since it is
> internal and the world cannot resolve the address anyhow it would not
> do much good even if I could.
>
> Next is the output when I run the perl program
>
> $ ./hostname.pl
> SUB:GETHOSTNAME: Got ccc_dddd_ddddddd_ddd
>
> It truncates the last _ccc for some reason. Here is the code. It works
> for all but the cases above in which the last few characters are _sw
> and the length of the return value is at or more than 20 places ( I
> have about 5 cases so far out of 1200 nodes)
>
> #!/usr/bin/perl
> use Socket;
> #####################################
> # Sub: GetHostname
> #####################################
> sub gethostname
> {
> my $target = shift;
> $dname = gethostbyaddr(inet_aton($target),AF_INET) or $dname =
> 'noresolve';
> print " SUB:GETHOSTNAME: Got $dname\n";
>
> }
>
> my $target = 'a.b.c.d';
> gethostname ($target);
>
> I am running this on an intel system RHES 4
> perl -v
> This is perl, v5.8.5 built for i386-linux-thread-mult
>
> any ideas?
Your code doesnot masks anything. I have tried using a global address
such as www.yahoo.com, I don't see the problem you described. Perhaps
you can try to use some other IP address, and provide us the sample
problem.
Regards,
Manish
------------------------------
Date: Fri, 16 Mar 2007 16:45:32 -0600
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: trying to determine gethostbyaddr call issues doesnt appear to be dns related
Message-Id: <45fb1e0c$0$516$815e3792@news.qwest.net>
j.greg.k@gmail.com wrote:
[...]
> sub gethostname
> {
> my $target = shift;
> $dname = gethostbyaddr(inet_aton($target),AF_INET) or $dname =
> 'noresolve';
my $dname = gethostbyaddr(inet_aton($target),AF_INET) || 'noresolve';
That probably doesn't fix anything, but it should be corrected.
------------------------------
Date: Fri, 16 Mar 2007 19:07:03 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Urgent requirement in perl for a US based CMM Level 4 company
Message-Id: <slrnevmc97.c6f.tadmc@tadmc30.august.net>
josh.arni@gmail.com <josh.arni@gmail.com> wrote:
> Must be strong in WEB application concepts and hands on with Web-app
> development.
What is the difference between a "WEB application" and a "Web-app"?
> Must have experience in Postgres SQL, MySQL, PERL, OOPerl experience
There is no programming language named PERL.
That is going to make it very hard to find someone who knows it...
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 16 Mar 2007 12:13:01 -0700
From: usenet@DavidFilmer.com
Subject: Re: What is abriviationfor CHR(4)
Message-Id: <1174072381.092500.267880@e1g2000hsg.googlegroups.com>
On Mar 15, 9:35 pm, Uri Guttman <u...@stemsystems.com> wrote:
> j> 1 - Creation of online charts and graphs controlled by user input
> with circles and arrows on the back of each one explaining them
But what Miles doesn't tell you is that the users are blind.
------------------------------
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 233
**************************************
