[32403] in Perl-Users-Digest
Perl-Users Digest, Issue: 3670 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Apr 21 06:09:23 2012
Date: Sat, 21 Apr 2012 03:09:05 -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, 21 Apr 2012 Volume: 11 Number: 3670
Today's topics:
Re: A Design Pattern Question for Functional Programers <jurgenex@hotmail.com>
Re: A Design Pattern Question for Functional Programers <cartercc@gmail.com>
Optionally avoid AutoLoader <marc.girod@gmail.com>
Using symbolic references to invoke package methods - g <jhumanski@gmail.com>
Re: Using symbolic references to invoke package methods <peter@makholm.net>
Re: Using symbolic references to invoke package methods <rweikusat@mssgmbh.com>
Re: Using symbolic references to invoke package methods <uri@stemsystems.com>
Re: Using symbolic references to invoke package methods <ben@morrow.me.uk>
Re: Using symbolic references to invoke package methods (Tim McDaniel)
Re: Using symbolic references to invoke package methods <rweikusat@mssgmbh.com>
Re: Using symbolic references to invoke package methods (Tim McDaniel)
Re: Using symbolic references to invoke package methods <ben@morrow.me.uk>
Re: Using symbolic references to invoke package methods <ben@morrow.me.uk>
Re: Using symbolic references to invoke package methods (Tim McDaniel)
Re: Why does this code works without cat ? (Randal L. Schwartz)
Re: Why does this code works without cat ? (Randal L. Schwartz)
Re: Why does this code works without cat ? (Randal L. Schwartz)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 20 Apr 2012 04:59:44 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: A Design Pattern Question for Functional Programers
Message-Id: <2rj2p718thiteeff3qlhabsdrpe7p5emmd@4ax.com>
siva kkolundu <sivakkolundu1993@gmail.com> wrote:
>http:/[...]
Do you mind explaining how you got the idea that Perl is a functional
programming language?
After you do I may even click on that link which you dumped into this
NG.
jue
------------------------------
Date: Fri, 20 Apr 2012 13:55:05 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: A Design Pattern Question for Functional Programers
Message-Id: <4e91198c-7fed-4743-a1cd-d7cabdcf73e5@n22g2000yqb.googlegroups.com>
On Apr 20, 7:59=A0am, J=FCrgen Exner <jurge...@hotmail.com> wrote:
> Do you mind explaining how you got the idea that Perl is a functional
> programming language?
> After you do I may even click on that link which you dumped into this
> NG.
'Higher Order Perl' by Mark Jason Dominus.
This is available free as a PDF, but I bought a dead-tree version to
encourage the author, and I would encourage you to do the same.
CC.
------------------------------
Date: Sat, 21 Apr 2012 01:01:54 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Optionally avoid AutoLoader
Message-Id: <3fdabed8-0c72-4c86-bdda-43bf3e10326b@er9g2000vbb.googlegroups.com>
Hello,
I contribute to a family of CPAN packages which heavily use AutoSplit/
AutoLoader (ClearCase::Wrapper, ClearCase::Wrapper::MGi --
unfortunately, they interface a proprietary tool: IBM/Rational
ClearCase, so that you cannot really test the packages without a
ClearCase installation).
The autoload functionality is good and useful. I don't want to modify
it.
However, for development and debugging purposes, it would be useful to
temporarily override the autoloader.
Now, the modules are actually used through a command line driver (the
'cleartool wrapper'), which is part of ClearCase::Wrapper.
This package is rather stable, so the the one I want to develop and
debug is rather the (an)other one.
I could consider having an alternative driver, and installing it
beside the normal one.
What I don't really want is to have to modify part of the
ClearCase::Wrapper package while editing ClearCase::Wrapper::MGi.
My idea for the 'wrapdebug' driver would be to define there an
AUTOLOAD routine, and to inject its name into the space of
ClearCase::Wrapper (preempting AutoLoader::AUTOLOAD, which is 'used'
explicitely, in the standard way).
The problem I hit right away is that then, I'd need to access code
beyond the __END__ tag in the modules...
Is there a way to open that door? Did I miss an obvious corridor
before reaching this door?
Thanks,
Marc
------------------------------
Date: Fri, 20 Apr 2012 06:06:55 -0700 (PDT)
From: jhumanski <jhumanski@gmail.com>
Subject: Using symbolic references to invoke package methods - good or bad practice?
Message-Id: <fea779a7-3a9e-4bef-a367-0cf804609b97@m16g2000yqc.googlegroups.com>
At my place of employment, a philosophical discussion is going on
within the development group. Say you have the following package
definition:
package MyPackage;
use strict;
...
sub new {
my $class = shift;
my $self = bless {}, $class;
$self->_init();
return $self;
}
sub _init {
my $self = shift;
foreach my $property ('func1', 'func2', 'func3', 'func4') {
$self->$property();
}
}
sub func1 {...}
sub func2 {...}
sub func3 {...}
sub func4 {...}
In this example, the private method _init is invoking package methods
using symbolic references.
Many in the development team don't have a problem with this. They
consider it a clean and extendible solution. While they recognize
that symbolic references in general are bad, they justify this
solution by stating that the use of the symbolic references is
controlled and, hence, with little risk.
I am in the minority. I am looking for justification (other than the
standard mantra that symbolic references are bad) that this practice
should be discouraged. I have googled this topic but have not found
any specific examples that state why this practice is bad.
I am looking for this group's opinion. Any examples that demonstrate
why this is bad (or good) practice are appreciated.
------------------------------
Date: Fri, 20 Apr 2012 15:50:46 +0200
From: Peter Makholm <peter@makholm.net>
Subject: Re: Using symbolic references to invoke package methods - good or bad practice?
Message-Id: <87d372jyvd.fsf@vps1.hacking.dk>
jhumanski <jhumanski@gmail.com> writes:
> I am in the minority. I am looking for justification (other than the
> standard mantra that symbolic references are bad) that this practice
> should be discouraged. I have googled this topic but have not found
> any specific examples that state why this practice is bad.
You should not be generalizing solely based on a mantra. You need to
understand the reason for the mantra, that is you need to understand why
symbolic references are a bad idea.
Then you can discusse if the same reasons holds for method calls.
One reason not to like symbolic references is that they are only working
for package variables (globals) and silently ignores the existence of
lexical variables. Globals are as such discouraged for it own reasons,
and ignoring lexical variables can mean some action on a distance where
the meaning of code can change in a radical way due to seemingly
unrelated code changes.
This problem with symbolic references does not hold for methods as
lexical methods does not exists in the same way.
There are other problems with symbolic references. For some of them it
could be argued that it also applies to symbolic method calls other
problems can be dismissed.
In the end it is up to your team to decide if the advantages outweights
the problems.
//Makholm
------------------------------
Date: Fri, 20 Apr 2012 16:59:59 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Using symbolic references to invoke package methods - good or bad practice?
Message-Id: <87d372s8ao.fsf@sapphire.mobileactivedefense.com>
jhumanski <jhumanski@gmail.com> writes:
> At my place of employment, a philosophical discussion is going on
> within the development group. Say you have the following package
> definition:
>
> package MyPackage;
>
> use strict;
> ...
> sub new {
> my $class = shift;
>
> my $self = bless {}, $class;
> $self->_init();
> return $self;
> }
>
> sub _init {
> my $self = shift;
>
> foreach my $property ('func1', 'func2', 'func3', 'func4') {
> $self->$property();
> }
> }
>
> sub func1 {...}
> sub func2 {...}
> sub func3 {...}
> sub func4 {...}
>
> In this example, the private method _init is invoking package methods
> using symbolic references.
This is a standard, documented feature of Perl, cf
The right side of the arrow typically is the method name, but
a simple scalar variable containing either the method name or
a subroutine reference can also be used.
[perlobj(1)]
[...]
> I am looking for justification (other than the standard mantra that
> symbolic references are bad) that this practice should be
> discouraged.
If you have no idea why it should be discouraged, why should it be
discouraged?
------------------------------
Date: Fri, 20 Apr 2012 13:52:52 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Using symbolic references to invoke package methods - good or bad practice?
Message-Id: <87vckunvd7.fsf@stemsystems.com>
>>>>> "j" == jhumanski <jhumanski@gmail.com> writes:
j> package MyPackage;
j> sub new {
j> my $class = shift;
j> my $self = bless {}, $class;
j> $self->_init();
j> return $self;
j> }
j> foreach my $property ('func1', 'func2', 'func3', 'func4') {
j> $self->$property();
j> In this example, the private method _init is invoking package methods
j> using symbolic references.
to be accurate those are not symbolic references. methods are always
looked up in the symbol table (late binding) when they are called (there
is some caching for speed). lexical vars are handled at compile time and
so can be made strict which disallows symrefs in the proper sense.
the technique of using late binding of methods is actually a good one
and it can be very powerful. it can be seen as the method version of a
dispatch table which is for procedural calls.
j> Many in the development team don't have a problem with this. They
j> consider it a clean and extendible solution. While they recognize
j> that symbolic references in general are bad, they justify this
j> solution by stating that the use of the symbolic references is
j> controlled and, hence, with little risk.
your issue is not whether it is a good idea but conflating late binding
of method calls with symbolic references. they are not the same beast at
all and so they shouldn't be compared.
j> I am in the minority. I am looking for justification (other than the
j> standard mantra that symbolic references are bad) that this practice
j> should be discouraged. I have googled this topic but have not found
j> any specific examples that state why this practice is bad.
j> I am looking for this group's opinion. Any examples that demonstrate
j> why this is bad (or good) practice are appreciated.
it is used in many modules on cpan whereas symrefs are not commonly used
(except when actually munging the symbol table which should be their
only use). you may not find examples easily but they are out there. this
is a perfectly fine perl idiom so don't fret over it and just use it.
uri
------------------------------
Date: Fri, 20 Apr 2012 19:41:38 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Using symbolic references to invoke package methods - good or bad practice?
Message-Id: <28n869-lsd2.ln1@anubis.morrow.me.uk>
Quoth Uri Guttman <uri@stemsystems.com>:
> >>>>> "j" == jhumanski <jhumanski@gmail.com> writes:
>
> j> foreach my $property ('func1', 'func2', 'func3', 'func4') {
> j> $self->$property();
>
> j> In this example, the private method _init is invoking package methods
> j> using symbolic references.
>
> to be accurate those are not symbolic references. methods are always
> looked up in the symbol table (late binding) when they are called (there
> is some caching for speed). lexical vars are handled at compile time and
> so can be made strict which disallows symrefs in the proper sense.
>
> the technique of using late binding of methods is actually a good one
> and it can be very powerful. it can be seen as the method version of a
> dispatch table which is for procedural calls.
<what Uri said...>
I would consider this usage good style, under the appropriate
circumstances.
Ben
(...and of course, I would never even *consider* doing anything like
*{"$pkg\::$meth!before"} = sub {...};
...
my $mod = "$meth!before";
$obj->$mod(@args);
because that would just be Wrong... :).)
------------------------------
Date: Fri, 20 Apr 2012 21:07:54 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Using symbolic references to invoke package methods - good or bad practice?
Message-Id: <jmsj7a$sn0$1@reader1.panix.com>
I *wish* "use strict" would do more compile-time checking for subs.
But it doesn't flag anything for
foreach my $property (\&func1, \&func2, \&func5) {
...
sub func1 { print "func1\n"; }
sub func2 { print "func2\n"; }
sub func3 { print "func3\n"; }
until runtime, when it goes to call the missing func5.
Personally, I still prefer the explicit function reference, if for no
other reason that, even if you only look at
foreach my $property (\&func1, \&func2, \&func5) {
it's clearly a list of sub references and it's likely that they will
be called, but for
foreach my $property ('func1', 'func2', 'func5') {
you have to look down to see how $property is being used to know what
they are.
But I'm unusual in liking to be explicit about things: initializations
and uses and such. I like to use fully-qualified names like
ThisMod::ThatMod::SomeSub() even if there has been importing, just to
make it clear where it's from. Or
my @result = ();
just to make it clear that I've considered it and I do really need it
to be an empty array, or
{
my @working = ();
...
}
to make it clear where the variable dies.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Fri, 20 Apr 2012 22:36:38 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Using symbolic references to invoke package methods - good or bad practice?
Message-Id: <87hawe9jbt.fsf@sapphire.mobileactivedefense.com>
tmcd@panix.com (Tim McDaniel) writes:
> I *wish* "use strict" would do more compile-time checking for subs.
> But it doesn't flag anything for
>
> foreach my $property (\&func1, \&func2, \&func5) {
> ...
> sub func1 { print "func1\n"; }
> sub func2 { print "func2\n"; }
> sub func3 { print "func3\n"; }
>
> until runtime, when it goes to call the missing func5.
>
> Personally, I still prefer the explicit function reference, if for no
> other reason that, even if you only look at
> foreach my $property (\&func1, \&func2, \&func5) {
> it's clearly a list of sub references and it's likely that they will
> be called
That won't work in this case because it was about method calls, see
contrived example below:
-------------------
package Parent;
sub new {
return bless([], $_[0]);
}
sub blah
{
print("Blah!\n");
}
package Child;
our @ISA = qw(Parent);
sub blubb
{
print("Blubb!\n");
}
package main;
my $c = Child->new();
# call the method
#
$c->$_() for (qw(blubb blah));
# this doesn't work
#
eval {
$c->$_() for (\&blubb, \&blah);
};
print("$@");
# neither does this
#
eval {
$c->$_() for (\&Child::blubb, \&Child::blah);
};
print("$@");
------------------------------
Date: Fri, 20 Apr 2012 23:16:34 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Using symbolic references to invoke package methods - good or bad practice?
Message-Id: <jmsqoi$jgg$1@reader1.panix.com>
In article <87hawe9jbt.fsf@sapphire.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>tmcd@panix.com (Tim McDaniel) writes:
>> Personally, I still prefer the explicit function reference, if for no
>> other reason that, even if you only look at
>> foreach my $property (\&func1, \&func2, \&func5) {
>> it's clearly a list of sub references and it's likely that they will
>> be called
>
>That won't work in this case because it was about method calls, see
>contrived example below:
Summary of the example: Package Parent has blah(). Package Child ISA
Parent and adds blubb(). Instantiate Child->new().
In package main, plain \&blubb and \&blah don't work because they are
equivalent to \&main::blubb and \&main::blah, which don't exist.
\&Child::blubb and \&Child::blah don't work because &Child::blah
doesn't exist.
He didn't mention \&Parent::blubb and \&Parent::blah, but they
wouldn't work either, because &Parent::blubb doesn't exist and
(if Child were to redefine blah) &Parent::blah would bypass Child's
override.
But calling the literal strings 'blubb' and 'blah' work fine, and they
follow inheritance.
Well, blah! That's a "blah!" directed at Perl and the entire
situation, not at Rainer, who provided a most help example. Thank
you.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Sat, 21 Apr 2012 00:28:40 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Using symbolic references to invoke package methods - good or bad practice?
Message-Id: <828969-pog2.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
> I *wish* "use strict" would do more compile-time checking for subs.
> But it doesn't flag anything for
>
> foreach my $property (\&func1, \&func2, \&func5) {
> ...
> sub func1 { print "func1\n"; }
> sub func2 { print "func2\n"; }
> sub func3 { print "func3\n"; }
>
> until runtime, when it goes to call the missing func5.
This, I am afraid, is the price of using a dynamic language. Perl is
designed so that you can create new subs at runtime; therefore it can't
assume that, just because a sub doesn't exist at compile time, it won't
exist before you come to call it.
Apart from anything else, in the code above *none* of those functions
exist yet at the point where the reference expressions are compiled. If
you want to, you can explicitly check at runtime, just after you take
the reference, that the sub has been defined:
defined &$property or die "ref to an undefined sub";
You can extract the name of the sub from the reference using B, or using
Sub::Identify or Sub::Information which wrap that.
The behaviour of 'strict "subs"' and bareword sub calls in this regard
is something of an anomoly. That (sub-)pragma actually just makes you
quote your *strings*, and the 'guess if this is going to be a valid sub
at runtime by looking now, at compile time' logic happens regardless of
whether it is enabled or not.
(I sometimes wish Perl had a true 'no strict "subs"', which would let
me make bareword sub calls without forward declarations.)
I suppose if you really wanted to you could walk your package's symbol
table at (UNIT)CHECK time looking for stubs which haven't been filled.
It looks like B::LintSubs does something like this: you might find it
useful.
> Personally, I still prefer the explicit function reference, if for no
> other reason that, even if you only look at
> foreach my $property (\&func1, \&func2, \&func5) {
> it's clearly a list of sub references and it's likely that they will
> be called, but for
> foreach my $property ('func1', 'func2', 'func5') {
> you have to look down to see how $property is being used to know what
> they are.
Um... and you have to turn off 'strict "refs"', which is a much more
useful stricture?
> But I'm unusual in liking to be explicit about things: initializations
> and uses and such. I like to use fully-qualified names like
> ThisMod::ThatMod::SomeSub() even if there has been importing, just to
> make it clear where it's from.
That's sensible, sometimes. If I only use a function once or twice in a
large module I will often not import it and call it by its full name
instead. Especially if its unqualified name is something a little bit
too ambiguous, which happens sometimes.
> Or
> my @result = ();
> just to make it clear that I've considered it and I do really need it
> to be an empty array,
That's stupid. If you hadn't needed it to be an empty array you would've
assigned something to it.
I suspect this is a habit people get into when they are also in the
habit of declaring their variables too early. I rather rarely declare a
variable without also initialising it (to something useful), so a plain
my @result;
already screams 'watch out, this is going to have something stuffed into
it later' to me.
> or
> {
> my @working = ();
> ...
> }
> to make it clear where the variable dies.
The block is extremely sensible. Except where it causes so much clutter
it makes the code unreadable, you should put all your variables in the
smallest blocks you can. For one thing, it makes it very easy to dike
out a block or two and turn them into separate subs when the sub they're
in gets a bit long.
Ben
------------------------------
Date: Sat, 21 Apr 2012 00:36:57 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Using symbolic references to invoke package methods - good or bad practice?
Message-Id: <ph8969-pog2.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
> In article <87hawe9jbt.fsf@sapphire.mobileactivedefense.com>,
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> >tmcd@panix.com (Tim McDaniel) writes:
> >> Personally, I still prefer the explicit function reference, if for no
> >> other reason that, even if you only look at
> >> foreach my $property (\&func1, \&func2, \&func5) {
> >> it's clearly a list of sub references and it's likely that they will
> >> be called
> >
> >That won't work in this case because it was about method calls, see
> >contrived example below:
>
> Summary of the example: Package Parent has blah(). Package Child ISA
> Parent and adds blubb(). Instantiate Child->new().
>
> In package main, plain \&blubb and \&blah don't work because they are
> equivalent to \&main::blubb and \&main::blah, which don't exist.
> \&Child::blubb and \&Child::blah don't work because &Child::blah
> doesn't exist.
>
> He didn't mention \&Parent::blubb and \&Parent::blah, but they
> wouldn't work either, because &Parent::blubb doesn't exist and
> (if Child were to redefine blah) &Parent::blah would bypass Child's
> override.
Well, yes? Don't treat methods as though they were functions.
> But calling the literal strings 'blubb' and 'blah' work fine, and they
> follow inheritance.
Are you looking for ->can? This resolves the method and returns a
coderef: it's effectively the equivalent of \&foo for methods. (And,
just like \&foo, it will under some circumstances return a stub, which
may or may not turn out to resolve to a real method when you call it.)
(BTW, if you have a coderef $meth which references a method, it's better
style to call it like this
$obj->$meth(@args)
than like this
$meth->($obj, @args)
despite the fact that the method resolution has already been done so
those two calls do precisely the same thing.)
Ben
------------------------------
Date: Sat, 21 Apr 2012 00:23:11 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Using symbolic references to invoke package methods - good or bad practice?
Message-Id: <jmsulf$mig$1@reader1.panix.com>
In article <ph8969-pog2.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>Well, yes? Don't treat methods as though they were functions.
Well, when you see "sub foo", it kinda makes you think of functions
somehow ...
>Are you looking for ->can? This resolves the method and returns a
>coderef: it's effectively the equivalent of \&foo for methods. (And,
>just like \&foo, it will under some circumstances return a stub,
>which may or may not turn out to resolve to a real method when you
>call it.)
I had written a paragraph asking about that but deleted it before
posting. Congratulations on the telepathy!
For anyone else who hadn't heard of it, a little Web search shows that
it's in built-in class UNIVERSAL, so "man UNIVERSAL" or
http://perldoc.perl.org/UNIVERSAL.html
The doc mentions some concerns with AUTOLOAD, as you alluded to
above. I assume that, like any deep pointer, $obj->can has the
limitation that it's good only for the current state of $obj, so you
won't get a pointer with serious mojo that works even if $obj is later
changed to be some other type of object. CLASS->can works anyway.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Fri, 20 Apr 2012 21:37:13 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: Why does this code works without cat ?
Message-Id: <86lilpd7k6.fsf@red.stonehenge.com>
>>>>> "Eric" == Eric Pozharski <whynot@pozharski.name> writes:
Eric> However, redirection comes with little bonuses:
Eric> {23:1} [0:0]% perl -wle 'print -s STDIN' </etc/passwd
Eric> 1814
Eric> {2048:2} [0:0]% cat /etc/passwd | perl -wle 'print -s STDIN'
Eric> 0
You're confusing what -s can return on a pipe vs a file. Very different.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
------------------------------
Date: Fri, 20 Apr 2012 21:29:53 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: Why does this code works without cat ?
Message-Id: <86pqb1d7we.fsf@red.stonehenge.com>
>>>>> "xhoster" == xhoster <xhoster@gmail.com> writes:
xhoster> The point you so cleverly miss is that turning a cat into a
xhoster> grep is let easier, and less error-prone, than migrating a
xhoster> redirected file name from after the perl -e 'whatever' to
xhoster> before it, and adding a grep.
But you still don't need a cat.
On a sane shell, this works:
<somefile proggy arg arg
And when you want to turn that into a *concatenation* or a grep or other
filter, the file is already in teh right place.
No need for a useless use of cat.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
------------------------------
Date: Fri, 20 Apr 2012 21:38:09 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: Why does this code works without cat ?
Message-Id: <86hawdd7im.fsf@red.stonehenge.com>
>>>>> "Rainer" == Rainer Weikusat <rweikusat@mssgmbh.com> writes:
Rainer> [rw@sapphire]/tmp $perl -pe '' a
perl -perl a
:-)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
------------------------------
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 3670
***************************************
