[29377] in Perl-Users-Digest
Perl-Users Digest, Issue: 621 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jul 6 14:25:14 2007
Date: Fri, 6 Jul 2007 11:25:00 -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, 6 Jul 2007 Volume: 11 Number: 621
Today's topics:
Re: improvement suggestion for File::Find: pre-parsed e anno4000@radom.zrz.tu-berlin.de
Re: improvement suggestion for File::Find: pre-parsed e <tzz@lifelogs.com>
Re: improvement suggestion for File::Find: pre-parsed e anno4000@radom.zrz.tu-berlin.de
Re: improvement suggestion for File::Find: pre-parsed e <tzz@lifelogs.com>
Re: improvement suggestion for File::Find: pre-parsed e (Randal L. Schwartz)
Re: improvement suggestion for File::Find: pre-parsed e <tzz@lifelogs.com>
Re: improvement suggestion for File::Find: pre-parsed e <blgl@stacken.kth.se>
Re: improvement suggestion for File::Find: pre-parsed e <bik.mido@tiscalinet.it>
Re: improvement suggestion for File::Find: pre-parsed e <joe@inwap.com>
Re: improvement suggestion for File::Find: pre-parsed e <abigail@abigail.be>
Re: improvement suggestion for File::Find: pre-parsed e <tzz@lifelogs.com>
Re: improvement suggestion for File::Find: pre-parsed e <tzz@lifelogs.com>
Re: improvement suggestion for File::Find: pre-parsed e <paduille.4061.mumia.w+nospam@earthlink.net>
In windows, start default app associated with file type <sicsicsic@freesurf.ch>
Re: In windows, start default app associated with file <lambik@kieffer.nl>
Re: In windows, start default app associated with file <sicsicsic@freesurf.ch>
Re: In windows, start default app associated with file <wyzelli@yahoo.com>
Re: IO::Socket::Multicast in limbo? <ThomasKratz@REMOVEwebCAPS.de>
Re: IO::Socket::Multicast in limbo? <rgbingham@gmail.com>
Re: IO::Socket::Multicast in limbo? <ThomasKratz@REMOVEwebCAPS.de>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 4 Jul 2007 09:51:48 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: improvement suggestion for File::Find: pre-parsed extensions
Message-Id: <5f18tkF3alj6gU1@mid.dfncis.de>
Ted Zlatanov <tzz@lifelogs.com> wrote in comp.lang.perl.misc:
> On Tue, 03 Jul 2007 10:26:55 -0700 Paul Lalli <mritty@gmail.com> wrote:
>
> PL> On Jul 3, 11:57 am, Ted Zlatanov <t...@lifelogs.com> wrote:
> >> I think it would be really useful if in addition to $File::Find::name
> >> and $_ there were also $File::Find::namenoext, $_namenoext ($_ without
> >> the extension), and $File::Find::ext (the extension itself).
[...]
> biased. In any case, as I mentioned, File::Find is IO-bound, so doing
> the extra CPU work in the find() function would not harm performance,
> and the extra memory usage is negligible.
You said that before, but have you checked? A run of find() that
calls File::Basename::fileparse() on every file takes twice the time
of one that only visits the files. Doubling the overhead isn't
something I'd do lightly.
Anno
use Benchmark qw( cmpthese);
use File::Find;
use File::Basename;
cmpthese( -1, {
without_base => sub {
find sub {}, '.';
},
with_base => sub {
find sub {
my ($name,$path,$suffix) = fileparse($File::Find::name);
},
'.';
},
});
__END__
Rate with_base without_base
with_base 14.6/s -- -51%
without_base 29.9/s 105% --
------------------------------
Date: Thu, 05 Jul 2007 10:20:23 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: improvement suggestion for File::Find: pre-parsed extensions
Message-Id: <m2zm2b9bko.fsf@lifelogs.com>
On 4 Jul 2007 09:51:48 GMT anno4000@radom.zrz.tu-berlin.de wrote:
a> Ted Zlatanov <tzz@lifelogs.com> wrote in comp.lang.perl.misc:
>> biased. In any case, as I mentioned, File::Find is IO-bound, so doing
>> the extra CPU work in the find() function would not harm performance,
>> and the extra memory usage is negligible.
a> You said that before, but have you checked? A run of find() that
a> calls File::Basename::fileparse() on every file takes twice the time
a> of one that only visits the files. Doubling the overhead isn't
a> something I'd do lightly.
You're right, and I assumed incorrectly.
A simple parse function:
my $suffix = undef;
my $name = $File::Find::name;
my $base = $name;
if ($name =~ m/(.*)\.([^.]+)/)
{
$suffix = $2;
$base = $1;
}
is only 20% slower on a local filesystem, which is better but still not
good. So I would not enable this feature by default, but only when
requested (e.g. through File::Find::find_fullparse() or
$File::Find::fullparse=1 or the require parameters). Would that be
acceptable?
Ted
------------------------------
Date: 5 Jul 2007 16:23:55 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: improvement suggestion for File::Find: pre-parsed extensions
Message-Id: <5f4k8rF3ad9viU1@mid.dfncis.de>
Ted Zlatanov <tzz@lifelogs.com> wrote in comp.lang.perl.misc:
> On 4 Jul 2007 09:51:48 GMT anno4000@radom.zrz.tu-berlin.de wrote:
>
> a> Ted Zlatanov <tzz@lifelogs.com> wrote in comp.lang.perl.misc:
> >> biased. In any case, as I mentioned, File::Find is IO-bound, so doing
> >> the extra CPU work in the find() function would not harm performance,
> >> and the extra memory usage is negligible.
>
> a> You said that before, but have you checked? A run of find() that
> a> calls File::Basename::fileparse() on every file takes twice the time
> a> of one that only visits the files. Doubling the overhead isn't
> a> something I'd do lightly.
>
> You're right, and I assumed incorrectly.
>
> A simple parse function:
>
> my $suffix = undef;
> my $name = $File::Find::name;
> my $base = $name;
> if ($name =~ m/(.*)\.([^.]+)/)
> {
> $suffix = $2;
> $base = $1;
> }
>
> is only 20% slower on a local filesystem, which is better but still not
> good. So I would not enable this feature by default, but only when
> requested (e.g. through File::Find::find_fullparse() or
> $File::Find::fullparse=1 or the require parameters). Would that be
> acceptable?
I believe as an option it would be useful. I think File::Find is
rather portable, so File::Basename would have to be used in order
not to deteriorate it.
Anno
------------------------------
Date: Thu, 05 Jul 2007 13:33:34 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: improvement suggestion for File::Find: pre-parsed extensions
Message-Id: <m2zm2a92mp.fsf@lifelogs.com>
On 5 Jul 2007 16:23:55 GMT anno4000@radom.zrz.tu-berlin.de wrote:
a> Ted Zlatanov <tzz@lifelogs.com> wrote in comp.lang.perl.misc:
>> A simple parse function:
>>
>> my $suffix = undef;
>> my $name = $File::Find::name;
>> my $base = $name;
>> if ($name =~ m/(.*)\.([^.]+)/)
>> {
>> $suffix = $2;
>> $base = $1;
>> }
>>
>> is only 20% slower on a local filesystem, which is better but still not
>> good. So I would not enable this feature by default, but only when
>> requested (e.g. through File::Find::find_fullparse() or
>> $File::Find::fullparse=1 or the require parameters). Would that be
>> acceptable?
a> I believe as an option it would be useful. I think File::Find is
a> rather portable, so File::Basename would have to be used in order
a> not to deteriorate it.
Sure. I didn't mean my parse function should be used, only that it
wasn't fast enough either, so I was completely wrong on the IO-bound
assumption :)
This makes it 2 votes for, 2 against a patch that a) uses
File::Basename, b) pulls the functionality in only when requested.
Anyone else?
Here's a simple outline of the usage I would want:
use File::Find;
$File::Find::extparse = 1;
find(
sub
{
printf ("%s has full name %s, extension %s, and full name without extension %s\n",
$_, $File::Find::name, $File::Find::ext, $File::Find::name_noext);
}, @search);
I think $_ without the extension wouldn't be very useful, and would
require another fileparse() invocation.
Ted
------------------------------
Date: Thu, 05 Jul 2007 12:02:24 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: improvement suggestion for File::Find: pre-parsed extensions
Message-Id: <86abuan073.fsf@blue.stonehenge.com>
>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:
Ted> I think it would be really useful if in addition to $File::Find::name
Ted> and $_ there were also $File::Find::namenoext, $_namenoext ($_ without
Ted> the extension), and $File::Find::ext (the extension itself). On most
Ted> OSs it should be true that
Ted> $File::Find::namenoext . '.' . $File::Find::ext eq $File::Find::name
Ted> $_namenoext . '.' . $File::Find::ext eq $_
My problem with this is that Unix doesn't have "extension" as a fundamental
concept, and Perl is basically a "happiest with Unix" tool.
Unix is perfectly fine with a file named "foo" or "foo.bar.bletch". Of those
two, what would you call the "extension"?
This isn't Windows.
print "Just another Perl hacker,"; # the original!
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
--
Posted via a free Usenet account from http://www.teranews.com
------------------------------
Date: Thu, 05 Jul 2007 16:00:29 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: improvement suggestion for File::Find: pre-parsed extensions
Message-Id: <m2ir8y8vtu.fsf@lifelogs.com>
On Thu, 05 Jul 2007 12:02:24 -0700 merlyn@stonehenge.com (Randal L. Schwartz) wrote:
>>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:
Ted> I think it would be really useful if in addition to $File::Find::name
Ted> and $_ there were also $File::Find::namenoext, $_namenoext ($_ without
Ted> the extension), and $File::Find::ext (the extension itself). On most
Ted> OSs it should be true that
Ted> $File::Find::namenoext . '.' . $File::Find::ext eq $File::Find::name
Ted> $_namenoext . '.' . $File::Find::ext eq $_
RLS> My problem with this is that Unix doesn't have "extension" as a fundamental
RLS> concept, and Perl is basically a "happiest with Unix" tool.
RLS> Unix is perfectly fine with a file named "foo" or "foo.bar.bletch". Of those
RLS> two, what would you call the "extension"?
1) '' according to File::Basename (undef would also work)
2) bletch
RLS> This isn't Windows.
File::Basename runs everywhere and understands extensions (it calls them
suffixes).
Lots of software looks at file extensions. GNU Make and Emacs, for
example. Let's not forget Perl uses .pm for modules.
I really don't think this is a Windows-only concept.
Ted
------------------------------
Date: Fri, 06 Jul 2007 10:37:22 +0200
From: Bo Lindbergh <blgl@stacken.kth.se>
Subject: Re: improvement suggestion for File::Find: pre-parsed extensions
Message-Id: <f6kv02$bif$1@news.su.se>
I'd say the right way to improve File::Find is to write an object-oriented
replacement that uses no global variables at all.
/Bo Lindbergh
------------------------------
Date: Fri, 06 Jul 2007 11:05:24 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: improvement suggestion for File::Find: pre-parsed extensions
Message-Id: <471s83hrd9993t79212td4uakfi9fb6pe2@4ax.com>
On Fri, 06 Jul 2007 10:37:22 +0200, Bo Lindbergh <blgl@stacken.kth.se>
wrote:
>I'd say the right way to improve File::Find is to write an object-oriented
>replacement that uses no global variables at all.
Which is what I was suggesting in another post. But do we really need
another F::F's son when there already exist File::Finder and
File::Find::Rule?
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Fri, 06 Jul 2007 02:52:42 -0700
From: Joe Smith <joe@inwap.com>
Subject: Re: improvement suggestion for File::Find: pre-parsed extensions
Message-Id: <B8ednUUtZtVsjRPbnZ2dnUVZ_g-dnZ2d@comcast.com>
Ted Zlatanov wrote:
> On Thu, 05 Jul 2007 12:02:24 -0700 merlyn@stonehenge.com (Randal L. Schwartz) wrote:
> RLS> This isn't Windows.
>
> File::Basename runs everywhere and understands extensions (it calls them
> suffixes).
If you actually look at File::Basename and its definition of suffix,
you will see that is does _not_ use '.' for that purpose. It has no
preconceived notion as to what character signifies the beginning of
a suffix. You, the programmer, have to explicitly provide that information.
Hardcoding '.' as the separator character is not good.
-Joe
------------------------------
Date: 06 Jul 2007 11:09:14 GMT
From: Abigail <abigail@abigail.be>
Subject: Re: improvement suggestion for File::Find: pre-parsed extensions
Message-Id: <slrnf8s8mq.1a4.abigail@alexandra.abigail.be>
_
Ted Zlatanov (tzz@lifelogs.com) wrote on VLVI September MCMXCIII in
<URL:news:m2ir8y8vtu.fsf@lifelogs.com>:
__ On Thu, 05 Jul 2007 12:02:24 -0700 merlyn@stonehenge.com (Randal L. Schwartz) wrote:
__
__
__ RLS> This isn't Windows.
__
__ File::Basename runs everywhere and understands extensions (it calls them
__ suffixes).
__
__ Lots of software looks at file extensions. GNU Make and Emacs, for
__ example. Let's not forget Perl uses .pm for modules.
No they don't.
The software you mention looks for patterns in filenames - patterns
that may resemble how "extensions" look like on certain operating
systems. The operating system itself (assuming it's Unix) doesn't care.
And it's not that you cannot have a module in a file that doesn't
end in '.pm'. Such patterns may be called 'suffixes', but they aren't
'extensions'.
__ I really don't think this is a Windows-only concept.
Perhaps not. But it doesn't exist in the Unix world.
Abigail
--
sub _ {$_ = shift and y/b-yB-Y/a-yB-Y/ xor !@ _?
exit print :
print and push @_ => shift and goto &{(caller (0)) [3]}}
split // => "KsvQtbuf fbsodpmu\ni flsI " xor & _
------------------------------
Date: Fri, 06 Jul 2007 12:21:12 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: improvement suggestion for File::Find: pre-parsed extensions
Message-Id: <m28x9t7bbb.fsf@lifelogs.com>
On 06 Jul 2007 11:09:14 GMT Abigail <abigail@abigail.be> wrote:
A> Ted Zlatanov (tzz@lifelogs.com) wrote on VLVI September MCMXCIII in
A> <URL:news:m2ir8y8vtu.fsf@lifelogs.com>:
A> __ On Thu, 05 Jul 2007 12:02:24 -0700 merlyn@stonehenge.com (Randal L. Schwartz) wrote:
A> __
A> __
A> __ RLS> This isn't Windows.
A> __
A> __ File::Basename runs everywhere and understands extensions (it calls them
A> __ suffixes).
A> __
A> __ Lots of software looks at file extensions. GNU Make and Emacs, for
A> __ example. Let's not forget Perl uses .pm for modules.
A> No they don't.
A> The software you mention looks for patterns in filenames - patterns
A> that may resemble how "extensions" look like on certain operating
A> systems. The operating system itself (assuming it's Unix) doesn't care.
A> And it's not that you cannot have a module in a file that doesn't
A> end in '.pm'. Such patterns may be called 'suffixes', but they aren't
A> 'extensions'.
I really don't feel like arguing over semantics and what "Unix" cares
about. My goal is to improve the user experience. Let's agree
applications often care about what follows the last dot, and therefore
this suffix or extension or whatever you want to call it is a useful
concept that users often need to manage files. I know about magic
numbers and MIME types and so on, and my proposal doesn't concern any of
that.
The core File::Basename module obviously implements that idea as a
"suffix" and I think it would be nice to the end user of File::Find to
*optionally* provide a suffix for the currently visited file through
already existing File::Basename functionality. That's all.
Ted
------------------------------
Date: Fri, 06 Jul 2007 12:30:59 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: improvement suggestion for File::Find: pre-parsed extensions
Message-Id: <m24pkh7av0.fsf@lifelogs.com>
On Fri, 06 Jul 2007 02:52:42 -0700 Joe Smith <joe@inwap.com> wrote:
JS> Ted Zlatanov wrote:
>> On Thu, 05 Jul 2007 12:02:24 -0700 merlyn@stonehenge.com (Randal
>> L. Schwartz) wrote: RLS> This isn't Windows.
>>
>> File::Basename runs everywhere and understands extensions (it calls them
>> suffixes).
JS> If you actually look at File::Basename and its definition of suffix,
JS> you will see that is does _not_ use '.' for that purpose. It has no
JS> preconceived notion as to what character signifies the beginning of
JS> a suffix. You, the programmer, have to explicitly provide that information.
JS> Hardcoding '.' as the separator character is not good.
Practically speaking, I simply don't care what the separator character
is. I want the last suffix; on Windows, all Unices I know, and MacOS X
that suffix follows the last dot *by convention*. There's no
platform-neutral suffix separator, so let's use '.' and be done with it
for the sake of at least 95% of the installed Perl base.
Ted
------------------------------
Date: Fri, 06 Jul 2007 18:04:11 GMT
From: "Mumia W." <paduille.4061.mumia.w+nospam@earthlink.net>
Subject: Re: improvement suggestion for File::Find: pre-parsed extensions
Message-Id: <vuvji.5206$zA4.2582@newsread3.news.pas.earthlink.net>
On 07/06/2007 11:21 AM, Ted Zlatanov wrote:
>
> I really don't feel like arguing over semantics and what "Unix" cares
> about. My goal is to improve the user experience. Let's agree
> applications often care about what follows the last dot, and therefore
> this suffix or extension or whatever you want to call it is a useful
> concept that users often need to manage files. I know about magic
> numbers and MIME types and so on, and my proposal doesn't concern any of
> that.
>
> The core File::Basename module obviously implements that idea as a
> "suffix" and I think it would be nice to the end user of File::Find to
> *optionally* provide a suffix for the currently visited file through
> already existing File::Basename functionality. That's all.
>
> Ted
I vote no. Explicit support for parsing "suffixes" is not needed in
File::Find, and the user can improve his or her experience by writing a
nominal amount of code.
If someone deems that writing that code is too much work, he or she can
create a new module and place it on CPAN.
------------------------------
Date: Fri, 06 Jul 2007 10:56:40 +0200
From: Philipp <sicsicsic@freesurf.ch>
Subject: In windows, start default app associated with file type
Message-Id: <1183712192_504@sicinfo3.epfl.ch>
Hello
From my perl script on windows I want to start the default viewer for
pdf files.
Is there an easy way of doing programatically what the OS does when you
double-click on file with a certain type?
ie.
1) get file type
2) find associated app
3) start app with file as argument
Thanks
Phil
------------------------------
Date: Fri, 6 Jul 2007 11:08:26 +0200
From: "Lambik" <lambik@kieffer.nl>
Subject: Re: In windows, start default app associated with file type
Message-Id: <468e0635$0$37719$5fc3050@dreader2.news.tiscali.nl>
"Philipp" <sicsicsic@freesurf.ch> wrote in message
news:1183712192_504@sicinfo3.epfl.ch...
> Hello
> From my perl script on windows I want to start the default viewer for
> pdf files.
> Is there an easy way of doing programatically what the OS does when you
> double-click on file with a certain type?
> ie.
> 1) get file type
> 2) find associated app
> 3) start app with file as argument
>
exec "rundll32.exe url.dll, FileProtocolHandler my.pdf "
------------------------------
Date: Fri, 06 Jul 2007 11:23:38 +0200
From: Philipp <sicsicsic@freesurf.ch>
Subject: Re: In windows, start default app associated with file type
Message-Id: <1183713809_510@sicinfo3.epfl.ch>
Lambik a écrit :
> "Philipp" <sicsicsic@freesurf.ch> wrote in message
> news:1183712192_504@sicinfo3.epfl.ch...
>> Hello
>> From my perl script on windows I want to start the default viewer for
>> pdf files.
>> Is there an easy way of doing programatically what the OS does when you
>> double-click on file with a certain type?
>> ie.
>> 1) get file type
>> 2) find associated app
>> 3) start app with file as argument
>>
> exec "rundll32.exe url.dll, FileProtocolHandler my.pdf "
Thanks :-)
------------------------------
Date: Fri, 06 Jul 2007 11:02:49 GMT
From: "Peter Wyzl" <wyzelli@yahoo.com>
Subject: Re: In windows, start default app associated with file type
Message-Id: <tjpji.3968$4A1.1307@news-server.bigpond.net.au>
"Philipp" <sicsicsic@freesurf.ch> wrote in message
news:1183712192_504@sicinfo3.epfl.ch...
> Hello
> From my perl script on windows I want to start the default viewer for pdf
> files.
> Is there an easy way of doing programatically what the OS does when you
> double-click on file with a certain type?
> ie.
> 1) get file type
> 2) find associated app
> 3) start app with file as argument
Let the OS handle that...
exec 'start myfile.pdf';
P
------------------------------
Date: Thu, 05 Jul 2007 18:51:24 +0200
From: Thomas Kratz <ThomasKratz@REMOVEwebCAPS.de>
Subject: Re: IO::Socket::Multicast in limbo?
Message-Id: <468d218b$0$2583$bb690d87@news.main-rheiner.de>
RayB wrote:
> #!/usr/bin/perl
> $|=1;
> use IO::Socket;
> use IO::Socket::Multicast;
> my $port = 1118;
> my $addr = '225.1.1.1';
> my $sock = IO::Socket::Multicast->new('LocalPort' => $port) or die
> "Can't create socket:$!";
>
> print $sock->mcast_if; //value is set to "any" by default
>
> $sock->mcast_if("eth1");
perldoc IO::Socket::Multicast says
$sock->mcast_if is for *outgoing* multicasts.
> $sock->mcast_add($addr) or die "mcast_add: $!";
$sock->mcast_add($addr, 'eth1') or die "mcast_add: $!";
>
> while (1) {
> my ($msg, $peer);
> die "recv error: $!" unless $peer = recv($sock, $msg, 1024, 0); //it
> hangs here...
> my ($port, $peeraddr) = sockaddr_in($peer);
> print inet_ntoa($peeraddr) . ":" . inet_ntoa($portaddr) . ": $msg\n";
print inet_ntoa($peeraddr) . ":" . $port . ": $msg\n";
you didn't have $portaddr. Please post code that is strict compliant.
apart from getting it to compile your script runs fine here
(WinXP, perl 5.8.8, ISM 1.04), with a simple multicast sender
from the local machine like this:
use strict;
use warnings;
use IO::Socket::Multicast;
my $s = IO::Socket::Multicast->new() or die $!;
for ( 1..100 ) {
$s->mcast_send($_ x 100, '225.1.1.1:1118');
sleep(1);
}
Thomas
--
$/=$,,$_=<DATA>,s,(.*),$1,see;__END__
s,^(.*\043),,mg,@_=map{[split'']}split;{#>J~.>_an~>>e~......>r~
$_=$_[$%][$"];y,<~>^,-++-,?{$/=--$|?'"':#..u.t.^.o.P.r.>ha~.e..
'%',s,(.),\$$/$1=1,,$;=$_}:/\w/?{y,_, ,,#..>s^~ht<._..._..c....
print}:y,.,,||last,,,,,,$_=$;;eval,redo}#.....>.e.r^.>l^..>k^.-
------------------------------
Date: Thu, 05 Jul 2007 21:37:22 -0000
From: RayB <rgbingham@gmail.com>
Subject: Re: IO::Socket::Multicast in limbo?
Message-Id: <1183671442.636367.108290@g37g2000prf.googlegroups.com>
On Jul 5, 9:51 am, Thomas Kratz <ThomasKr...@REMOVEwebCAPS.de> wrote:
> RayB wrote:
> perldoc IO::Socket::Multicast says
> $sock->mcast_if is for *outgoing* multicasts.
> > $sock->mcast_add($addr) or die "mcast_add: $!";
> $sock->mcast_add($addr, 'eth1') or die "mcast_add: $!";
Heh. Thanks Thomas for the correction. Now that it's pointed out to
me, I don't see how I could've missed it. :)
[snip]
> print inet_ntoa($peeraddr) . ":" . $port . ": $msg\n";
> you didn't have $portaddr. Please post code that is strict compliant.
Thanks again. I've never gotten the script past the recv, hence
everything after that line was... well... untested. :)
I've added your suggested changes, but unfortunately it continues to
hand on that same spot.
I'm curious why Ethereal receives the packet, but my script can't. I'm
curious if Perl is reliant upon some feature of the IP stack or OS
that I just don't know about (being a TCP/IP and Linux (FC-3) newbie),
or if there's some configuration somewhere I need to tweak or some
flag in the config that is different on my OS. I know ethereal uses
Pcap stuff, and I see terms like "promiscuous mode" that I don't know
if they're necessary for my script to engage in order to see it, or if
there's something else I'm missing.
Anyhow thanks for the pointers thusfar. Little by little it'll come,
so thanks for taking the time to respond.
Best regards,
--Ray
------------------------------
Date: Fri, 06 Jul 2007 08:44:31 +0200
From: Thomas Kratz <ThomasKratz@REMOVEwebCAPS.de>
Subject: Re: IO::Socket::Multicast in limbo?
Message-Id: <468de4ce$0$2591$bb690d87@news.main-rheiner.de>
RayB wrote:
> I've added your suggested changes, but unfortunately it continues to
> hand on that same spot.
Did you try to use my posted send script to test the multicasts locally?
If yes, I would bet on some OS issue. Do you have anything else on your
machine that is successfully receiving multicasts?
I'm not a Linux hack but you could check:
http://www.yolinux.com/TUTORIALS/LinuxTutorialNetworking.html#MULTICAST
Thomas
--
$/=$,,$_=<DATA>,s,(.*),$1,see;__END__
s,^(.*\043),,mg,@_=map{[split'']}split;{#>J~.>_an~>>e~......>r~
$_=$_[$%][$"];y,<~>^,-++-,?{$/=--$|?'"':#..u.t.^.o.P.r.>ha~.e..
'%',s,(.),\$$/$1=1,,$;=$_}:/\w/?{y,_, ,,#..>s^~ht<._..._..c....
print}:y,.,,||last,,,,,,$_=$;;eval,redo}#.....>.e.r^.>l^..>k^.-
------------------------------
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 621
**************************************
