[32834] in Perl-Users-Digest
Perl-Users Digest, Issue: 4099 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Dec 23 14:09:34 2013
Date: Mon, 23 Dec 2013 11:09:05 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 23 Dec 2013 Volume: 11 Number: 4099
Today's topics:
Re: DBI: CREATE USER statement fails <rweikusat@mobileactivedefense.com>
Re: Extra commas ignored? <rweikusat@mobileactivedefense.com>
Re: PDL Questions - Dec. 21, 2013 <jblack@nospam.com>
Re: PDL Questions - Dec. 21, 2013 <edgrsprj@ix.netcom.com>
Re: PDL Questions - Dec. 21, 2013 <news@lawshouse.org>
Re: PDL Questions - Dec. 21, 2013 <edgrsprj@ix.netcom.com>
Re: PDL Questions - Dec. 21, 2013 <jurgenex@hotmail.com>
Question about language setting <dave@invalid.invalid>
Re: Question about language setting <rweikusat@mobileactivedefense.com>
Re: Question about language setting <dave@invalid.invalid>
Re: Question about language setting <rweikusat@mobileactivedefense.com>
Re: Syntax understanding problem <justin.1312@purestblue.com>
Re: Syntax understanding problem (Tim McDaniel)
Re: Syntax understanding problem <rweikusat@mobileactivedefense.com>
Re: Syntax understanding problem <derykus@gmail.com>
tricky stdout <gravitalsun@foo.com>
Re: tricky stdout <jurgenex@hotmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 22 Dec 2013 18:12:22 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: DBI: CREATE USER statement fails
Message-Id: <87haa0wy9l.fsf@sable.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Alan Curry <rlwinm@sdf.org>:
>> In article <VA.000068e4.2e1f85d4@news.conactive.com>,
>> Kai Schaetzl <kai@mvps.org.invalid> wrote:
>> >
>> >/testmysqluser.pl testuser4 "testuser4-test"
>> >DBD::mysql::db do failed: String 'testuser4' IDENTIFIED BY ' is too
>> long for user name
>> >(should be no longer than 16) at ./testmysqluser.pl line 19.
>> [...]
>> >
>> >$sql = "CREATE USER '$user'@'localhost' IDENTIFIED BY '$password'";
>> >
>>
>> Notice how the localhost part didn't show up in the error message? That's a
>> clue. A bigger clue can be seen if you'd just enable warnings:
>>
>> Possible unintended interpolation of @::localhost in string at - line 4.
>> Name "main::localhost" used only once: possible typo at - line 4.
>>
>> To put an @ character in a qq string you need to use \@ or you'll be
>> interpolating an array.
>
> If the OP had used placeholders and a single-quoted string this problem
> would have never existed:
>
> my $sql = 'CREATE USER ?@? IDENTIFIED BY ?';
> $dbh->do($sql, undef, $user, "localhost", $password);
>
> This will also avoid potential SQL-injection problems if $password
> contains a single-quote character.
This deserves some emphasis: The sole reason why 'SQL injection' exists
at all is because people construct complex SQL-statements via string
interpolation and get the quoting wrong because this is much more
complicated than simply passing a template statement with placeholders
to 'the DB engine' (however implemented) and a list of
parameters. Programming is not a sport abnd there are no consolation
prizes for "trying hard to accomplish something stupid and failing at
that". Use the simple way.
------------------------------
Date: Sun, 22 Dec 2013 14:05:39 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Extra commas ignored?
Message-Id: <87bo092d70.fsf@sable.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
[...]
>> > There is only one comma operator. It always parses the same, and it
>> > always compiles down to the same opcode (it has to, because context
>> > isn't always known at compile time).
>>
>> Judging from the 5.10.1 perly.y, there's actually no such thing as 'a
>> comma operator' which would need to be a 'binary operator between
>> terms'. The lexer treats it as such but in the parser, it's only (slight
>> simplification)
>>
>> /* Expressions are a list of terms joined by commas */
>> argexpr : argexpr ','
>
> [Sometime between 5.10.1 and the blead source I posted an extract from
> before, this production was renamed to 'listexpr'...]
>
>> | argexpr ',' term
>> | term %prec PREC_LOW
>> ;
>>
>> ie, there is something like a list operator and the , is used as purely
>> syntactical element for separating terms in a list.
>
> OK, you can call it that if you like; it's not really any different from
> the ?: operator, which uses '?' and ':' to separate its three
> arguments.
If it really wasn't different, you'd refer to 'the question mark
operator' and 'the colon operator' in this case and this would be as
inadequate because they're also just syntactical elements of something
else.
> My point was that 'the scalar comma operator' and 'the list context list
> construction operator' are actually the same operator, whose behaviour
> is context-dependant.
There is no such thing as 'a comma operator' in the Perl grammar (at
least, I didn't find anything like that), commas are used as separators
in a certain kind of compound expression. As Tim McDaniel observed,
despite comma is documented as binary operator, it doesn't behave like
one: It has no arity. The other hypothesis, "it is a binary operator but
one which can have imaginary arguments" is to be rejected on the grounds
that it introduces artifical complications in order to bend reality such
that it fits with terminology (applying Occam's razor).
>
>> >> [*] Technically, the scalar-context comma operator is also not an operator
>> >> in the sense that + is, it's rather a compiler directive.
>> >
>> > Nonsense. The lexer, parser and optree handle it exactly the same way as
>> > they handle +, except for the fact that OP_LIST takes multiple arguments.
>>
>> At least in certain cases, the list is expanded inline, with no 'list
>> operator' anywhere in sight, eg
>>
>> [rw@sable]~#perl -MO=Concise,-exec,a -e 'sub a { return ($_[0], $_[3],
>> $_[2]); }'
>> main::a:
>> 1 <;> nextstate(main 1 -e:1) v
>> 2 <0> pushmark s
>> 3 <#> aelemfast[*_] s
>> 4 <#> aelemfast[*_] s/3
>> 5 <#> aelemfast[*_] s/2
>> 6 <@> return KP
>> 7 <1> leavesub[1 ref] K/REFC,1
>
> That's a slight hack: this is the 'listop' production, which does
> actually build an OP_LIST, but then, rather than adding an extra op, it
> converts the OP_LIST into an OP_RETURN. It's easier to see what's
> happening without -exec:
>
> ~/src/perl/perl% perl -MO=Concise,a -e'sub a { $x, $y, $z }'
> main::a:
> 7 <1> leavesub[1 ref] K/REFC,1 ->(end)
> - <@> lineseq KP ->7
> 1 <;> nextstate(main 1 -e:1) v ->2
> 6 <@> list K ->7
> 2 <0> pushmark s ->3
> - <1> ex-rv2sv sK/1 ->4
> 3 <$> gvsv(*x) s ->4
> - <1> ex-rv2sv sK/1 ->5
> 4 <$> gvsv(*y) s ->5
> - <1> ex-rv2sv sK/1 ->6
> 5 <$> gvsv(*z) s ->6
> -e syntax OK
> ~/src/perl/perl% perl -MO=Concise,a -e'sub a { return $x, $y, $z }'
> main::a:
> 7 <1> leavesub[1 ref] K/REFC,1 ->(end)
> - <@> lineseq KP ->7
> 1 <;> nextstate(main 1 -e:1) v ->2
> 6 <@> return K ->7
> 2 <0> pushmark s ->3
> - <1> ex-rv2sv sK/1 ->4
> 3 <$> gvsv(*x) s ->4
> - <1> ex-rv2sv sK/1 ->5
> 4 <$> gvsv(*y) s ->5
> - <1> ex-rv2sv sK/1 ->6
> 5 <$> gvsv(*z) s ->6
> -e syntax OK
>
> The only different between these two is that perl has turned the 'list'
> into a 'return'.
The difference I see here is that there has to be some op (not operator)
in this place and if no other was provided, a 'list' op is used. That
'return' happens to be equivalent to that is just an accidental property of
my example (The same phenomenon can be observed for reverse and grep and
presumably, for any other list operator returning a list).
[...]
>> It would be interesting to know if 'the comma operator' in C is actually
>> treated as an operator or if the historical misnomer actually came from
>> there.
>
> In C the comma really does have two entirely different meanings: the
> 'comma operator' which behaves like Perl's comma in scalar context, and
> the comma-as-an-argument-separator in the argument list of a function
> call, which is not really an operator at all.
The main difference is that , is really a binary operator in C, eg this
------
int main(void)
{
return 1,, 2;
}
------
doesn't compile because of a missing operand.
------------------------------
Date: Sun, 22 Dec 2013 22:55:08 -0600
From: John Black <jblack@nospam.com>
Subject: Re: PDL Questions - Dec. 21, 2013
Message-Id: <MPG.2d217e2862c8f6c79897a5@news.eternal-september.org>
In article <QeydnRQ9h74GUijPnZ2dnUVZ_gKdnZ2d@earthlink.com>, edgrsprj@ix.netcom.com says...
>
> "George Mpouras" <gravitalsun@hotmail.foo> wrote in message
> news:l94ifl$1g9$1@news.ntua.gr...
> > Perl is great, but for row calculation power there is only C.
>
> http://pdl.perl.org
>
> So far I haven't seen a good explanation of exactly how the PDL
> module works. But I am guessing that when Perl is told to run, that module
> converts some specially written Perl code to something like C language code.
> And then that C (or whatever) code runs instead of having Perl run all of
> the Perl code one statement at a time.
From page 7 of the PDL manual: "In PDL each of these [functions] is implemented by heavily
optimized C code, which is what makes PDL very efficient for procession of large chunks of
data. If you did the same operation using normal perl arrays rather than piddles it would be
about ten to twenty times slower (and use ten times more memory)."
John Black
------------------------------
Date: Mon, 23 Dec 2013 08:32:10 -0600
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Re: PDL Questions - Dec. 21, 2013
Message-Id: <6ridnRIt4o7w1CXPnZ2dnUVZ_qGdnZ2d@earthlink.com>
"John Black" <jblack@nospam.com> wrote in message
news:MPG.2d217e2862c8f6c79897a5@news.eternal-september.org...
>> http://pdl.perl.org
>> So far I haven't seen a good explanation of exactly how the PDL
>> module works. But I am guessing that when Perl is told to run, that
>> module
>> converts some specially written Perl code to something like C language
>> code.
>> And then that C (or whatever) code runs instead of having Perl run all of
>> the Perl code one statement at a time.
> From page 7 of the PDL manual: "In PDL each of these [functions] is
> implemented by heavily
> optimized C code, which is what makes PDL very efficient for procession of
> large chunks of
> data. If you did the same operation using normal perl arrays rather than
> piddles it would be
> about ten to twenty times slower (and use ten times more memory)."
Hi John,
Thanks for tracking down that information. I did read through some
of their documentation but did not come across those details myself. And
from the lack of responses here to my questions I have to wonder how many
people are actually using the Perl PDL module.
It looks like PDL could be a very powerful and useful addition to
standard Perl. And it appears that it probably does the same things as a
module that I myself encouraged ActiveState to develop quite a while ago.
That C code generation is largely what I thought PDL might be doing.
And that information generally answers several question:
First,
Q: What type of accelerated code is actually generated?
A: It is some version of C.
Second,
Q: How fast is that new code compared with regular Perl code, Python,
Fortran, C, or Julia?
A: It appears that if it is optimized C code then the calculations are
likely as fast as or faster as any of those other languages including
perhaps Fortran.
If I can determine how to contact the Julia language people I am
going to recommend to them that they run their calculation speed tests using
the PDL module and then add that information to their Web page benchmark
chart.
A third question that I myself have had is,
Q: Would it be worthwhile for me to upgrade my Perl programs to the latest
ActiveState version so that the PDL module can be used?
A: With that potential calculation speed improvement and assuming that the
graphics work much better, that update looks quite reasonable.
One of the reasons for wanting to stay with Perl is that Perl appears
to run on almost every Internet Server on the planet. Other languages can
probably be installed on some servers. But that means more work.
I don't know if the PDL module would be available with the Perl
versions on most Internet Servers. Hopefully it is. That could make Web
site based graphics a lot easier. Or perhaps PDL could be installed if
necessary. I can get that information myself from my own Internet Server
people.
------------------------------
Date: Mon, 23 Dec 2013 15:21:52 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: PDL Questions - Dec. 21, 2013
Message-Id: <dq-dndT_LMqNyCXPnZ2dnUVZ8tOdnZ2d@giganews.com>
On 23/12/13 14:32, E.D.G. wrote:
> from the lack of responses here to my questions I have to wonder how
> many people are actually using the Perl PDL module.
Don't lose heart; don't be discouraged. The lack of response here is
probably because people lose the will to live through trying to help you
in your futile project.
Wherever it is that you're trying to get to, you won't get there from
where you are.
--
Henry Law Manchester, England
------------------------------
Date: Mon, 23 Dec 2013 09:48:32 -0600
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Re: PDL Questions - Dec. 21, 2013
Message-Id: <TYydnVv_7Z3OxiXPnZ2dnUVZ_s-dnZ2d@earthlink.com>
"Henry Law" <news@lawshouse.org> wrote in message
news:dq-dndT_LMqNyCXPnZ2dnUVZ8tOdnZ2d@giganews.com...
> probably because people lose the will to live through trying to help you
> in your futile project.
What "project" might that be? I presently have several dozen
underway covering a wide variety of science and medical efforts.
And again, it would be my guess that not too many people are
presently using PDL. One indicator of that would be the problems that I
myself have had so far with getting the module to install and run using PPM.
Usually new modules install without any problems.
Actually, I have several degrees in the physical sciences and regard
myself as a disaster mitigation professional. My research and advice
related to a wide variety of life saving, health improving, and economy
strengthening efforts have, in my opinion, been used extensively by
governments and NGOs around the world for many years.
The programming work that I do is largely just whatever is needed to
glue other efforts together.
At the moment the main programming "project" is to find a faster and
more efficient language than standard Perl. And if that PDL module works as
well as it sounds, then I will probably eventually create a "Perl for
Scientists" Web page.
Perhaps the main problem with having scientists around the world use
Perl is that the free downloadable documentation for beginner and
intermediate level programmers such as myself is in my opinion not very
good.
If you want to do something as simple as:
for $i(1..5){;
print $i*2, "\n";
};
You don't want to have to spend a year trying to learn how to install Perl
and get things running.
It took me a long, long time to learn how to even get Perl to
generate exe versions of a program. And it is actually extremely easy to do
once you learn how it works. But the documentation for how to do that was
unclear or almost nonexistent for a beginner or intermediate level
programmer in my opinion. The documentation should say, 1. Do this. 2. Do
this. 3. Do that.
Other than that, if Perl calculations can be made to run faster using
PDL and if the module also provides adequate graphics then it is my opinion
that I have stated repeatedly over the years that it is likely a high value
language for scientists who are not professional programmers. For example,
I myself like that fact that arrays don't have to have predefined sizes etc.
Most modern computers have enough memory that a simple program doesn't have
to be optimized for array sizes.
------------------------------
Date: Mon, 23 Dec 2013 07:49:09 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: PDL Questions - Dec. 21, 2013
Message-Id: <vomgb99i0bj3odl1s26k9fi1aaassm4jnp@4ax.com>
Henry Law <news@lawshouse.org> wrote:
>On 23/12/13 14:32, E.D.G. wrote:
>> from the lack of responses here to my questions I have to wonder how
>> many people are actually using the Perl PDL module.
>
>Don't lose heart; don't be discouraged. The lack of response here is
>probably because people lose the will to live through trying to help you
>in your futile project.
s/lose/lost many years ago/
jue
------------------------------
Date: Mon, 23 Dec 2013 15:39:06 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Question about language setting
Message-Id: <fV45K0OBJxbE-pn2-BdNdroGr6Gvs@paddington.bear.den>
I have a perl script that checks a program's "data base" for
consistancy.
A German user said it would not run and threw a "Feature bundle 5.0.0"
not supported from feature.pm. This was because I call Carp.
He now says
<qoute>
the perl problem seems to be solved: it's not a problem with
installation or version. The problem is the setting for "LANG": It has
to be LANG=en_US.UTF-8 and not LANG=de_DE_EURO which is the standard
for german!
</quote>
Surely (base) perl modules aren't dependent on language?
--
Regards
Dave Saville
------------------------------
Date: Mon, 23 Dec 2013 16:13:08 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Question about language setting
Message-Id: <87d2kn5ywb.fsf@sable.mobileactivedefense.com>
"Dave Saville" <dave@invalid.invalid> writes:
> A German user said it would not run and threw a "Feature bundle 5.0.0"
> not supported from feature.pm. This was because I call Carp.
>
> He now says
>
> <qoute>
> the perl problem seems to be solved: it's not a problem with
> installation or version. The problem is the setting for "LANG": It has
> to be LANG=en_US.UTF-8 and not LANG=de_DE_EURO which is the standard
> for german!
> </quote>
>
> Surely (base) perl modules aren't dependent on language?
According to a completely random web search result,
https://www.illumos.org/issues/1203
the issue is possibly that the 5.0 becomes 5,0 when formatted
according to German conventions. The thread and related bug & bugfix has
some more information on this (AFAIK, 'feature bundle 5.0.0' means
'Perl5').
------------------------------
Date: Mon, 23 Dec 2013 17:06:16 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: Question about language setting
Message-Id: <fV45K0OBJxbE-pn2-qRd3Uh5nxH8W@paddington.bear.den>
On Mon, 23 Dec 2013 16:13:08 UTC, Rainer Weikusat
<rweikusat@mobileactivedefense.com> wrote:
> "Dave Saville" <dave@invalid.invalid> writes:
> > A German user said it would not run and threw a "Feature bundle 5.0.0"
> > not supported from feature.pm. This was because I call Carp.
> >
> > He now says
> >
> > <qoute>
> > the perl problem seems to be solved: it's not a problem with
> > installation or version. The problem is the setting for "LANG": It has
> > to be LANG=en_US.UTF-8 and not LANG=de_DE_EURO which is the standard
> > for german!
> > </quote>
> >
> > Surely (base) perl modules aren't dependent on language?
>
> According to a completely random web search result,
>
> https://www.illumos.org/issues/1203
>
> the issue is possibly that the 5.0 becomes 5,0 when formatted
> according to German conventions. The thread and related bug & bugfix has
> some more information on this (AFAIK, 'feature bundle 5.0.0' means
> 'Perl5').
Well that seems to suggest that it is not perl but something else
<qoute>
root source found, the bug is not in perl, its in Illumos locales,
</quote>
Whatever that is. Surely perl must be used in non English speaking
countries? :-)
--
Regards
Dave Saville
------------------------------
Date: Mon, 23 Dec 2013 17:28:24 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Question about language setting
Message-Id: <878uvb5vev.fsf@sable.mobileactivedefense.com>
"Dave Saville" <dave@invalid.invalid> writes:
> On Mon, 23 Dec 2013 16:13:08 UTC, Rainer Weikusat
> <rweikusat@mobileactivedefense.com> wrote:
>
>> "Dave Saville" <dave@invalid.invalid> writes:
>> > A German user said it would not run and threw a "Feature bundle 5.0.0"
>> > not supported from feature.pm. This was because I call Carp.
>> >
>> > He now says
>> >
>> > <qoute>
>> > the perl problem seems to be solved: it's not a problem with
>> > installation or version. The problem is the setting for "LANG": It has
>> > to be LANG=en_US.UTF-8 and not LANG=de_DE_EURO which is the standard
>> > for german!
>> > </quote>
>> >
>> > Surely (base) perl modules aren't dependent on language?
>>
>> According to a completely random web search result,
>>
>> https://www.illumos.org/issues/1203
>>
>> the issue is possibly that the 5.0 becomes 5,0 when formatted
>> according to German conventions. The thread and related bug & bugfix has
>> some more information on this (AFAIK, 'feature bundle 5.0.0' means
>> 'Perl5').
>
> Well that seems to suggest that it is not perl but something else
>
> <qoute>
> root source found, the bug is not in perl, its in Illumos locales,
> </quote>
>
> Whatever that is. Surely perl must be used in non English speaking
> countries? :-)
As I already wrote: The thread and the associated OpenSlowalrus bug &
bug fix provide some more background information on this. In particular,
the suggested workaround (set LC_NUMERIC to a 'decimal point' locale)
should be sufficient to determine if this is really the same
problem. Depending on how you feel about that, you might also just tell
your user that "Locale support on your system is obviously broken, get
of my lawn, sucker!" -- the open source way of dealing with
'uninteresting' user problems ...
------------------------------
Date: Sun, 22 Dec 2013 12:10:59 +0000
From: Justin C <justin.1312@purestblue.com>
Subject: Re: Syntax understanding problem
Message-Id: <jf1joa-t9n.ln1@moonlight.purestblue.com>
On 2013-12-20, Ben Morrow <ben@morrow.me.uk> wrote:
>
> Justin's confusion is more an example of why it is a bad idea to copy
> code you don't entirely understand (sorry Justin) than of anything wrong
> with the construction itself.
No problem, Ben. I must have been under the impression that I
understood it at the time I used it, but my understanding must
have slipped since. I wouldn't just copy something I saw on the
web. It was probably one of those "oh, that's clever" moments
where I think "I must remember that, it'll save me..." and then
promptly forget it.
I'll probably replace it with Rainer's variation:
/^Relayed message/ and $discard = 0, next;
because this is clearer to me.
The confusing part, for me, in perldoc perlop WRT the comma
operator, is ``In scalar context it evaluates its left argument,
throws that value away, then evaluates its right argument and
returns that value''. I can understand the ``throws ... away''
if I had:
/^match/ and call_a_sub(foo), next;
the return of call_a_sub would be discarded, but the assignment
in my code isn't discarded.
You know, by the time I get back to work, after Christmas, I
may just do:
if (/^Relayed message/) {
$discard = 0;
next;
}
Depends if it's still clear to me in the new year.
Thank you all for the discussion.
Justin.
------------------------------
Date: Sun, 22 Dec 2013 14:48:08 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Syntax understanding problem
Message-Id: <l96u38$5lu$1@reader1.panix.com>
In article <jf1joa-t9n.ln1@moonlight.purestblue.com>,
Justin C <justin.1312@purestblue.com> wrote:
>/^Relayed message/ and $discard = 0, next;
...
>The confusing part, for me, in perldoc perlop WRT the comma
>operator, is ``In scalar context it evaluates its left argument,
>throws that value away, then evaluates its right argument and
>returns that value''. I can understand the ``throws ... away''
>if I had:
>
>/^match/ and call_a_sub(foo), next;
>
>the return of call_a_sub would be discarded, but the assignment
>in my code isn't discarded.
It doesn't say "ignores the left argument completely"; in contrast, it
says that it "evaluates" it. It says that it "throws that value
away", "that value" being the return value of the evaluation. In
>/^match/ and call_a_sub(foo), next;
it still calls call_a_sub, and any global side effects from the sub
remain (opening or closing files, setting global variables,
whatever). The only thing discarded is the return value.
An assignment statement returns a value:
$ perl -e 'print ($x = 23, "\n")'
23
So in
>/^Relayed message/ and $discard = 0, next;
the assignment gets done and $discard is set to 0. It's just that the
0 return value coming out of the assignment is discarded.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Sun, 22 Dec 2013 17:42:05 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Syntax understanding problem
Message-Id: <87sitkdbpu.fsf@sable.mobileactivedefense.com>
tmcd@panix.com (Tim McDaniel) writes:
> In article <jf1joa-t9n.ln1@moonlight.purestblue.com>,
> Justin C <justin.1312@purestblue.com> wrote:
>>/^Relayed message/ and $discard = 0, next;
> ...
>>The confusing part, for me, in perldoc perlop WRT the comma
>>operator, is ``In scalar context it evaluates its left argument,
>>throws that value away, then evaluates its right argument and
>>returns that value''. I can understand the ``throws ... away''
>>if I had:
>>
>>/^match/ and call_a_sub(foo), next;
>>
>>the return of call_a_sub would be discarded, but the assignment
>>in my code isn't discarded.
>
> It doesn't say "ignores the left argument completely"; in contrast, it
> says that it "evaluates" it. It says that it "throws that value
> away", "that value" being the return value of the evaluation. In
>
>>/^match/ and call_a_sub(foo), next;
>
> it still calls call_a_sub, and any global side effects from the sub
> remain (opening or closing files, setting global variables,
> whatever). The only thing discarded is the return value.
It might be easier to understand this when knowing the implementation:
Internally, a list is represented as an OP_LIST (corresponding with
pp_list) whose arguments are the elements of the list (Except when the
list is an argument list for another list operator. In this case, the
OP_LIST/ pp_list is elided). Implemented in Perl, the 'list operator'
would look like this:
sub list
{
return wantarray() ? @_ : $_[$#_];
}
which means the
/^Relayed message/ and $discard = 0, next;
is really something like this:
/^Relayed messages/ and list($discard = 0, next); # [*]
[*] Loop control is indeed allowed in 'argument lists', eg
print("$_\n", ($_ & 1 and next) || '') for 1 .. 10;
is a seriously bizarre way to print all even numbers from (1,10)
------------------------------
Date: Sun, 22 Dec 2013 22:44:18 -0800
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: Syntax understanding problem
Message-Id: <l98m4q$hlq$1@speranza.aioe.org>
On 12/22/2013 6:48 AM, Tim McDaniel wrote:
> In article <jf1joa-t9n.ln1@moonlight.purestblue.com>,
> Justin C <justin.1312@purestblue.com> wrote:
>> /^Relayed message/ and $discard = 0, next;
> ...
>
> it still calls call_a_sub, and any global side effects from the sub
> remain (opening or closing files, setting global variables,
> whatever). The only thing discarded is the return value.
>
> An assignment statement returns a value:
>
> $ perl -e 'print ($x = 23, "\n")'
> 23
>
> So in
>
>> /^Relayed message/ and $discard = 0, next;
>
> the assignment gets done and $discard is set to 0. It's just that the
> 0 return value coming out of the assignment is discarded.
>
Deparse (with or without brackets) may make it clearer:
$ perl -MO=Deparse -e '/^Relayed message/ and $discard = 0, next;'
-e syntax OK
$discard = 0, next if /^Relayed message/;
$ perl -MO=Deparse,-p -e'/^match/ and call_a_sub(foo), next'
-e syntax OK
(/^match/ and (call_a_sub('foo'), (next)));
--
Charles DeRykus
------------------------------
Date: Mon, 23 Dec 2013 14:40:36 +0200
From: George Mpouras <gravitalsun@foo.com>
Subject: tricky stdout
Message-Id: <l99aut$hg$1@news.ntua.gr>
I use the s1.pl to feed with data the s2.pl
is there any way s1.pl to catch back the output of s2.pl ?
# s1.pl
open SHELL, '|-', './s2.pl' or die "Could not run shell $?\n";
print SHELL "$_\n" foreach 'a1', 'a2', 'a3';
close SHELL;
# s2.pl
while (<STDIN>) {
chomp $_;
print STDOUT "s2 $$ received \"$_\"\n" }
------------------------------
Date: Mon, 23 Dec 2013 07:47:19 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: tricky stdout
Message-Id: <0nmgb9t9sdl5fg3lj73pik7ib0e2mqjpkc@4ax.com>
George Mpouras <gravitalsun@foo.com> wrote:
>I use the s1.pl to feed with data the s2.pl
>is there any way s1.pl to catch back the output of s2.pl ?
perldoc -q pipe
"How can I open a pipe both to and from a command?"
jue
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 4099
***************************************
