[24769] in Perl-Users-Digest
Perl-Users Digest, Issue: 6922 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Aug 27 14:06:51 2004
Date: Fri, 27 Aug 2004 11:05:07 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 27 Aug 2004 Volume: 10 Number: 6922
Today's topics:
Re: exit(), die, ?? (Sara)
Re: exit(), die, ?? <nobull@mail.com>
Re: Larry Wall & Cults (Dr. Richard E. Hawkins)
Re: Object Oriented programs, Perl and others (Daniel Berger)
Re: Own module needs loaded module from main script (Bart Van der Donck)
Re: performance surprise -- why? ctcgag@hotmail.com
Re: Problem on Debian Linux Installing DBD-mysql <hal@thresholddigital.com>
Re: Reference to functions <nobull@mail.com>
Re: Resizing JPG images with Perl? <scobloke2@infotop.co.uk>
Re: split question ctcgag@hotmail.com
Re: start some actions with Perl without Cron? ctcgag@hotmail.com
Trapping Perl divide-by-zero exceptions using eval( ) (Griff)
Re: Trapping Perl divide-by-zero exceptions using eval( <gifford@umich.edu>
Re: Trapping Perl divide-by-zero exceptions using eval( <uri.guttman@fmr.com>
Re: using the result of a variable regular expression <nobull@mail.com>
Re: Xah Lee's Unixism <davids@webmaster.com>
Re: Xah Lee's Unixism ctcgag@hotmail.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 27 Aug 2004 08:07:48 -0700
From: genericax@hotmail.com (Sara)
Subject: Re: exit(), die, ??
Message-Id: <776e0325.0408270707.3cc291e1@posting.google.com>
tony@paradoxcommunity.com (Tony McGuire) wrote in message news:<f896a829.0408261454.57e649db@posting.google.com>...
> "Paul Lalli" <mritty@gmail.com> wrote in message news:<1RpXc.15136$IO1.1808@trndny03>...
> >
> > You should always make an attempt before asking if it's possible. You clearly
> > already know that the way to end a script is with either exit() or die() (based
> > on the subject of your post). So what happened when you tried putting exit() or
> > die() inside an if block?
> >
> > Paul Lalli
.
.
"die" IS a premature end to the script so that's normal message.
Don't worry about how you capitalize "PERL", most of us can parse your
spelling with /i and understand what you mean. Capitalization is one
of those cult things.
As for the execution path in your code, Perl has some very nice
capabilities to exit programs, subroutines, and loops asynchronously.
If you're used to c or many other languages, it's commonly difficult
to break out of a program, loop, or subroutine without somehow first
finding your way to the end of the block. not so in Perl. They made it
MUCH easier:
# Perl loop control, exit the iteration, the loop, or the whole
script!
for ( @bigArray)
{
next unless /./; # skip this iteration unless there is something
in the element
last if /^cat/; # jump out of the loop NOW if the line starts
with cat
exit if /^dog/ # jump out of the whole script if it starts with
dog
die "whoa a BAT!!!\n\n" if /^bat/ # error and jump out of the
script if it starts with dog
}
# Perl subroutine control
sub ILovePerl
{local $_ = $_[0];
return "lucky you!" if /ACE/; # go back to calling routine NOW
return "ohoh!" if /DUECE/; # go back to calling routine NOW
"soso!"; # default return value, the last lvalue is returned by
default
}
# Perl script control
.
.
die "of starvation" unless $food;
exit unless $cantFindTheDoor;
.
.
Hope this helps you.
G
------------------------------
Date: Fri, 27 Aug 2004 17:40:44 +0100
From: Brian McCauley <nobull@mail.com>
Subject: Re: exit(), die, ??
Message-Id: <cgnnuh$rue$1@sun3.bham.ac.uk>
Sara wrote:
> "die" IS a premature end to the script so that's normal message.
>
> Don't worry about how you capitalize "PERL", most of us can parse your
> spelling with /i and understand what you mean.
My spelling is very poor. I know most people can read what I write
nonetheless. This does not mean I should not attempt to spell correctly.
> Capitalization is one of those cult things.
s/cult/culture/
> As for the execution path in your code, Perl has some very nice
> capabilities to exit programs, subroutines, and loops asynchronously.
You do not mean 'asynchronously'.
> If you're used to c or many other languages,
Er, isn't it 'C' not 'c'? :-)
> sub ILovePerl
> {local $_ = $_[0];
Never use local($_) - I used to do it all the time before I discovered
how dangerous it was. Always use for() to localize $_ or use local(*_)
(after, of course, you've got what you need from @_).
Note using explicit subscripts on @_ is affected. Use a list assignment
or shift.
> return "lucky you!" if /ACE/; # go back to calling routine NOW
> return "ohoh!" if /DUECE/; # go back to calling routine NOW
> "soso!"; # default return value, the last lvalue is returned by
> default
> }
You do not mean 'lvalue'.
------------------------------
Date: Fri, 27 Aug 2004 15:24:43 +0000 (UTC)
From: hawk@slytherin.ds.psu.edu (Dr. Richard E. Hawkins)
Subject: Re: Larry Wall & Cults
Message-Id: <cgnjnr$1iu0$1@f04n12.cac.psu.edu>
In article <HvadnUsZ7IAwc7DcRVn-sQ@megapath.net>,
R Baumann <rynt@9yahoo.com> wrote:
>
>"Xah Lee" <xah@xahlee.org> wrote in message
>news:7fe97cc4.0408251356.34f2102a@posting.google.com...
>> Larry Wall and Cults
>> (Lazyness, Impatience and Hubris)
>> 200012
>In this context --- This is the STUPIDEST thing I've ever heard.
Nah. I practiced law for five years. :)
hawk
--
Richard E. Hawkins, Asst. Prof. of Economics /"\ ASCII ribbon campaign
dochawk@psu.edu 111 Hiller (814) 375-4846 \ / against HTML mail
These opinions will not be those of X and postings.
Penn State until it pays my retainer. / \
------------------------------
Date: 27 Aug 2004 08:48:02 -0700
From: djberg96@hotmail.com (Daniel Berger)
Subject: Re: Object Oriented programs, Perl and others
Message-Id: <6e613a32.0408270748.1f39e0fa@posting.google.com>
Matthew Braid <mb@uq.net.au.invalid> wrote in message news:<cgmffp$cg7$1@bunyip.cc.uq.edu.au>...
> Hi all,
>
> I've been spending a lot of time lately writing a lot of objects for a project
> here (so far about 60 objects and counting), and while I've been considering
> security the whole way I've started thinking one level down on how to secure
> objects from direct alteration if they were used as a library in some other
> code. (At the moment this isn't _really_ an issue as the packages are not
> available to users unless they go through controlled programs that don't allow
> unknown code to run).
>
> After tinkering, I've come up with the following pseudo-rules (please correct me
> if I'm wrong here, and preferably give me pointers :)
>
> 1. If an object inherits from another object (in perl), it is free to
> change/override any sub inside the parent.
>
> 2. There is no way to stop code from altering a class directly (eg, by doing
> something like 'sub Object::_internal { something_unexpected() }'
>
> 3. The fixes I've so far run across (my'd hashes keyed on blessed references to
> store instance data instead of using hashes for the base instance structure,
> my'd subroutines for truly private methods) work (well, as far as they can
> considering 1 and 2) but make inheritance an absolute nightmare - children can't
> get hold of parent's protected data. Writing accessor methods for them is
> problematic because of 2 - the accessor can be replaced to return something else.
>
> 4. Even if perl strictly adhered to OO paradigms I've learnt, some of these
> problems are very hard to fix.
>
> I've been thinking of theoretical ways to fix problems like this, and my
> amateurish ideas so far have been:
>
> 1. Closing packages - from then on, no other code can enter that package's
> namespace to specify subs, ie this:
>
> package Example is closed; # Made up syntax - maybe should be fatal if the
> # Example namespace already exists
> our($Bar) = '123';
> sub foo { ... }
>
> package main;
> sub Example::foo { ... } # Fatal - modify closed package
> sub Example::other { ... } # Fatal - add to closed package
> $Example::Bar = '321'; # OK - not changing a sub
>
> package OtherExample;
> use base qw/Example/;
>
> sub foo { ... } # OK - this is an override, doesn't
> # alter the Example package
>
> This could be expanded to making packages 'append only' (only new subs added) as
> well etc etc.
>
> 2. Closing subs - from then on, child packages and external code cannot override
> a particular sub:
>
> package Example;
>
> sub foo is closed { ... } # More made up syntax. Maybe a warning if
> # Example::foo is already defined
> sub bar { ... }
>
> package OtherExample;
> use base qw/Example/;
> sub foo { ... } # Fatal - the sub is closed and cannot be
> # overriden, even by children
> sub bar { ... } # OK
>
> package main;
> sub Example::foo { ... } # Fatal - same reason as above
>
> 3. 'Closed Object Families' or 'Willed Inheritance'. This one breaks the idea
> that a parent need not know anything about its children a bit, but it limits who
> can inherit from it:
>
> package Example wills qw(OtherExample # Made up syntax - 'wills'
> MoreExamples); # as in 'I hereby will my
> # stuff to the following
> # children...'
> ....
>
> package MoreExamples;
> use base qw/Example/; # OK - this is one of our 'trusted' children
> ....
>
> package UnexpectedExample;
> use base qw/Example/; # Fatal - not one of our trusted children, not allowed
> # to inherit.
>
> Using mixes of these, you can start to be confident to write accessors for
> objects for finding out if they can do something potentially dangerous, or for
> accessors to find out parameters for potentially dangerous actions, eg:
>
> package Example is closed, wills qw(OtherExample);
> my %Private;
> sub new {
> my $class = shift;
> my $self = bless('', $class); # short version :)
> $Private{$self} = {CanDelete => 0,
> ID => 'someid'};
> return $self;
> }
> sub can_delete is closed {
> my $self = shift;
> return 0 if not exists $Private{$self}; # Safe default
> return $Private{$self}{CanDelete};
> }
> sub do_delete {
> my $self = shift;
> return 0 if not $self->can_delete;
> # Do the delete...
> return 1;
> }
>
> Now instances of Example and OtherExample can safely assume that:
>
> $eg->can_delete
>
> hasn't been overridden like:
>
> sub Example::can_delete { return 1 }
>
> (and do_delete hasn't been modified by 'untrusted' code), so can be used in
> arbitrary code as library code (...I think :) )
>
> This is all just musings off the top of my head - for all I know perl has some
> of this already that I don't know about, and I haven't descended to the level
> below (how can I be sure the user loaded the right module and not something from
> a private directory etc), _and_ nothing here defines what happens if a package
> tries to inherit from a package that has inherited from a _willed_ package (sheesh!)
>
> All up I think I've been thinking too much about this stuff anyway :)
>
> MB
If you want an OO scripting language *today* consider Ruby or Python.
Lord only knows when Perl6 will be out.
Regards,
Dan
------------------------------
Date: 27 Aug 2004 10:30:44 -0700
From: bart@nijlen.com (Bart Van der Donck)
Subject: Re: Own module needs loaded module from main script
Message-Id: <b5884818.0408270930.fb3487f@posting.google.com>
Thanks to both posters.
I was not entirely right about the error report. Script didn't say
that the module was not loaded (however it was the cause why it
failed).
Gunnar wrote:
> What happens if you include "use DBI;" in
> NameOfModule.pm as well is that you import possible symbols that are
> exported by default. DBI.pm is not compiled once again.
OK that's great. That solves my original concern about the waste of
memory and compiling the same module again (as I thought it would).
I did some further research and come to odd results.
-------------------------------------
This is always present in main script
-------------------------------------
use DBI;
use lib '/path/to/my/own/modules/';
use DBconf; # own module
&DBconf::DBvars(); # returns hash with configuration values
use MyModule; # own module
----------------------
Case 1: MyModule has:
----------------------
use DBconf;
&DBconf::DBvars();
Result of case 1: script OK.
----------------------
Case 2: MyModule has:
----------------------
&DBconf::DBvars();
Result of case 2: Error: Can't call method "prepare" on an undefined
value at /some/path/MyModule.pm line 22.
Line 22 is the first connection string towards MySQL. DBconf::DBvars()
should have given the connection parameters, but obviously it returned
empty values. It probably needs "use DBconf;" first, I'ld say.
----------------------
Case 3: MyModule has:
----------------------
use DBconf;
Result of case 3: script OK
Odd, I didn't even invoke DBconf::DBvars() !
--------------------------------------
Case 4: No modules invoked by MyModule
--------------------------------------
Result of case 4: Error: Can't call method "prepare" on an undefined
value at /some/path/MyModule.pm line 22.
I believe the situation is the same as in case 2.
---
It's unclear for me to draw a line in these results. Seems that I need
to invoke "use DBconf;", but without need to call sub
"&DBconf::DBvars();" (?)
Following calls apparently don't need to take place (script works fine
with or without these):
use DBI;
use lib '/path/to/my/own/modules/';
...which is not very logical, presuming that I do need "use DBconf;".
I am thinking about the construction of my module DBconf and the way
it exports its variables. AFAIK, this is all pretty default (shortened
code):
package DBconf;
require Exporter;
@ISA = qw(Exporter);
@EXPORT = qw(%CONFIG);
@EXPORT_OK = qw(%CONFIG);
sub DBvars
{ %CONFIG = (first=>"1",second=>"2"); }
1;
Best regards
Bart
------------------------------
Date: 27 Aug 2004 16:50:19 GMT
From: ctcgag@hotmail.com
Subject: Re: performance surprise -- why?
Message-Id: <20040827125019.476$pG@newsreader.com>
Joe Davison <haltingNOSPAM@comcast.net> wrote:
>
> So, say I do use English qw( -no_match_vars). I presume I'd still be
> able to use the non-english versions to access the match variables,
> should the need arise? RTFM, aye.
Yes and no. You could still use them, but it would have a poor effect
on performance. Using the match variables anywhere causes all regex to
slow down[1]. And apparently "use English" triggers this same penalty
even if you don't use explicitly use the match variables anywhere. So you
could use them, but would get the same performance problem.
Xho
[1] The docs say they slow down all regex in the program, but I think one
of the smarty-pants here said it actually only slows down all regex in the
scopes containing the use.
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Fri, 27 Aug 2004 11:42:39 -0400
From: Hal Vaughan <hal@thresholddigital.com>
Subject: Re: Problem on Debian Linux Installing DBD-mysql
Message-Id: <FpednWXbZZPxx7LcRVn-qA@comcast.com>
Guy Smiley wrote:
> "Hal Vaughan" <hal@thresholddigital.com> wrote in message
> news:kYCdnV-PPICbTLPcRVn-gw@comcast.com...
>
>> I'm not using the MySQL server on this computer, but I am using the
>> client to connect to MySQL on another system.
>
> AFAIK, you definately need the server onboard in order to install the
> dbd-mysql. I run libranet also and use apt-get like I would if it was a
> regular Debian install
>
> apt-get mysql-server
> apt-get libdbd-mysql-perl
I checked to see if mysql-server was installed -- yep. I had added
libdbd-mysql-perl myself. It's still not working.
Was that all you needed to do and is it working for you?
Hal
> For more information see:
>
http://packages.debian.org/cgi-bin/search_packages.pl?keywords=mysql&searcho
> n=names&subword=1&version=all&release=all
------------------------------
Date: Fri, 27 Aug 2004 17:28:22 +0100
From: Brian McCauley <nobull@mail.com>
Subject: Re: Reference to functions
Message-Id: <cgnn7a$rh4$1@sun3.bham.ac.uk>
Bernard El-Hagin wrote:
> "Paul Lalli" <mritty@gmail.com> wrote:
>
>>You don't. That's specifically the kind of thing use strict;
>>exists to prevent. [...]
>
> It's *one of several* kinds of things use strict exists to prevent.
> Not a nitpick. That kind of statement would have confused me to no
> end back when I was starting out with Perl. :)
[ Your smiley has no nose, how does it smell?... ]
Not to nitpick but strict prevents 3 kinds of things and I've always
considered "several" to start not lower than 4. :-)
------------------------------
Date: Fri, 27 Aug 2004 16:54:53 +0000 (UTC)
From: Ian Wilson <scobloke2@infotop.co.uk>
Subject: Re: Resizing JPG images with Perl?
Message-Id: <cgnp0t$sbu$1@titan.btinternet.com>
Randal L. Schwartz wrote:
> *** post for FREE via your newsreader at post.newsfeed.com ***
>
>
>>>>>>"Patrice" == Patrice Auffret <patrice.auffret@intranode.com> writes:
>
>
> Patrice> And what about Gimp::* hierarchy ? Have someone in this group
> Patrice> ever tested it ? (I'm curious about it, maybe I'll have to use
> Patrice> it one day).
>
> I've had all of like an hour with the Gimp on my screen. With the
> Gimp being fairly underdocumented, always in motion, and still lagging
> about 4 years behind Photoshop, there's no reason for me to not use
> "the real thing".
>
Blimey, there's a Photoshop::* module?
;-)
--
Ian
Just arranging Perl hopelessly.
------------------------------
Date: 27 Aug 2004 17:05:39 GMT
From: ctcgag@hotmail.com
Subject: Re: split question
Message-Id: <20040827130539.935$CE@newsreader.com>
Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
> Tore Aursand wrote:
> >
> > Untested:
> >
> > #!/usr/bin/perl
> > #
> > use strict;
> > use warnings;
> > use Data::Dumper;
> >
> > my $string = 'abc def ghi jkl';
> > my @parts = split( /\s+/, $string, 2 );
> >
> > print Dumper( \@parts );
>
> Why on earth do you use Data::Dumper to print a two elements array?
What would you suggest? As far as I know, it is the only easy way to print
an array which makes it crystal clear where the boundaries between
elements are, and what weird characters there may be, and if there is
leading or trailing whitespace, and...
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 27 Aug 2004 17:39:59 GMT
From: ctcgag@hotmail.com
Subject: Re: start some actions with Perl without Cron?
Message-Id: <20040827133959.962$KR@newsreader.com>
"PHP2" <gp@nospm.hr> wrote:
> is possible start some actions with Perl without Cron?
>
> for example send email to users from database after 3 days
3 days after *what*?
> or delete
> something from database automaticaly after 3 day with Perl but without
> Cron?
Well, I probably wouldn't use Cron as a general engine to do this anyway.
I don't think Cron is made to handle tens of thousands of tasks on a
one-off basis. I might use cron to fire some bulk-processing script, but
certainly not each individual action.
while (1) {
make_connection_if_not_valid($dbh);
$dbh->do('delete from foo where bar < date_add(now(),interval -3 day)');
## specifics vary with DBMS
sleep 1800;
};
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 27 Aug 2004 08:25:01 -0700
From: griffph@aol.com (Griff)
Subject: Trapping Perl divide-by-zero exceptions using eval( )
Message-Id: <d698d3e7.0408270725.9cae150@posting.google.com>
Why is it that this code produces a trappable exception -
#--------------------------------
$b = 1;
$c = 0;
eval { $b / $c ; } ;
if ($@)
{
print "I caught an exception\n";
print $@;
}
#--------------------------------
but this code seems to crash without catching the exception -
eval { 1 / 0 ; } ;
if ($@)
{
print "I caught an exception\n";
print $@;
}
I know that the second piece of code is even dumber than the first,
but just wondered what the difference was between the errors produced.
Thanks - Griff
------------------------------
Date: Fri, 27 Aug 2004 11:52:02 -0400
From: Scott W Gifford <gifford@umich.edu>
Subject: Re: Trapping Perl divide-by-zero exceptions using eval( )
Message-Id: <qsz8yc0o9y5.fsf@mspacman.gpcc.itd.umich.edu>
griffph@aol.com (Griff) writes:
[...]
> but this code seems to crash without catching the exception -
>
> eval { 1 / 0 ; } ;
>
> if ($@)
> {
> print "I caught an exception\n";
> print $@;
> }
>
> I know that the second piece of code is even dumber than the first,
> but just wondered what the difference was between the errors
> produced.
My guess is that this error is produced at compile-time, when the Perl
compiler is calculating constant expressions and your code isn't yet
running. If you eval 1/0 in a string you get a runtime exception, and
if there are any variables at all in the expression (even $a/0) you
get a runtime exception, which seems to support this theory.
For a more definitive answer somebody will probably have to delve into
Perl's guts.
----ScottG.
------------------------------
Date: Fri, 27 Aug 2004 12:53:50 -0400
From: Uri Guttman <uri.guttman@fmr.com>
Subject: Re: Trapping Perl divide-by-zero exceptions using eval( )
Message-Id: <li4qmoy129.fsf@fmr.com>
>>>>> "G" == Griff <griffph@aol.com> writes:
G> Why is it that this code produces a trappable exception -
G> #--------------------------------
G> $b = 1;
G> $c = 0;
G> eval { $b / $c ; } ;
G> but this code seems to crash without catching the exception -
G> eval { 1 / 0 ; } ;
G> I know that the second piece of code is even dumber than the first,
G> but just wondered what the difference was between the errors produced.
the latter is executed at compile time as perl does constant folding. so
the eval hasn't been compiled yet and can't be run.
uri
------------------------------
Date: Fri, 27 Aug 2004 17:22:05 +0100
From: Brian McCauley <nobull@mail.com>
Subject: Re: using the result of a variable regular expression
Message-Id: <cgnmri$r8c$1@sun3.bham.ac.uk>
Following up in the wrong part of this thread Sara wrote:
> leifwessman@hotmail.com wrote in message news:<cgl2im$tru@odak26.prod.google.com>...
>
>>if ($numb == 1) {
>>print $1;
>>} elsif ($numb == 2) {
>> print $2;
>>} elsif ($numb == 3) {
>> print $3;
>>}
>
> Interesting question. As pointed out, $$numb will work nicely for you.
For certain values of "nice".
> The odd thing being that this LOOKS like a scalar dereference, which
> it really isn't
Yes it is. It's a scalar dereference of a _symbolic_ reference.
> since 2 isn't the memory location of the value.
If it were a _hard_ scalar reference then its numeric value would be the
address in memory.
> Seems like there is an ambiguity in there somewhere but I can't pinpoint it.
No ambiguity. Perl's scalar values can contain either ordinary
strings/numbers or they can contain hard references. It is possible to
convert a hard reference[1] into an address in memory simply by using it
in a numeric context. It is not possible to go the other way[4]. If
you use a non-reference in a reference context then it will never be
treated as a memory address - it will be converted into a string and
looked up in the symbol table - i.e. it will be a symbolic reference.
Of course most of the time one has "strict qw(refs)" in effect which
causes symbolic references to be diallowed except in a few special
cases[2].
[1] (other than one to an overloaded type object)
[2] To do with symbolic CODErefs[3].
[3] And due to a bug any symrefs resolved at compile-time.
[4] In Perl - you can of course do anything you want by dropping down
into C.
------------------------------
Date: Fri, 27 Aug 2004 10:33:09 -0700
From: "David Schwartz" <davids@webmaster.com>
Subject: Re: Xah Lee's Unixism
Message-Id: <cgnr8l$egb$1@nntp.webmaster.com>
"Pascal Bourguignon" <spam@mouse-potato.com> wrote in message
news:878yc0ucyl.fsf@thalassa.informatimago.com...
> Kenny Tilton <ktilton@nyc.rr.com> writes:
>> >>What you mean with Unixism?
>> > repeated accidents. Such a tool would
>> > first chop off the user's brain, molding
>> > a mass of brainless imbeciles and
>> > microcephalic charlatans the likes of
>> > Larry Wall and Linus Torvald jolly
>> > Server: Apache/2.0.50 (Fedora)
>> > ^^^^^^^^^^^^^^^^^^^^^^
>>
>> So you like my approach, which is to condemn things they have never used?
>>
>> :)
>
> No, that of no more using things that you condemn.
I don't follow you at all. I think you'll find the most useful,
meaningful complaints about, say, a Ford Explorer from the people who drive
one every day.
DS
------------------------------
Date: 27 Aug 2004 17:54:23 GMT
From: ctcgag@hotmail.com
Subject: Re: Xah Lee's Unixism
Message-Id: <20040827135423.154$1T@newsreader.com>
"David Schwartz" <davids@webmaster.com> wrote:
> "Pascal Bourguignon" <spam@mouse-potato.com> wrote in message
> news:878yc0ucyl.fsf@thalassa.informatimago.com...
>
> > Kenny Tilton <ktilton@nyc.rr.com> writes:
>
> >> >>What you mean with Unixism?
> >> > repeated accidents. Such a tool would
> >> > first chop off the user's brain, molding
> >> > a mass of brainless imbeciles and
> >> > microcephalic charlatans the likes of
> >> > Larry Wall and Linus Torvald jolly
> >> > Server: Apache/2.0.50 (Fedora)
> >> > ^^^^^^^^^^^^^^^^^^^^^^
> >>
> >> So you like my approach, which is to condemn things they have never
> >> used?
> >>
> >> :)
> >
> > No, that of no more using things that you condemn.
>
> I don't follow you at all. I think you'll find the most useful,
> meaningful complaints about, say, a Ford Explorer from the people who
> drive one every day.
And if they continue to drive one everyday, perhaps you would conclude
that their complaints are insincere.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
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 V10 Issue 6922
***************************************
