[23042] in Perl-Users-Digest
Perl-Users Digest, Issue: 5263 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jul 24 00:08:07 2003
Date: Wed, 23 Jul 2003 21:05:11 -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 Wed, 23 Jul 2003 Volume: 10 Number: 5263
Today's topics:
Authentication with LWP (Avatar)
Called as method or subroutine? <coo_t2-NO-LIKE-SPAM@yahoo.com>
Re: Called as method or subroutine? <REMOVEsdnCAPS@comcast.net>
Re: Called as method or subroutine? <grazz@pobox.com>
Chomp temporarily nullifies my scalar variable. <jandellis@hotmail.com>
Re: Chomp temporarily nullifies my scalar variable. <grazz@pobox.com>
Re: Chomp temporarily nullifies my scalar variable. <bwalton@rochester.rr.com>
Re: Chomp temporarily nullifies my scalar variable. <jandellis@hotmail.com>
Correct file handling on Linux (Jon)
Re: Correct file handling on Linux <shawn@magma.ca>
Re: Correct file handling on Linux (Tad McClellan)
Re: Correct file handling on Linux (Pierre Asselin)
Re: Data::Dumper vs perl -d (Sam Holden)
Re: Data::Dumper vs perl -d <REMOVEsdnCAPS@comcast.net>
Re: generalizing cgi handling <bart.lateur@pandora.be>
how to initialize size of DOS Window? <cuzin@adelphia.net>
Re: how to initialize size of DOS Window? (remove the obvious)
Re: IP Conversion..Sending to Subroutine.. (David Efflandt)
Re: JOIN problem ? (2nd attempt to post) (stu7)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 23 Jul 2003 11:51:36 -0700
From: ksu1wd@mit.edu (Avatar)
Subject: Authentication with LWP
Message-Id: <415d5171.0307231051.5e905757@posting.google.com>
I am trying to login to this website so I can access the information.
Here is the code I am trying:
use strict;
use warnings;
use LWP;
my $browser=LWP::UserAgent->new;
$browser->credentials(
'http://ibol29-01-ldn.ibb.ubs.com/pages/derivatives/indexes.jsp?TabM1=3:80',
'Client login',
'usname' => 'pswd');
my $response=$browser->get(
'http://ibol29-01-ldn.ibb.ubs.com/pages/derivatives/indexes.jsp?TabM1=3:80'
);
print $response->content;
I cannot give the real password, but the url is correct, though :80 is
the port so it doesn't have to be there.
The result of running this gives me:
<html>
<head>
<meta http-equiv="refresh"
content="0;URL=https://clientlogin.ibb.ubs.com/login?
_URI=aHR0cDovL2lib2wyOS0wMS1sZG4uaWJiLnVicy5jb20vcGFnZXMvZGVyaXZhdGl2ZXMvaW5kZXh
lcy5qc3A%2FVGFiTTE9Mzo4MA%3D%3D">
</head>
<body></body>
</html>
and when I comment out browser->credentials, I get the same result.
My first question is, how to get the correct realm, because I am aware
that 'Client login' is not accurate.
And my second quesiton is, when I do have the correct realm, how do I
use browser-credentials correctly to get the information I want. If I
left anything out, please let me know, by private email or follow-up
posts. Thanks in advance for your help.
------------------------------
Date: Wed, 23 Jul 2003 23:47:54 GMT
From: ed <coo_t2-NO-LIKE-SPAM@yahoo.com>
Subject: Called as method or subroutine?
Message-Id: <gk7uhvstvnnct0e73big7muhujl3h7jte9@4ax.com>
Hi is there a way to make a sub/method compatible with
the two following calling methods?
1. MyClass::mySub();
2. MyClass->mySub();
Using the first method gives me one less argument in my argument list.
How do you deal with both situations?
Is there an easy way to find out if you're being invoked a method or
subroutine?
tia,
--ed
------------------------------
Date: Wed, 23 Jul 2003 21:51:23 -0500
From: "Eric J. Roode" <REMOVEsdnCAPS@comcast.net>
Subject: Re: Called as method or subroutine?
Message-Id: <Xns93C1E876EEB5Bsdn.comcast@206.127.4.25>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
ed <coo_t2-NO-LIKE-SPAM@yahoo.com> wrote in
news:gk7uhvstvnnct0e73big7muhujl3h7jte9@4ax.com:
> Hi is there a way to make a sub/method compatible with
> the two following calling methods?
>
> 1. MyClass::mySub();
> 2. MyClass->mySub();
>
> Using the first method gives me one less argument in my argument list.
> How do you deal with both situations?
> Is there an easy way to find out if you're being invoked a method or
> subroutine?
Well, you could check the first argument and see if it's equal to
__PACKAGE__. But that's not a good solution, because it breaks
inheritance.
I don't think there's a solution, except to document which way your
subroutines expect to be invoked.
- --
Eric
$_ = reverse sort qw p ekca lre Js reh ts
p, $/.r, map $_.$", qw e p h tona e; print
-----BEGIN xxx SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBPx9JmmPeouIeTNHoEQKn8ACg9jDe1WWaHJT+csmLPwN6XnaeUfYAoJwD
8Jfap+x0x79PzbMuL3F+zL5r
=2zbJ
-----END PGP SIGNATURE-----
------------------------------
Date: Thu, 24 Jul 2003 03:09:14 GMT
From: Steve Grazzini <grazz@pobox.com>
Subject: Re: Called as method or subroutine?
Message-Id: <u5ITa.22316$0F4.19764@nwrdny02.gnilink.net>
ed <coo_t2-NO-LIKE-SPAM@yahoo.com> wrote:
> Hi is there a way to make a sub/method compatible with
> the two following calling methods?
>
> 1. MyClass::mySub();
> 2. MyClass->mySub();
Not a good way.
You'd have to look at the number of arguments and the value
of the first argument and take a guess.
These are going to look awfully similar, though:
Class->sub;
Class::sub("Class");
--
Steve
------------------------------
Date: Thu, 24 Jul 2003 02:16:11 GMT
From: Joseph Ellis <jandellis@hotmail.com>
Subject: Chomp temporarily nullifies my scalar variable.
Message-Id: <77guhvo4sd0ajirrb58im20gd2dfkl893j@4ax.com>
I am writing a program / script (in Perl, yet) that will parse a text
database of genealogy information to generate a web-based family tree.
When invoking the script, I have to give it an ID such as "I108" to
search for. Development has been going fine so far, but since I often
forget to specify an ID, I'm making a little if {} block to allow me
to type in an ID when I forget to do so at invocation:
#!/usr/bin/perl
use strict;
use warnings;
use CGI ':standard';
use CGI::Carp qw(fatalsToBrowser);
my $gedcom="Joseph Ellis Family.ged";
my $id = param('id');
if (not $id) { ## Just because I keep forgetting to specify the ID
print ("\n\nSpecify an ID to work with.\n: ");
chomp ($id = <STDIN>);
print "\n$id newline?\n\n"; ## for debugging
}
my %data;
my $found;
my @record;
my %indiv = &getrec($id);
print "Hash contents for ID: $id\n\n"; ## for debugging
foreach (sort keys %indiv) {
printf "%10s : %s\n", $_, $indiv{$_};
}
etc etc
The problem is that the chomp ($id = <STDIN>) seems to be killing $id
for the following print statement, but not for the print "Hash
contents... statement later in the program. Output looks like:
newline?
Hash contents for ID: I108
But if I get rid of the chomp, output is as expected:
I108
newline?
Hash contents for ID: I108
Any thoughts on this? I've searched perldoc -f and the perlfaqs to no
avail.
Thanks,
Joseph
------------------------------
Date: Thu, 24 Jul 2003 03:00:56 GMT
From: Steve Grazzini <grazz@pobox.com>
Subject: Re: Chomp temporarily nullifies my scalar variable.
Message-Id: <IZHTa.22302$0F4.3569@nwrdny02.gnilink.net>
Joseph Ellis <jandellis@hotmail.com> wrote:
> chomp ($id = <STDIN>);
> print "\n$id newline?\n\n"; ## for debugging
[ snip ]
> The problem is that the chomp ($id = <STDIN>) seems to be
> killing $id for the following print statement, but not for
> the print "Hash contents... statement later in the program.
It looks like you read $id = "ID\r\n" and chomp() only removed
the newline.
--
Steve
------------------------------
Date: Thu, 24 Jul 2003 03:35:53 GMT
From: Bob Walton <bwalton@rochester.rr.com>
Subject: Re: Chomp temporarily nullifies my scalar variable.
Message-Id: <3F1F53FD.6080605@rochester.rr.com>
Joseph Ellis wrote:
> I am writing a program / script (in Perl, yet) that will parse a text
> database of genealogy information to generate a web-based family tree.
> When invoking the script, I have to give it an ID such as "I108" to
> search for. Development has been going fine so far, but since I often
> forget to specify an ID, I'm making a little if {} block to allow me
> to type in an ID when I forget to do so at invocation:
>
> #!/usr/bin/perl
>
> use strict;
> use warnings;
> use CGI ':standard';
> use CGI::Carp qw(fatalsToBrowser);
>
> my $gedcom="Joseph Ellis Family.ged";
> my $id = param('id');
>
> if (not $id) { ## Just because I keep forgetting to specify the ID
> print ("\n\nSpecify an ID to work with.\n: ");
> chomp ($id = <STDIN>);
You are running a CGI script. STDIN is therefore either hooked up to
the output of your web browser (POST mode) or not hooked to anything
(GET mode), and STDOUT is hooked to your browser. It won't give you a
prompt and permit you to input on your browser if that is what you were
hoping for (although it will print the prompt message on your browser).
Nor will it give you a console window with the prompt in it. Your
best bet is to generate an error page with a "back" link explaining what
happened and how to fix it.
But I'm confused -- you neglected to print an HTTP header, so you should
get a 500 error from this. Are you just running the script standalone
at the moment? If so, you should be prepared for this not to work when
you try it as a CGI.
I don't have an explanation for the remainder of the behavior you
describe. It doesn't do that on my system (Windoze 98SE, AS build 806)
-- I get the expected output. And it should work properly on any
platform I know of.
...
> Joseph
--
Bob Walton
------------------------------
Date: Thu, 24 Jul 2003 03:38:27 GMT
From: Joseph Ellis <jandellis@hotmail.com>
Subject: Re: Chomp temporarily nullifies my scalar variable.
Message-Id: <ptjuhvsha864rfjofkc1nv7tu6sj190te2@4ax.com>
On Thu, 24 Jul 2003 03:00:56 GMT, Steve Grazzini <grazz@pobox.com>
wrote:
>Joseph Ellis <jandellis@hotmail.com> wrote:
>> chomp ($id = <STDIN>);
>> print "\n$id newline?\n\n"; ## for debugging
>
>[ snip ]
>
>> The problem is that the chomp ($id = <STDIN>) seems to be
>> killing $id for the following print statement, but not for
>> the print "Hash contents... statement later in the program.
>
>It looks like you read $id = "ID\r\n" and chomp() only removed
>the newline.
Yes, you're right. Putting $id =~ s/\r//; after the chomp statement
fixed the problem.
But in a fit of raging curiosity, I've done the following:
if (not $id) { ## Just because I keep forgetting to specify the ID
print ("\n\nSpecify an ID to work with.\n: ");
chomp ($id = <STDIN>);
print "Is there a carriage return following the ID? $id\n";
print "Is there a carriage return $id following the ID?\n";
exit;
}
This outputs:
Is there a carriage return following the ID? I108
following the ID?e return I108
Any idea why the first line printed "properly", and the second line
printed "improperly"?
------------------------------
Date: 23 Jul 2003 16:09:05 -0700
From: jon18_uk2002@yahoo.co.uk (Jon)
Subject: Correct file handling on Linux
Message-Id: <83bd902f.0307231416.27e72bc1@posting.google.com>
Lately I have been reviewing how my Perl scripts handles files they
write to, as until now I have already taken for granted that it will
"just work", so many of my scripts never stopped when they could not
write to or read a file.
My normal setup is Perl 5.6.0, Linux 2.4.x kernel, ext2 filesystem
(although our newer servers do use ext3, however unfortunately most
still use ext2).
open(LOG,">>/path/to/file") or &bad_file;
print LOG "xx";
close(LOG);
Now that works fine, and if the path is invalid it will error out
nicely, however, one of my scripts has the possibility of being run
regularly, each time it will write to a file.
So my question is, if 2 scripts run at the same split second and get
around to writing to the same file at the same time what would be the
result? Would one fail and the other succeed, or would the file be
damaged maybe (if I was using the above code for example).
Thank you for any advise,
Jon.
------------------------------
Date: Wed, 23 Jul 2003 19:23:54 -0400
From: Shawn Corey <shawn@magma.ca>
Subject: Re: Correct file handling on Linux
Message-Id: <ReGcneS1A5DphYKiXTWJhQ@magma.ca>
Hi,
I'm not sure about all varieties of Linux but I assumed it acts like
UNIX. Each program writes to the file when (1) its buffer is full, (2)
when a flush is done, or (3) when the file is closed. The file will
contain the output from both programs intermixed in a random manner.
See perldoc -f flock for a way of locking a file. Note that all programs
using the file must flock or you may end up with the same problem. And,
of course, if your OS does not support flock, same as above.
Jon wrote:
> Lately I have been reviewing how my Perl scripts handles files they
> write to, as until now I have already taken for granted that it will
> "just work", so many of my scripts never stopped when they could not
> write to or read a file.
>
> My normal setup is Perl 5.6.0, Linux 2.4.x kernel, ext2 filesystem
> (although our newer servers do use ext3, however unfortunately most
> still use ext2).
>
> open(LOG,">>/path/to/file") or &bad_file;
> print LOG "xx";
> close(LOG);
>
> Now that works fine, and if the path is invalid it will error out
> nicely, however, one of my scripts has the possibility of being run
> regularly, each time it will write to a file.
>
> So my question is, if 2 scripts run at the same split second and get
> around to writing to the same file at the same time what would be the
> result? Would one fail and the other succeed, or would the file be
> damaged maybe (if I was using the above code for example).
>
> Thank you for any advise,
>
> Jon.
------------------------------
Date: Wed, 23 Jul 2003 18:38:42 -0500
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: Correct file handling on Linux
Message-Id: <slrnbhu742.6at.tadmc@magna.augustmail.com>
Jon <jon18_uk2002@yahoo.co.uk> wrote:
> So my question is, if 2 scripts run at the same split second and get
That is known as a "race condition" in computer science lingo.
> around to writing to the same file at the same time what would be the
> result?
Bad, because...
> Would one fail and the other succeed, or would the file be
> damaged maybe (if I was using the above code for example).
... it could be any of those, in general.
> Thank you for any advise,
To avoid corrupting data due to a race condition, you must
implement some form of "file locking" in *each* program
that might write to the common file.
There are several Perl FAQs about file locking:
perldoc -q "\block"
(or put the data in a real RDBMS, and it can do the locking for you)
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Wed, 23 Jul 2003 21:05:01 -0400
From: pa@invalid.invalid (Pierre Asselin)
Subject: Re: Correct file handling on Linux
Message-Id: <tbbnfb.ghk.ln@brick.verano.sba.ca.us>
Jon <jon18_uk2002@yahoo.co.uk> wrote:
> So my question is, if 2 scripts run at the same split second and get
> around to writing to the same file at the same time what would be the
> result?
In general, the file will contain erratic bursts of data both
programs, unless you write the code carefully. For log files, you
should
1) open the file in append mode,
2) use syswrite() exclusively.
open(LOG, '>>the_log_file');
...
syswrite LOG, "Complete, uninterrupted line.\n"
...
close(LOG);
------------------------------
Date: 23 Jul 2003 21:51:09 GMT
From: sholden@flexal.cs.usyd.edu.au (Sam Holden)
Subject: Re: Data::Dumper vs perl -d
Message-Id: <slrnbhu0qd.g1g.sholden@flexal.cs.usyd.edu.au>
On Wed, 23 Jul 2003 17:13:17 GMT, Bill Smith <wksmith@optonline.net> wrote:
> I have noticed that many of the frequent posters recommend Data::Dumper
> for debugging data structure and reference problems. I have always used
> the "x" command in the perl debugger.
>
> The debugger offers several advantages. The original script does not
> have to be temporarily changed. The dump can be limited to critical
> loop iterations. Alternate syntax can often be tested in the debugging
> session.
>
> What advantages of the module approach am I overlooking?
I've found Data::Dumper of great utility when debugging things like CGI
scripts with use reasonably complicated hashes of hashes of hashes of
arrays (or whatever).
Using ther debugger is more hassle than it's worth under CGI, with
Data::Dumper you don't have to worry about replicating the whole CGI
environment correctly.
--
Sam Holden
------------------------------
Date: Wed, 23 Jul 2003 21:54:35 -0500
From: "Eric J. Roode" <REMOVEsdnCAPS@comcast.net>
Subject: Re: Data::Dumper vs perl -d
Message-Id: <Xns93C1E902621F1sdn.comcast@206.127.4.25>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
"Bill Smith" <wksmith@optonline.net> wrote in news:NmzTa.98495$ye5.17561926
@news4.srv.hcvlny.cv.net:
> I have noticed that many of the frequent posters recommend Data::Dumper
> for debugging data structure and reference problems. I have always used
> the "x" command in the perl debugger.
>
> The debugger offers several advantages. The original script does not
> have to be temporarily changed. The dump can be limited to critical
> loop iterations. Alternate syntax can often be tested in the debugging
> session.
>
> What advantages of the module approach am I overlooking?
In a CGI environment, especially a mod_perl or FastCGI environment, it's
next to impossible to use the debugger. (However, the excellent Tk-based
debugger ptkdb can be used in a plain-vanilla CGI environment, and it makes
debugging CGI apps a joy).
When debugging CGI apps, sometimes I'll dump a complex structure to a table
cell or <div> and view it with the page. Or I'll dump it to a log file and
examine it later.
In general, though, I agree with your approach: I frequently use the
standard debugger.
- --
Eric
$_ = reverse sort qw p ekca lre Js reh ts
p, $/.r, map $_.$", qw e p h tona e; print
-----BEGIN xxx SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBPx9KW2PeouIeTNHoEQJL6wCffh483YU0D+Ynr8GFz4v9qXIwL3MAniD8
BVuFGn85nfCSvXrsDgY071Pk
=qnob
-----END PGP SIGNATURE-----
------------------------------
Date: Wed, 23 Jul 2003 21:46:44 GMT
From: Bart Lateur <bart.lateur@pandora.be>
Subject: Re: generalizing cgi handling
Message-Id: <6f0uhvcpg5eej99838j2akg61tofe1i3r3@4ax.com>
Steve in NY wrote:
>On Sat, 19 Jul 2003 21:34:17 -0400, Jeff 'japhy' Pinyan <pinyaj@rpi.edu> wrote:
>
>>Eh, I don't think you want to learn it that way. The CGI.pm module, which
>>is a STANDARD module, does it. Correctly. If you want to learn the right
>>way to do it, study the code from the module, and use the module. Writing
>>it on your own is NOT easy.
>
>Well, I am pretty comfortable with http and the CGI.pm is something like
>6,000 lines of code...so I think that is a good reason to advoid it.
To be honest, CGI.pm is an extremely *ugly* module. If you want to
learn proper coding, *don't* take this module as an example.
You could learn a few tricks from it, once you've got a few years of
Perl coding under your belt, yes...
--
Bart.
------------------------------
Date: Wed, 23 Jul 2003 19:08:38 GMT
From: "John Cugini" <cuzin@adelphia.net>
Subject: how to initialize size of DOS Window?
Message-Id: <W2BTa.36599$8g6.634165@news1.news.adelphia.net>
Running Active Perl on Windows XP: - when I execute a PERL script,
a DOS-style command window is created - but it's always a mere 25 lines
big.... how can I set it to other (larger) sizes.
I set up a simple shortcut to the DOS window and it (the shortcut) has
properties
that let you adjust the window (font, color, size) ... but the executable
itself
(windows/system32/cmd.exe) does not.
Thanks for any tips.
--- John Cugini / cuzin@adelphia.net
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
Date: Wed, 23 Jul 2003 19:48:59 GMT
From: "--Rick" <no_trick@my-de(remove the obvious)ja.com>
Subject: Re: how to initialize size of DOS Window?
Message-Id: <LEBTa.68254$3o3.4576322@bgtnsc05-news.ops.worldnet.att.net>
"John Cugini" <cuzin@adelphia.net> wrote in message
news:W2BTa.36599$8g6.634165@news1.news.adelphia.net...
| Running Active Perl on Windows XP: - when I execute a PERL script,
| a DOS-style command window is created - but it's always a mere 25
lines
| big.... how can I set it to other (larger) sizes.
|
<snip>
|
| --- John Cugini / cuzin@adelphia.net
This worked in a Win98 console (at the > prompt).
c:\windows>mode con lines=50
HTH
--Rick
------------------------------
Date: Thu, 24 Jul 2003 00:40:50 +0000 (UTC)
From: efflandt@xnet.com (David Efflandt)
Subject: Re: IP Conversion..Sending to Subroutine..
Message-Id: <slrnbhuaoh.b9r.efflandt@typhoon.xnet.com>
On Mon, 21 Jul 2003 23:35:33 GMT, Joe <joecool118@nospam.hotmail.com> wrote:
>
> "David Efflandt" <efflandt@xnet.com> wrote in message
> news:slrnbhlejf.t85.efflandt@typhoon.xnet.com...
>> On Sun, 20 Jul 2003 09:45:24 GMT, Joe <joecool118@nospam.hotmail.com>
> wrote:
>> >> On Sat, 19 Jul 2003, Joe Henderson wrote:
>> >>
>> >> >Or does ne1 have a better way...
>> >>
>> >> I don't really know what you're doing, or why you're doing it.
>> >
>> >
>> > Normally this is a whole array of sorting ip's in a file..
>> > .While reading a file of ip's i want to sort then by lowest
>> > to highest then print.. However.. when i do not split them
>> > the values are not correctly push to the sub's.. So.. I tried
>> > to use "big::int" but that did not work.. Any Ideas?
>>
>> This is an example of a script that can sort a file list of full or
>> partial IPs, or insert (optional) single IP from the commandline into the
>> sorted list.
>
> Yes.. Correct
>
>>
>> Simply sorting a unique list of packed IPs and then unpacking them did
>> not work for partial IPs because either 192.168. or 192.168.0. became
>> 192.168.0.0 which would not work for intended purpose. So I put the IPs
>> into a hash with a packed value, and sort on the value string (cmp). Not
>> sure if this is optimized, but it works.
>>
>> The partial IPs (ending with dot) are for class A, B, or C subnets (dot is
>> appended if needed). I did not get into more specific subnet masking yet
>> (more complicated). This demo does not check if IPs are valid and would
>> need added code for multi-user access of same IP list (flock, etc.).
>>
>> #!/usr/bin/perl -w
>> # banip 5/30/2003 by David Efflandt efflandt@xnet.com
>> # Inserts (optional) single full or partial IP from commandline
>> # into file list. List is sorted and duplicates removed.
>> #
>> # set $file to point to your IP list file
>> my $file = "$ENV{HOME}/banlist.txt";
>> my $newip = shift or 0;
>> $newip =~ s/^[^\d\.]+$// if $newip;
> This is a new one..
>> my ($iplist,%hash);
>> if ($_ = $newip) {
>> $newip .= '.' unless (/\.$/ || /\d+\.\d+\.\d+\.\d+/);
>> $hash{$newip} = pack('C4',split(/\./,$newip));
> need to read up on this "pack();"
>> print "using: $file\n";
>> } else {
>> warn "usage: $0 ip_addr\n$file is just being sorted\n";
>> }
>> if (open (IN,"$file")) {
>> while (<IN>) {
>> chomp;
>> $_ .= '.' unless (/\.$/ || /\d+\.\d+\.\d+\.\d+/);
>> $hash{$_} = pack('C4',split(/\./,$_));
>> }
>> close IN;
>> } elsif (!$newip) {
>> die "nothing to do!\n";
>> } else {
>> die "can't read $file: $!\n";
>> }
>> @iplist = sort { $hash{$a} cmp $hash{$b} } keys %hash;
>> open (OUT,"> $file") || die "Can't write $file: $!";
>> foreach (@iplist) {
>> print OUT "$_\n";
> hmm.. wonder what happen to the 2nd-4th octet.. doesn't this just print the
> 1st?
>> }
>> close OUT;
Maybe I should have explained it. The hash keys (name) are the original
IPs (which eats any duplicates). The hash values are the packed (I think
binary coded decimal) equivalent of each IP (typically used to represent
an IP if you get deep into socket programming). It sorts the keys (IPs)
into @iplist based on comparing the packed value. So the last foreach
loop does spit out the sorted list of original IPs (less any duplicates).
--
David Efflandt - All spam ignored http://www.de-srv.com/
http://www.autox.chicago.il.us/ http://www.berniesfloral.net/
http://cgi-help.virtualave.net/ http://hammer.prohosting.com/~cgi-wiz/
------------------------------
Date: 23 Jul 2003 19:56:48 -0700
From: stuseven@hotmail.com (stu7)
Subject: Re: JOIN problem ? (2nd attempt to post)
Message-Id: <d7dd90b0.0307231856.32e04aa@posting.google.com>
Uri Guttman <uri@stemsystems.com> wrote in message news:<x7oeznoyig.fsf@mail.sysarch.com>...
> >>>>> "s" == stu7 <stuseven@hotmail.com> writes:
>
> s> *** ...sets out a bowl of sugar water, to attract more ***
> s> style-spammers
>
> nah, you just made sure no one would help you by your attitude. i don't
> kill file but your posting style makes it easy for me to ignore you. try
> to get help here and you probably will not get it except from the
> newbies or clueless who don't know you yet.
>
> uri
*** Uri... you missed it. I got my answer already.
*** There was no attitude... I asked a simple question, and
*** got a quick answer.
***
*** What I took issue with was the large group of people
*** who waste their time here style-critiquing every legitiamate
*** question that is asked... why should I be friendly
*** toward this unappreciated practice ?
*** You seem divided on whether to support those who ask
*** legitimate questions, or those who choose to harangue them.
***
*** I dont care, really, one way or the other. Im sorry, but
*** your name calling insulting post isnt legitimatized by
*** any responsibilty you feel you might have here.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 5263
***************************************
