[29631] in Perl-Users-Digest
Perl-Users Digest, Issue: 875 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Sep 22 21:10:15 2007
Date: Sat, 22 Sep 2007 18: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 Sat, 22 Sep 2007 Volume: 11 Number: 875
Today's topics:
Re: Concatenation: $i.$j different from "$i$j" <rvtol+news@isolution.nl>
Fashion Footwear Industrial Co.,Ltd(Fujian,CHINA) www.f fashion-sky@hotmail.com
map mystery <Occidental@comcast.net>
Re: map mystery xhoster@gmail.com
perlipc bidirectional unix domain socket <elvis-85363@notatla.org.uk>
Re: perlipc bidirectional unix domain socket <mjp-nntp@pilcrow.madison.wi.us>
Re: perlipc bidirectional unix domain socket <elvis-85363@notatla.org.uk>
Re: perlipc bidirectional unix domain socket <ben@morrow.me.uk>
Re: re-launch piped external program <rihad@mail.ru>
Re: re-launch piped external program <Peter@PSDT.com>
Re: re-launch piped external program <mgjv@tradingpost.com.au>
Re: re-launch piped external program <rihad@mail.ru>
why do these snippets have different behavior? <please_no_more@spam.net>
Re: why do these snippets have different behavior? <eric-amick@comcast.net>
Re: why do these snippets have different behavior? <please_no_more@spam.net>
Re: why do these snippets have different behavior? <bill@ts1000.us>
Re: why do these snippets have different behavior? <allergic-to-spam@no-spam-allowed.org>
Re: why do these snippets have different behavior? <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 22 Sep 2007 13:07:47 +0200
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: Concatenation: $i.$j different from "$i$j"
Message-Id: <fd3464.1bk.1@news.isolution.nl>
Abigail schreef:
> Dr.Ruud:
>> Occidental:
>>> if ("$i$j" =~ /X/)
>>> if ($i.$j =~ /X/)
>>
>> I heard somewhere that the next version of Python will make
>>
>> 1+2 * 3
>>
>> behave differently from
>>
>> 1 + 2*3
>
> If you had written 'Perl6' instead of 'Python', I would have assumed
> you were serieus.
Hey, I was just aiming for a bigger publiek.
--
Affijn, Ruud (actually likes Perl6)
"Gewoon is een tijger."
------------------------------
Date: Sat, 22 Sep 2007 09:44:25 -0700
From: fashion-sky@hotmail.com
Subject: Fashion Footwear Industrial Co.,Ltd(Fujian,CHINA) www.fashion-sky.com
Message-Id: <1190479465.703732.37320@g4g2000hsf.googlegroups.com>
Dear my friend
It is our pleasure to meet you here.
we are wholesaler sport shoes,clothing,electrons in Fujian of China.
our website: http://www.fashion-sky.com
We are professional and honest wholesaler of all kinds of brand
sneaks and apparel.the products
our company supply are as follows:
1).Nike Jordans
Jordan 1 jordan 1.5 jordan 2 jordan 3 jordan 3.5 jordan 4 jordan 5
jordan 5.5 jordan 6 jordan 6.5 jordan 7 jordan 8 jordan 9 jordan 9.5
jordan 10 jordan 11 jordan 12 jordan 13 jordan 13.5 jordan 14 jordan
15 jordan 16 jordan 17 jordan 18 jordan 18.5 jordan 19 jordan 20
jordan 21 jordan 21.5 jordan 22 jordan King jordan Dub Zero Jordan 23
Jordan 7.5
2).Air Force One Air Force one (low) Air Force one (High) Air Force
one (Mid) Air Force one (clear) Air Force One 25 year
3).SHOX Shox R3 Shox R4 Shox R5 Shox TL1 Shox TL2 Shox TL3 Shox NZ
Shox OZ Shox Turbo Show GO Shox CL Shox Coqnescenti Shox Energia Shox
Explodine Shox Monster Shox Rhythmic Shox Warrior
4).Bape Shoes Bape Bape (transparent)
5).Air max AirMax 90 AirMax 95 AirMax 97 AirMax 2003 AirMax 2004
AirMax 2005 Air Max 2006 AirMax 180 AirMax LTD AirMax TN AirMax solas
AirMax 87 AirMax Rift
6).Puma Puma Rpt2 Puma SK6 Puma Jayfi Puma Cir Puma Speed Puma Repli
Puma Future Cat Puma Mostro Puma Lifestyle
7).Dunk SB Dunk High Dunk Low
8).Timberland Timberland High Timberland Low
9).Adidas Adidas 35 Adicolor Country city sense Adidas NBA
11).Prada & Gucci Prada Gucci
12).Footballer Shoes Footballer
13).Locaste
14).converse & Reebok converse Reebok
15).D&G shoes
16).Dsquared2 shoes
17).James shoes
18).Nike King
9).Children shoes Jordan Shox
20).Women shoes Women Jordans Women Shox R3 Women Shox R4 Women AirMax
95&97 Women AirMax 03&06 Women Dunk Women Shox NZ Women AF1
21).sandal & baboosh Nike Puma Gucci Prada
CLOTHES 1).Bape 2).ED Hardy 3).BBC 4).CLH 5).LRG 6).Artful Dodger
Hoodies 7).GINO GREEN GLOBAL 8).10 Deep 9).A&F Coat 11).Jersey NBA
Jersey Football Jersey 12).Juicy Bikini 13).Adidas Coat 14).F1 Coat
15).D&G Coat 16).Superman Coat 17).NBA Coat
JEAN 1).E&D Jeans 2).BBC Jeans 3).BAPE Jeans 4).D&G Jeans 5).EVSIU
Jeans 6).Red monkey 7).COOGI Jeans
T-shirt 1).POLO 2007 polo(women) 2007 POLO IIII(Men) POLO (stripe)
polo (small )
2).Lacoste Lacoste (LONG) Lacoste (SHORT) 3).Name Brand shirt D&G
Shirt Giorgio Armani TN Shirt 4).BBC T-shirt 5).LRG & gina green
glalal 6).Triumvir 7).ED handy 8).Evsiu 9).R.M.B 10).CLOT
Burse & Handbag 1).LV Bag 2).Gucci Bag 3).Dior Bag 4).Chanel Bag
5).Fendi Bag 6).Coach Bag 7).Burberrys Bag 8).Prada Bag 9).Man Leisure
Bag 11).D&G bag 12).nike bag 13).Wallet 14).Suitcase
Electronics 1).Vertu Mobile 2).New iphone Mobile 3).Nokia Mobile
4).moto Mobile 5).PSP Game & memory card 6).Sony Mobile 7).Samsung
Mobile 8).Ipod nano 9).Sony PS3 10).Laptops IBM laptops DELL laptops
Sony laptops ASUS laptops
CAP 1).ED Hardy Cap 2).New Bape & NY Cap 3).RMC Cap 4).New era NBA
5).F1 6).Chanel 7).D&G 8).gucci 9).LV 10).Prada 11).PUMA 12).wool
WATCH 1).Rolex 2).Omega 3).Cartier 4).Chanel 5).Piaget 6).Breitling
7).Bvlgari 8).Corum
Sunglasses 1).Gucci Sunglasses 2).D&G Sunglasses 3).Dior Sunglasses
4).LV Sunglasses 5).Chanel Sunglasses 6).Prada Sunglasses 7).Versace
Sunglasses 8).Giorgio Armani
Strap 1).Bape Strap 2).D&G Strap 3).Gucci Strap 4).LV Strap 5).Scarf
Other 1).Lighter
size chart
Men Size:
US: 7 8 8.5 9 9.5 10 10.5 11 11.5 12 13 14 15
UK: 6 7 7.5 8 8.5 9 9.5 10 10.5 11 12 13 14
EUR: 40 41 42 42.5 43 44 44.5 45 45.5 46 47.5 48 49
Women Size:
US: 5 5.5 6 6.5 7 7.5 8 8.5
UK: 2.5 3 3.5 4 4.5 5 5.5 6
EUR: 35.5 36 36.5 37.5 38 38.5 39 40
Kid's
US: 1 2 3 4 5 6 7 7.5 8 8.5 9 9.5 10 10.5 11 11.5 12 12.5 13 13.5
UK: 13 1 2 3 4 5 6 6.5 7 7.5 8 8.5 9 9.5 10 10.5 11 11.5 12 12.5
EUR:17 18 19 20 21 22 23 24 24.5 25 25.5 26 26.5 27 27.5 28 29 30 30.5
31
Clothing Size:
S M L XL XXL XXXL XXXXL XXXXXL
7.because the space of the website is limited,we can also supply many
other products which be not showed out in our site. if you have the
photos of the products you need , we are pleasure to supply for your
orders.
And our company can supply for our customers ,as follow:
1. top quality.all our products have top quality.
2. most rational price. we offer the most competitive price to you to
open your market. So today most of our products have sold well in the
America, Europe, Middle East, Southeast Asia etc..
3. safe and fast shipment. As different country you are in, we will
deliver the products to you by different ways and pledge to arrive to
your address 100%.and we will send the products to you within 24h
after we get your payment.
4.many products in stock. We have many products in stock and kinds of
size you need , also include kid's.
5.our credit. If the products can be not delivered to your address as
our reason, we will refund the money you paid.
Hope sincerely to have glad and long term business relationship with
you.
If you are interested in our products and have any problem, welcome
to
contact us.
Please trust us , we will be your best choice !!!
Website : http://www.fashion-sky.com
MSN and E-mail: fashion-sky@hotmail.com
Yahoo ID:mallinchina@yahoo.com.cn
Michael
Fashion Footwear Industrial Co.,Ltd.(Fujian,CHINA)
------------------------------
Date: Sat, 22 Sep 2007 17:22:04 -0700
From: Occidental <Occidental@comcast.net>
Subject: map mystery
Message-Id: <1190506924.880072.214930@w3g2000hsg.googlegroups.com>
my @A = qw/one two three/;
print "A: ";
print join " ", @A;
print "\n";
my @A1 = map (ucfirst, @A);
print "A1: ";
print join " ", @A1;
print "\n";
my @A2 = map (reverse, @A);
print "A2: ";
print join " ", @A2;
print "\n";
my $y = reverse "one";
print "y: $y\n";
===============================================
gives:
A: one two three
A1: One Two Three
A2:
y: eno
===============================================
The first map operation works, and reverse works on a scalar, but the
array A2 is empty. Anyone know why?
------------------------------
Date: 23 Sep 2007 00:33:25 GMT
From: xhoster@gmail.com
Subject: Re: map mystery
Message-Id: <20070922203328.705$fa@newsreader.com>
Occidental <Occidental@comcast.net> wrote:
> my @A = qw/one two three/;
>
> print "A: ";
> print join " ", @A;
> print "\n";
>
> my @A1 = map (ucfirst, @A);
> print "A1: ";
> print join " ", @A1;
> print "\n";
>
> my @A2 = map (reverse, @A);
You are reversing the empty list, which of course just gives the empty
list. The concatenation of a bunch of empty lists is still an empty list.
The reverse only operates on $_ implicitly when it is in a scalar context,
while map invokes its thingy in a list context. So put it into scalar
context explicitly:
my @A2 = map scalar reverse, @A;
--
-------------------- 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: 22 Sep 2007 13:47:07 GMT
From: all mail refused <elvis-85363@notatla.org.uk>
Subject: perlipc bidirectional unix domain socket
Message-Id: <slrnffa6hd.b9c.elvis-85363@notatla.org.uk>
I've been trying to put bidirectional traffic through a
local domain (aka Unix domain) socket by adapting code
from "man perlipc" as seen at
http://perl.active-venture.com/pod/perlipc-sockets.html
where the local stuff comes near the end of the page.
The original code works unidirectional - i.e. the client
reads something from the server but after making what look
to me like suitable changes I've been unable to get the server
to obtain the request from the client. I see the original
server opens STDIN from <&Client but doesn't use it.
I've also simplified it by taking the multithread stuff
out of the server. Tested so far on Linux but aiming to
go on multiple Unix versions.
Can someone show me where I'm falling down?
Client
======
#!/usr/bin/perl -w
use Socket;
use strict;
my ($rendezvous, $line);
$rendezvous = shift || 'catsock';
socket(SOCK, PF_UNIX, SOCK_STREAM, 0) or die();
connect(SOCK, sockaddr_un($rendezvous)) or die();
printf(SOCK "Request something\n");
shutdown(SOCK,1); # finished writing
$line = <SOCK>;
print $line;
exit;
Server
======
#!/usr/bin/perl -Tw
use strict;
use sigtrap;
use Socket;
use Carp;
BEGIN {%ENV=('PATH'=>'/usr/ucb:/bin')}
sub spawn; # forward declaration
sub logmsg { print "$0 $$: @_ at ", scalar localtime, "\n" }
my $NAME = 'catsock';
my $uaddr = sockaddr_un($NAME);
my $proto = getprotobyname('tcp');
socket(Server,PF_UNIX,SOCK_STREAM,0) or die();
unlink($NAME);
bind(Server, $uaddr) or die();
listen(Server,SOMAXCONN) or die();
logmsg "server started on $NAME";
accept(Client,Server) or die("accept $!");
# Is Client now bidirectional?
logmsg "connection on $NAME";
spawn sub {
my $input=shift;
printf("(%s): Reply=XXXX\n", $input);
};
sub spawn {
my $coderef = shift;
my $input;
unless (@_ == 0 && $coderef && ref($coderef) eq 'CODE') {
confess "usage: spawn CODEREF";
}
close(STDIN);
open(STDIN, "<&Client") or die("open STDIN $!");
# lsof here shows we do have fd0 dup from one of the previous fds
open(STDOUT, ">&Client") or die("open STDOUT $!");
$input=<STDIN>;
$input="sample" unless (defined($input));
chomp($input);
printf(STDERR "Now executing coderef(%s)...\n", $input);
exit &$coderef($input);
}
--
Elvis Notargiacomo master AT barefaced DOT cheek
http://www.notatla.org.uk/goen/
------------------------------
Date: Sat, 22 Sep 2007 21:22:48 GMT
From: Mike Pomraning <mjp-nntp@pilcrow.madison.wi.us>
Subject: Re: perlipc bidirectional unix domain socket
Message-Id: <IIfJi.38663$G23.18526@newsreading01.news.tds.net>
all mail refused wrote:
> I've been trying to put bidirectional traffic through a
> local domain (aka Unix domain) socket by adapting code
> from "man perlipc" as seen at
> http://perl.active-venture.com/pod/perlipc-sockets.html
> where the local stuff comes near the end of the page.
>
> The original code works unidirectional - i.e. the client
> reads something from the server but after making what look
> to me like suitable changes I've been unable to get the server
> to obtain the request from the client. I see the original
> server opens STDIN from <&Client but doesn't use it.
>
> I've also simplified it by taking the multithread stuff
> out of the server. Tested so far on Linux but aiming to
> go on multiple Unix versions.
Your sample code seems to work for me without modification:
shhhh$ perl -T server.pl & sleep 2 && perl client.pl
[1] 18983
Name "main::Client" used only once: possible typo at server.pl line 22.
server.pl 18983: server started on catsock at Sat Sep 22 16:10:52 2007
server.pl 18983: connection on catsock at Sat Sep 22 16:10:54 2007
Now executing coderef(sample)...
(sample): Reply=XXXX
[1]+ Exit 1 perl -T server.pl
> Can someone show me where I'm falling down?
Can you tell us what specific behavior you are observing, and how it
differs from what you expected?
Regards,
Mik
------------------------------
Date: 22 Sep 2007 23:58:01 GMT
From: all mail refused <elvis-85363@notatla.org.uk>
Subject: Re: perlipc bidirectional unix domain socket
Message-Id: <slrnffbasl.fu8.elvis-85363@notatla.org.uk>
On 2007-09-22, Mike Pomraning <mjp-nntp@pilcrow.madison.wi.us> wrote:
> all mail refused wrote:
>> I've been trying to put bidirectional traffic through a
>> local domain (aka Unix domain) socket by adapting code
>> from "man perlipc" as seen at
>> http://perl.active-venture.com/pod/perlipc-sockets.html
>> where the local stuff comes near the end of the page.
> Your sample code seems to work for me without modification:
>
> Can you tell us what specific behavior you are observing, and how it
> differs from what you expected?
I'm getting the same behaviour as you, but that is not what I call working.
The client is supposed to send "Request something\n" through the
socket where the server should read it on STDIN into the variable
$input. Instead $input is undefined after the read and so replaced
by "sample".
"(Request something): Reply=XXXX" was the hoped-for output from the client.
--
Elvis Notargiacomo master AT barefaced DOT cheek
http://www.notatla.org.uk/goen/
------------------------------
Date: Sun, 23 Sep 2007 01:11:41 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: perlipc bidirectional unix domain socket
Message-Id: <tings4-cr7.ln1@osiris.mauzo.dyndns.org>
Quoth all mail refused <elvis-85363@notatla.org.uk>:
> I've been trying to put bidirectional traffic through a
> local domain (aka Unix domain) socket by adapting code
> from "man perlipc" as seen at
> http://perl.active-venture.com/pod/perlipc-sockets.html
> where the local stuff comes near the end of the page.
>
> The original code works unidirectional - i.e. the client
> reads something from the server but after making what look
> to me like suitable changes I've been unable to get the server
> to obtain the request from the client. I see the original
> server opens STDIN from <&Client but doesn't use it.
>
> I've also simplified it by taking the multithread stuff
> out of the server. Tested so far on Linux but aiming to
> go on multiple Unix versions.
>
> Can someone show me where I'm falling down?
(I realise this is mostly copied from the perldoc: the style of the code
is rather out-of-date, and they should probably be updated.)
> Client
> ======
>
> #!/usr/bin/perl -w
use warnings;
is better than -w.
> use Socket;
It's usually easier to use IO::Socket than the raw socket calls.
> use strict;
> my ($rendezvous, $line);
It's better not to declare variables until you need them. Perl is not C
:).
> $rendezvous = shift || 'catsock';
> socket(SOCK, PF_UNIX, SOCK_STREAM, 0) or die();
> connect(SOCK, sockaddr_un($rendezvous)) or die();
Don't use global filehandles. If you *really* want to stick to using
socket() directly, you can use
socket(my $SOCK, PF_UNIX, SOCK_STREAM, 0) or ...;
but it would probably be easier to use
my $SOCK = IO::Socket::UNIX->new($rendevous) or ...;
which will deal with socket/connect/sockaddr_un for you.
You should always give a useful error message when you die, including
the appropriate system error, which for socket functions
> printf(SOCK "Request something\n");
Don't use printf when you can use print. In fact, I never use printf at
all in Perl: on the rare occasion I actually want to printf something, I
tend to write it as
print sprintf ...;
Also, while I don't usually have a problem with parens around function
arguments (though I avoid them myself), when the first arg is a
filehandle for print/f the lack of a comma is a little too weird... it
would be all to easy to put the comma in by mistake and write something
perfectly valid but quite different. If you're really attached to the
parens I might even recommend switching to full method syntax:
$SOCK->print("Request something\n");
though this requires a
use IO::Handle;
before it will work on ordinary filehandles. Hmmm, this is very much a
matter of style, and a rare case in which Perl's syntax is less than
ideal, so feel free to ignore this paragraph... :)
> shutdown(SOCK,1); # finished writing
It's clearer to use the named constants:
shutdown($SOCK, SHUT_WR);
> $line = <SOCK>;
> print $line;
> exit;
There's no need to exit. 'Falling off the end' is a perfectly valid way
to successfully terminate a Perl program.
> Server
> ======
>
> #!/usr/bin/perl -Tw
> use strict;
> use sigtrap;
> use Socket;
> use Carp;
>
> BEGIN {%ENV=('PATH'=>'/usr/ucb:/bin')}
>
> sub spawn; # forward declaration
> sub logmsg { print "$0 $$: @_ at ", scalar localtime, "\n" }
>
> my $NAME = 'catsock';
> my $uaddr = sockaddr_un($NAME);
> my $proto = getprotobyname('tcp');
>
> socket(Server,PF_UNIX,SOCK_STREAM,0) or die();
> unlink($NAME);
> bind(Server, $uaddr) or die();
> listen(Server,SOMAXCONN) or die();
Again, it's probably easier to use
unlink($NAME);
my $Server = IO::Socket::UNIX->new(
Local => $NAME,
Listen => SOMAXCONN,
);
SOCK_STREAM is the default for IO::Socket::UNIX.
> logmsg "server started on $NAME";
>
> accept(Client,Server) or die("accept $!");
my $Client = $Server->accept
or die "accept: $!";
> # Is Client now bidirectional?
Yes, it is.
> logmsg "connection on $NAME";
> spawn sub {
> my $input=shift;
> printf("(%s): Reply=XXXX\n", $input);
No need for printf even here:
print("($input): Reply=XXXX\n");
> };
>
> sub spawn {
> my $coderef = shift;
> my $input;
>
> unless (@_ == 0 && $coderef && ref($coderef) eq 'CODE') {
> confess "usage: spawn CODEREF";
> }
>
> close(STDIN);
> open(STDIN, "<&Client") or die("open STDIN $!");
This is a really bad idea. The example in the perldoc was forking a new
process dedicated to handling one connection, so attaching the std
handles of the new process only to the client socket was useful. You're
not doing that (yet?), so just print to and read from the client socket
directly.
You're passing the client socket from the main program to this sub as a
global variable. This is ad for all the usual reasons globals are bad:
they all apply just as much to filehandles. Use properly scoped
variables for filehandles, and pass the client socket into spawn as a
parameter. You will probably also need to pass it into the coderef;
unless it is created within the scope of $Client above, in which case
things Just Work (technically, this feature of Perl is called 'lexical
closure', and only works with anonymous subs).
Note that if you switch to using a variable for Client, but still want
to dup it onto STDIN, you have to use the three-arg form of open to do
so:
open(STDIN, '<&', $Client) or ...;
> # lsof here shows we do have fd0 dup from one of the previous fds
> open(STDOUT, ">&Client") or die("open STDOUT $!");
>
> $input=<STDIN>;
> $input="sample" unless (defined($input));
> chomp($input);
> printf(STDERR "Now executing coderef(%s)...\n", $input);
> exit &$coderef($input);
I'm not sure what you meant by this, but this will pass exit() the
return value of the printf that was the last statement in the coderef;
probably not what you want, as it will usually be 1.
IMO, 'don't call subs with &' applies to subrefs as well: I would write
the call as
$coderef->($input)
Ben
------------------------------
Date: Sat, 22 Sep 2007 00:11:32 -0700
From: rihad <rihad@mail.ru>
Subject: Re: re-launch piped external program
Message-Id: <1190445092.507925.61780@57g2000hsv.googlegroups.com>
> > have passed. And I can see ipfw hanging there during that time from
> > another console using ps. Looks like Perl holds on to the line for
> > some reason. Someone care to explain what I did wrong?
>
> Maybe ipfw doesn't flush stderr until either the buffer is full or until
> its stdin gets closed, which doesn't happen here until the parent program
> exits.
>
*Perl* holds on to the $command line even though I turned auto-flush
on with $| = 1;
As I said ipfw is hanging there all along, which wouldn't be the case
if it got the flawed command from the pipe immediately.
------------------------------
Date: Sat, 22 Sep 2007 11:39:51 GMT
From: Peter Scott <Peter@PSDT.com>
Subject: Re: re-launch piped external program
Message-Id: <pan.2007.09.22.11.39.50.683906@PSDT.com>
On Fri, 21 Sep 2007 11:46:28 -0700, rihad wrote:
> Thanks to you both, guys. I'll try the EPIPE trick as soon as I get
> over this small problem:
>
> $\ = "\n";
> $| = 1;
> open my $FW, "|-", "sudo", "ipfw", "/dev/stdin" or die "can't run
> ipfw: $!";
> $| = 1;
> print $FW 'add';
> sleep 10;
> exit;
perldoc perlvar:
$| If set to nonzero, forces a flush right away and after every
write or print on the currently selected output channel.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You did not select $FW as the current output channel.
--
Peter Scott
http://www.perlmedic.com/
http://www.perldebugged.com/
------------------------------
Date: Sat, 22 Sep 2007 21:58:54 +1000
From: Martien verbruggen <mgjv@tradingpost.com.au>
Subject: Re: re-launch piped external program
Message-Id: <slrnffa0ru.7fi.mgjv@martien.heliotrope.home>
On Sat, 22 Sep 2007 11:39:51 GMT,
Peter Scott <Peter@PSDT.com> wrote:
> On Fri, 21 Sep 2007 11:46:28 -0700, rihad wrote:
>> Thanks to you both, guys. I'll try the EPIPE trick as soon as I get
>> over this small problem:
>>
>> $\ = "\n";
>> $| = 1;
>> open my $FW, "|-", "sudo", "ipfw", "/dev/stdin" or die "can't run
>> ipfw: $!";
>> $| = 1;
>> print $FW 'add';
>> sleep 10;
>> exit;
>
> perldoc perlvar:
>
> $| If set to nonzero, forces a flush right away and after every
> write or print on the currently selected output channel.
>
> You did not select $FW as the current output channel.
This probably is a good spot to draw attention to IO::Handle's autoflush
method. rather than selecting the file handle you want to flush, you set
the autoflush attribute on those filehandles you want to flush. I find
that generally fits better with the way I think it should work.
Regards,
Martien
--
|
Martien Verbruggen | "In a world without fences,
| who needs Gates?"
|
------------------------------
Date: Sat, 22 Sep 2007 05:18:53 -0700
From: rihad <rihad@mail.ru>
Subject: Re: re-launch piped external program
Message-Id: <1190463533.930377.200440@d55g2000hsg.googlegroups.com>
> You did not select $FW as the current output channel.
>
Thank you! Worked like a charm. On a sidenote: I'm a bit new to Perl
(surprise!), and I'm at chapter 4 of "Learning Perl" ("The Llama
book") right now. Then I will read Programming Perl ("The Camel book")
and tons of perldocs. I think perldocs are best at giving minute
technical details, as you mentioned. Thanks again!
------------------------------
Date: Sat, 22 Sep 2007 07:31:18 -0400
From: "Chris M." <please_no_more@spam.net>
Subject: why do these snippets have different behavior?
Message-Id: <6vmdnUxFIKeEYGnbnZ2dnUVZ_v6rnZ2d@comcast.com>
The following two versions don't have the same effect:
# 2-LINE VERSION; this way works as expected
my $v;
$v = "hello" if 0;
# 1-LINE VERSION; this way does not work as expected (imho)
my $v = "hello" if 0;
Example Program:
for my $i (1 .. 3) {
my $v = "hello" if 0;
print "v somehow defined: '$v', i = '$i'\n" if defined $v;
$v = "bye";
}
Sample Output:
v somehow defined: 'bye', i = '2'
v somehow defined: 'bye', i = '3'
When the 2-line snippet is used instead, the program produces no output, as
I was expecting.
It's as if not only the assignment (i.e. '= "hello"') part of the line is
subject to the conditional clause (false in this case), but also the
declaration (i.e. 'my') part of the line, too. Hence, the variable is not
re-declared each iteration, but retains its previous value. But if that
were truly the case, then it seems to me Perl should complain when $v is
assigned to "bye" since the variable was never declared (I have both
'strict' and 'warnings' on) which it doesn't. Although I suppose the
interpreter can't evaluate the conditional clause until runtime (even though
in this case the condition is static); maybe that's why?
Anyone else bothered by this behavior? This seems like a nasty feature.
Took me quite awhile before I realized some of my for-loop iterations were
interfering with each other...
Thanks,
Chris
------------------------------
Date: Sat, 22 Sep 2007 09:22:25 -0400
From: Eric Amick <eric-amick@comcast.net>
Subject: Re: why do these snippets have different behavior?
Message-Id: <dk5af31nj72sn35aupgfsha5jaua5cojh4@4ax.com>
On Sat, 22 Sep 2007 07:31:18 -0400, "Chris M." <please_no_more@spam.net>
wrote:
>The following two versions don't have the same effect:
>
># 2-LINE VERSION; this way works as expected
>my $v;
>$v = "hello" if 0;
>
># 1-LINE VERSION; this way does not work as expected (imho)
>my $v = "hello" if 0;
The one-line version is documented to have undefined results; see
"Statement Modifiers" in perldoc perlsyn. ( I wish they would put some
mention of this in the documetation for my as well.)
--
Eric Amick
Columbia, MD
------------------------------
Date: Sat, 22 Sep 2007 13:10:55 -0400
From: "Chris M." <please_no_more@spam.net>
Subject: Re: why do these snippets have different behavior?
Message-Id: <zJ-dnfPUi4Ih0WjbnZ2dnUVZ_oqhnZ2d@comcast.com>
Thanks, Eric. I'm sure I read that doc page a dozen times and it just never
clicked. "Here be dragons", indeed.
--Chris
"Eric Amick" <eric-amick@comcast.net> wrote in message
news:dk5af31nj72sn35aupgfsha5jaua5cojh4@4ax.com...
> On Sat, 22 Sep 2007 07:31:18 -0400, "Chris M." <please_no_more@spam.net>
> wrote:
>
>>The following two versions don't have the same effect:
>>
>># 2-LINE VERSION; this way works as expected
>>my $v;
>>$v = "hello" if 0;
>>
>># 1-LINE VERSION; this way does not work as expected (imho)
>>my $v = "hello" if 0;
>
> The one-line version is documented to have undefined results; see
> "Statement Modifiers" in perldoc perlsyn. ( I wish they would put some
> mention of this in the documetation for my as well.)
> --
> Eric Amick
> Columbia, MD
------------------------------
Date: Sat, 22 Sep 2007 11:28:30 -0700
From: Bill H <bill@ts1000.us>
Subject: Re: why do these snippets have different behavior?
Message-Id: <1190485710.111722.6330@y42g2000hsy.googlegroups.com>
On Sep 22, 7:31 am, "Chris M." <please_no_m...@spam.net> wrote:
> The following two versions don't have the same effect:
>
> # 2-LINE VERSION; this way works as expected
> my $v;
> $v = "hello" if 0;
>
> # 1-LINE VERSION; this way does not work as expected (imho)
> my $v = "hello" if 0;
>
> Example Program:
>
> for my $i (1 .. 3) {
> my $v = "hello" if 0;
> print "v somehow defined: '$v', i = '$i'\n" if defined $v;
> $v = "bye";
>
> }
>
> Sample Output:
>
> v somehow defined: 'bye', i = '2'
> v somehow defined: 'bye', i = '3'
>
> When the 2-line snippet is used instead, the program produces no output, as
> I was expecting.
>
> It's as if not only the assignment (i.e. '= "hello"') part of the line is
> subject to the conditional clause (false in this case), but also the
> declaration (i.e. 'my') part of the line, too. Hence, the variable is not
> re-declared each iteration, but retains its previous value. But if that
> were truly the case, then it seems to me Perl should complain when $v is
> assigned to "bye" since the variable was never declared (I have both
> 'strict' and 'warnings' on) which it doesn't. Although I suppose the
> interpreter can't evaluate the conditional clause until runtime (even though
> in this case the condition is static); maybe that's why?
>
> Anyone else bothered by this behavior? This seems like a nasty feature.
> Took me quite awhile before I realized some of my for-loop iterations were
> interfering with each other...
>
> Thanks,
> Chris
Curious - what is the benefit of putting the if at the end of the
line?
print "v somehow defined: '$v', i = '$i'\n" if defined $v;
versus
if (defined $v){print "v somehow defined: '$v', i = '$i'\n";}
Bill H
------------------------------
Date: Sun, 23 Sep 2007 00:37:34 +0200 (CEST)
From: Jim Cochrane <allergic-to-spam@no-spam-allowed.org>
Subject: Re: why do these snippets have different behavior?
Message-Id: <slrnffb69a.vtr.allergic-to-spam@no-spam-allowed.org>
On 2007-09-22, Bill H <bill@ts1000.us> wrote:
> On Sep 22, 7:31 am, "Chris M." <please_no_m...@spam.net> wrote:
>> The following two versions don't have the same effect:
>>
>> # 2-LINE VERSION; this way works as expected
>> my $v;
>> $v = "hello" if 0;
>>
>> # 1-LINE VERSION; this way does not work as expected (imho)
>> my $v = "hello" if 0;
>>
>> Example Program:
>>
>> for my $i (1 .. 3) {
>> my $v = "hello" if 0;
>> print "v somehow defined: '$v', i = '$i'\n" if defined $v;
>> $v = "bye";
>>
>> }
>>
>> Sample Output:
>>
>> v somehow defined: 'bye', i = '2'
>> v somehow defined: 'bye', i = '3'
>>
>> When the 2-line snippet is used instead, the program produces no output, as
>> I was expecting.
>>
>> It's as if not only the assignment (i.e. '= "hello"') part of the line is
>> subject to the conditional clause (false in this case), but also the
>> declaration (i.e. 'my') part of the line, too. Hence, the variable is not
>> re-declared each iteration, but retains its previous value. But if that
>> were truly the case, then it seems to me Perl should complain when $v is
>> assigned to "bye" since the variable was never declared (I have both
>> 'strict' and 'warnings' on) which it doesn't. Although I suppose the
>> interpreter can't evaluate the conditional clause until runtime (even though
>> in this case the condition is static); maybe that's why?
>>
>> Anyone else bothered by this behavior? This seems like a nasty feature.
>> Took me quite awhile before I realized some of my for-loop iterations were
>> interfering with each other...
>>
>> Thanks,
>> Chris
>
> Curious - what is the benefit of putting the if at the end of the
> line?
>
> print "v somehow defined: '$v', i = '$i'\n" if defined $v;
>
> versus
>
> if (defined $v){print "v somehow defined: '$v', i = '$i'\n";}
>
> Bill H
>
Seems to me the only benefit is a programmer with a mean spirit can use
the first form to make it harder for his fellow programmers to catch.
("Why don't I put the conditional clause at the end of the line where my
teammate Bill, whom I despise, is likely to miss it. Hopefully it will
cause him to introduce a bug in the code and get him fired.")
:-)
--
------------------------------
Date: Sun, 23 Sep 2007 00:14:49 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: why do these snippets have different behavior?
Message-Id: <98kgs4-e97.ln1@osiris.mauzo.dyndns.org>
Quoth "Chris M." <please_no_more@spam.net>:
> The following two versions don't have the same effect:
>
> # 2-LINE VERSION; this way works as expected
> my $v;
> $v = "hello" if 0;
>
> # 1-LINE VERSION; this way does not work as expected (imho)
> my $v = "hello" if 0;
This has been a known, though undocumented, way of implementing an
equivalent to C's 'static' variables for a long time. The official
position from the perldocs is that the behaviour is undefined. 5.10 will
have 'state' variables, which give explicit and documented access to
equivalent behaviour.
> When the 2-line snippet is used instead, the program produces no output, as
> I was expecting.
The second statement is of course completely irrelevant, and is in fact
optimized away:
~% perl -MO=Deparse -e'my $x; $x = 2 if 0;'
my $x;
'???';
-e syntax OK
~%
('???'; from Deparse means 'there used to be a statement here, but it
got optimized away so I don't know what it said').
> It's as if not only the assignment (i.e. '= "hello"') part of the line is
> subject to the conditional clause (false in this case), but also the
> declaration (i.e. 'my') part of the line, too.
This is not quite what happens. 'my' has both run-time and compile-time
effects: at compile time, it causes a new variable to be declared; this
happens anyway. At runtime, it causes that variable to be reinitialized;
this part was accidentally made subject to the 'if 0'. Strictly
speaking, it's a bug in perl. But some clever people found out about it
and started depending on it, so it probably can't be fixed for a while
yet; hence the 'undefined' in the perldocs. As a rule, statements of the
form
my ... if ...;
or similar should be avoided.
> Hence, the variable is not re-declared each iteration, but retains its
> previous value. But if that were truly the case, then it seems to me
> Perl should complain when $v is assigned to "bye" since the variable
> was never declared (I have both 'strict' and 'warnings' on) which it
> doesn't. Although I suppose the interpreter can't evaluate the
> conditional clause until runtime (even though in this case the
> condition is static); maybe that's why?
Yes. The declaration happens at compile-time, so is unaffected by the
conditional. If the condition is known at compile-time, the whole
runtime effect of 'my' is optimized away, and Deparse gets so confused
it emits code that doesn't compile:
~% perl -MO=Deparse -Mstrict -e'my $x if 0; print $x'
use strict 'refs';
'???';
print $x;
-e syntax OK
> Anyone else bothered by this behavior? This seems like a nasty feature.
5.10 will warn, since the desired behaviour now has a proper syntax:
~% perl-current -we'my $x if 0;'
Deprecated use of my() in false conditional at -e line 1.
~%
> Took me quite awhile before I realized some of my for-loop iterations were
> interfering with each other...
What did you hope to achieve with that syntax anyway? Or did you simply
not realize you were attempting to make a 'my' conditional?
Ben
------------------------------
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 875
**************************************
