[12055] in Perl-Users-Digest
Perl-Users Digest, Issue: 5656 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri May 14 03:07:35 1999
Date: Fri, 14 May 99 00:01:44 -0700
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, 14 May 1999 Volume: 8 Number: 5656
Today's topics:
FMTEYEWTK on Managing Class Data (draft) <tchrist@mox.perl.com>
Re: Help with CGI Script Required! (Jon Orwant)
Re: Help with CGI Script Required! (Tad McClellan)
Help! sendmail problems <whitwam@magma.NOSPAM.ca>
Re: How can i write perl script and ouput the base dire (Austin Ming)
Re: How to mail html files? jmsinstl@my-dejanews.com
Re: imbedded subroutine (Andrew Allen)
Re: Mac System calls (Chris Nandor)
man pages and FAQs: why posted? (Lee)
Re: man pages and FAQs: why posted? (Greg Bacon)
NET::IRC question (markus)
Re: Net::Telnet Module Question <jay@rgrs.com>
Re: Newbie question on CGI developing <aqumsieh@matrox.com>
Re: Newbie question on CGI developing (Charles R. Thompson)
Re: Newbie question on CGI developing (Tad McClellan)
Next line <ceedas@my-dejanews.com>
Re: Next line (Robert Watkins)
Re: OPEN command doesn't work on NT machine <swarren@www.wwwdotorg.org>
Re: Oraperl help - inserting perl vars (John D Groenveld)
Special: Digest Administrivia (Last modified: 12 Dec 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 13 May 1999 15:33:18 -0700
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: FMTEYEWTK on Managing Class Data (draft)
Message-Id: <373b451e@cs.colorado.edu>
There is far more than one way to do this: I can think of many *many*
ways to store "class data"! Keep these in mind:
*) I use the hypothetical our() syntax for package variables.
It works like use vars, but looks like my(). It should be 5.006,
I hope.
*) The usual mealy-mouthed package mungeing doubtless
applies. For example, $self->{ObData1} should
probably be $self->{ __PACKAGE__ . "_ObData1" }
but that would just confuse the examples.
1) Make methods that access the class data directly. Class data will
reside in the compiling package's symbol table, and we'll use
fully-qualified package names to access it. These versions entirely
ignore their obclass (object reference or classname) argument.
package ClassName;
sub CData1 {
my $obclass = shift; # XXX: unused
$ClassName::CData1 = shift if @_;
return $ClassName::CData1;
}
sub CData2 {
my $obclass = shift; # XXX: unused
$ClassName::CData2 = shift if @_;
return $ClassName::CData2;
}
Issues:
By fully qualifying the package variables, they stand out
clearly when reading the code.
If you misspell one of these, it's hard to catch, because
use strict isn't there to help you. -w can be, though.
A derived class will inherit these methods, and consequently
get the versions in the base class's package. This is not
necessarily intuitive.
It's easy to dump the state of all the package variables if you're
implementing a persistent class using an external mechanism,
since they can access the package data perfectly well.
The XXX makes you go "hm...."
2) Same as the previous one, except we declare our package variables
so that they work under use strict and catch typos. This takes are
of the first issue raised in the previous example:
package ClassName;
our($CData1, $CData2);
sub CData1 {
my $obclass = shift; # XXX: unused
$CData1 = shift if @_;
return $CData1;
}
sub CData2 {
my $obclass = shift; # XXX: unused
$CData2 = shift if @_;
return $CData2;
}
Issues:
By no longer fully qualifying the package variables, their
significance can be lost when reading the code.
A derived class will inherit these methods, and consequently
get the versions in the base class's package. This is not
necessarily intuitive.
It's easy to dump the state of all the package variables if you're
implementing a persistent class using an external mechanism,
since they can access the package data perfectly well.
The XXX makes you go "hm...."
3) Modify the previous strategy to use lexicals instead of package
variables.
Some folks get the heebie-jeebies when they see package variables
hanging out there for anyone to reach in and diddle. (The Config.pm
module has a package variable, %Config::Config, which it exports --
but it's really a tied hash, so access is still mediated.) Perl
doesn't really care one way or another, but we can make these people
less edgy by making the package variables into lexicals at the file
scope.
package ClassName;
my($CData1, $CData2);
sub CData1 {
my $obclass = shift; # XXX: unused
$CData1 = shift if @_;
return $CData1;
}
sub CData2 {
my $obclass = shift; # XXX: unused
$CData2 = shift if @_;
return $CData2;
}
Issues:
No one above or below can reach in and diddle the class state
without the documented interface interceding.
Anything in the same scope (the rest of the file) can see
those variables, so the other code in this file can diddle
the data if they care to.
A derived class will inherit these methods, and consequently
get the versions in the base class's package. This is not
necessarily intuitive.
It's no longer easy to dump the state of the class data
using an external persistence mechanism, because nobody can see in
to the lexicals. It would not be terribly hard to create a separate
class method to do so, however, since all the lexical class
data is still in the file scope. (This assumes you haven't
split your class across separate file scopes.)
The XXX makes you go "hm...."
4) Modify the previous version by creating a new scope to
surround each class method and its affilated datum.
package ClassName;
{ # scope for hiding $CData1
my $CData1;
sub CData1 {
my $obclass = shift; # XXX: unused
$CData1 = shift if @_;
return $CData1;
}
}
{ # scope for hiding $CData2
my $CData1;
sub CData2 {
my $obclass = shift; # XXX: unused
$CData2 = shift if @_;
return $CData2;
}
}
Issues:
A derived class will inherit these methods, and consequently
get the versions in the base class's package. This is not
necessarily intuitive.
It is now darnright difficult to dump out all the class data
transparently, such as for debugging or persistence. You're going
to have to politely call each class accessor one at a time to
get it to divulge its state.
No one -- absolutely no one -- is allowed to diddle the class
data without the mediation of the managing accessor method,
since they and they alone can see their respective data.
Note that this use of mediated access to class data is far
stronger privacy than most OO languages provide. A black
hole is more apt to bleed data than are lexical closures.
Perl's flexility is such that you can make classes that are
even more privacy freaked than you can is oft-touted systems
with mixed private, partial, protected, public, persnickety,
friend, and foe datum attributes.
The XXX still makes you go "hm...."
5) Keep one whole separate structure (something of a "class metaobject",
but unblessed) as either a file-scoped lexical:
package ClassName;
my $CObj = {
CData1 => '',
CData2 => '',
};
sub CData1 {
my $obclass = shift; # XXX: unused
$CObj->{CData1} = shift if @_;
return $CObj->{CData1};
}
sub CData1 {
my $obclass = shift; # XXX: unused
$CObj->{CData2} = shift if @_;
return $CObj->{CData2};
}
Issues:
A derived class will inherit these methods, and consequently
get the versions in the base class's package. This is not
necessarily intuitive.
Any parts of this class (or any other!) at the file scope can
still access the class data without mediation.
Parts of the class in another file (don't do that!) can't
access the class data, because it's associated not with
the package but the file.
(Remember that a module has both package (symbol table)
componentry and file scope (private lexicals) componentry,
and while most people one module using one package and one
file, and nothing else sharing these, there's no law that
says you have to do it that way. TMTOWTDI.)
All the class data is grouped together, making it easy
to find, alter, etc.
While an external dumper can't get at the class metaobject,
it's pretty easy to create a "dump state" class method for
debugging or persistence, since the class metaobject is visible
to the whole file.
The XXX still makes you go "hm...."
6) Same as previous, but hide the class metaobject in its own scope
so the regular accessors and other instance methods can't
get at the thing without mediation.
package ClassName;
{ # scope for class metaobject
my $CObj = {
CData1 => '',
CData2 => '',
};
sub CData1 {
my $obclass = shift; # XXX: unused
$CObj->{CData1} = shift if @_;
return $CObj->{CData1};
}
sub CData1 {
my $obclass = shift; # XXX: unused
$CObj->{CData2} = shift if @_;
return $CObj->{CData2};
}
}
Issues:
A derived class will inherit these methods, and consequently
get the versions in the base class's package. This is not
necessarily intuitive.
Nothing but the class metaobject's own accessor methods can
get at the class attributes without mediation.
Any class accessor method can get at any class datum
without recourse to mediation.
All the class data is grouped together, making it easy
to find, alter, etc.
While an external dumper can't get at the class metaobject, it's
pretty easy to create a "dump state" class method (inside the
class metaobject scope) for debugging or persistence, since the
class metaobject is visible to the whole file.
The XXX still makes you go "hm...."
7) And now for something rather different. We'll make the
(unblessed) "class metaobject" a package variable of the same name as
the package itself. In our case, that's %ClassName::ClassName.
This is reminiscent of classes that use &ClassName::ClassName for
their constructors.
package ClassName;
use strict;
# create class metaobject of the most perfect name
our %ClassName = (
CData1 => '',
CData2 => '',
);
no strict 'refs';
sub CData1 {
my $self = shift;
$self = ref $self if ref $self;
$self->{CData1} = shift if @_;
return $self->{CData1};
}
sub CData1 {
my $self = shift;
$self = ref $self if ref $self;
$self->{CData2} = shift if @_;
return $self->{CData2};
}
use strict 'refs';
Issues:
There is no more hmmming over XXX crud! Hurray!
A derived class will inherit these methods, but will intuitively
set the state vraiables in their *derived* class's package, not
in the package in which the methods were compiled as all
suggestions previous to this dubiously did.
It's easy to dump the class state using an external mechanism,
since the class metaobject is 1) a package variable 2) has a
well-known name 3) clusters all of its data together.
If you call an accessor method that's expecting to manipulate
instance data on the class name, you'll take an exception because
we turned strict refs back on again right after the class
accessor method
8) This next example is just like the previous one, save that we
do some oddness to dodge the strict refs issue.
package ClassName;
our %ClassName = (
CData1 => '',
CData2 => '',
);
sub _classobj {
my $self = shift;
$self = ref $self if ref $self;
no strict 'refs';
return \%{ ${self}::${self} };
}
sub CData1 {
my $self = shift->classobj();
$self->{CData1} = shift if @_;
return $self->{CData1};
}
sub CData1 {
my $self = shift->classobj();
$self->{CData2} = shift if @_;
return $self->{CData2};
}
Issues:
This version still does the intuitive thing with inheritance,
affecting the class metaobject in the actual class.
We're now 'use strict' clean, but preserve the elegance
of using our eponymous %ClassName metaobject.
It's easy to dump the class state using an external mechanism,
since the class metaobject is 1) a package variable 2) has a
well-known name 3) clusters all of its data together.
9) This time, we repent of symbol table poking and symrefs.
Much of the rest is similar.
package ClassName;
{ scope for class obj
my $CObj = {
CData1 => '',
CData2 => '',
};
sub _classobj {
my $self = shift; # XXX: unused
return $CObj;
}
}
sub CData1 {
my $self = shift->classobj();
$self->{CData1} = shift if @_;
return $self->{CData1};
}
sub CData1 {
my $self = shift->classobj();
$self->{CData2} = shift if @_;
return $self->{CData2};
}
Issues:
This version still does the intuitive thing with inheritance,
affecting the class metaobject in the actual class, not the
class into which the method was compiled.
That XXX stuff is back, but I think it's ok this time.
It's no longer so easy to get at the class metaobject
to dump or debug the class state. It's not too hard,
either, though, since there's no requirement that the
&_classobj method be called from the same package. The
paranoid might try this:
sub _classobj {
my $self = shift; # XXX: unused
die "tsk" unless __PACKAGE__ eq caller();
return $CObj;
}
But there are still no assurances, so it signifies nothing.
10) Now, consider a variation on the themes elaborated above
in which all accessor calls can be called on either an obref or on
a classname. This gives a kind of pass-through behaviour to the
class meta-object if the instance has not that field of its own.
use ClassName;
ClassName->color("red");
$ob1 = ClassName->spawn(); # "inherits" red
$ob2 = ClassName->spawn(); # "inherits" red
$ob3 = ClassName->spawn(); # "inherits" red
$ob3->color("green"); # now green
$ob4 = $ob3->spawn(); # this guy green, too.
ClassName->color("blue"); # change global colors
# now $ob1 and $ob2 are blue, but $ob3 and $obj4 still green
$ob3->color("violet"); # did $obj4 change?
My take on $ob4's color is that it will still be green, not
violet, because it took it from a discrete instantiated
parent, not from the meta-object.
That could be simply set up in this way:
package ClassName;
no strict 'refs';
our %ClassName = (
color => 'beige',
popcount => 0,
);
# constructor
sub spawn {
my $obclass = shift;
my $self = {};
(ref $obclass || $obclass)->{popcount}++;
%$self = %$obclass if ref $obclass; # copy protos
return bless $self => ref($obclass) || $obclass;
}
# access class or object data
sub color {
my $self = shift;
if (ref $self) {
$self->{"color"} = shift if @_;
return defined $self ->{"color"}
? $self ->{"color"}
: (ref $self)->{"color"}
}
else {
$self->{"color"} = shift if @_;
return $self->{"color"}
}
die "not reached";
}
# access class data
sub population {
my $self = shift;
return (ref $self)->{"popcount"};
}
# destructor
sub DESTROY {
my $self = shift;
(ref $self)->{popcount}--;
}
Issues:
This version seems most perlish and least C++ish, which I deem
a feature. It could of course be honed into the privacy paranoia
as in some of the preceding examples, but that is not particularly
perlian either.
Inquisitive people can get at the class metaobject easily.
This means that it's easy to dump the class state using an
external mechanism, since the class metaobject is 1) a package
variable 2) has a well-known name 3) clusters all of its data
together.
You could tighten this up for strict refs or for abject privacy
using the techniques described in previous examples.
11) Use one generic function that access all class data, and
hide those data in a lexical scoped to that function alone.
package ClassName;
{
my $CObj = {
CData1 => '',
CData2 => '',
};
sub classdata {
my($proto, $datum, $newval) = @_;
die "No such class datum: $datum"
unless exists $CObj{$datum};
$CObj{$datum} = $newval if @_ > 2;
return $CObj{$datum};
}
}
#...and later...
my $obj = ClassName->new();
ClassName->classdata(CData1 => val1);
print $obj->classdata('CData2');
12) Keep a reference to each class datum on the object. This is
a strategy you've seen before, although there may be twists you
haven't thought of here.
package ClassName;
our($CData1, $CData2);
sub new {
my $obclass = shift;
return bless my $self = {
ObData1 => '',
ObData2 => '',
CData1 => \$CData1,
CData2 => \$CData2,
} => (ref $obclass || $obclass);
}
sub ObData1 {
my $self = shift;
$self->{ObData1} = shift if @_;
return $self->{ObData1};
}
sub ObData2 {
my $self = shift;
$self->{ObData2} = shift if @_;
return $self->{ObData2};
}
sub CData1 {
my $self = shift;
my $dataref = ref $self
? $self->{CData1}
: \$CData1;
$$dataref = shift if @_;
return $$dataref;
}
sub CData2 {
my $self = shift;
my $dataref = ref $self
? $self->{CData2}
: \$CData2;
$$dataref = shift if @_;
return $$dataref;
}
Issues:
A derived class will inherit these methods, and consequently
get the versions in the base class's package. This is not
necessarily intuitive.
There is no check that the object accessor methods have not
been called on the classname. If strict refs are on, you'd
blow up. If not, you get the eponymous metaobject. What you
do with -- or about -- this is up to you; previous examples
should suggest tricks and treatments respectively.
13) This is like the previous version, but we use the eponymous metaobject
this time, and are careful about accessing the right package data.
package ClassName;
our %ClassName = (
CData1 => '',
CData2 => '',
);
sub _classobj {
my $self = shift;
$self = ref $self if ref $self;
no strict 'refs';
return \%{ ${self}::${self} };
}
sub new {
my $obclass = shift;
my $classobj = $obclass->_classobj();
bless my $self = {
ObData1 => '',
ObData2 => '',
CData1 => \$classobj->{CData1},
CData2 => \$classobj->{CData2},
} => (ref $obclass || $obclass);
return $self;
}
sub ObData1 {
my $self = shift;
$self->{ObData1} = shift if @_;
return $self->{ObData1};
}
sub ObData2 {
my $self = shift;
$self->{ObData2} = shift if @_;
return $self->{ObData2};
}
sub CData1 {
my $self = shift;
$self = $self->_classobj() unless ref $self;
my $dataref = $self->{CData1};
$$dataref = shift if @_;
return $$dataref;
}
sub CData2 {
my $self = shift;
$self = $self->_classobj() unless ref $self;
my $dataref = $self->{CData2};
$$dataref = shift if @_;
return $$dataref;
}
Issues:
We're now strict refs clean, and using an eponymous metaobject
seems to make the code cleaner.
Unlike the previous one, this version does the intuitive thing
with inheritance, affecting the class metaobject in the actual
class, not the class into which the method was compiled.
Inquisitive people can get at the class metaobject easily.
This means that it's easy to dump the class state using an
external mechanism, since the class metaobject is 1) a package
variable 2) has a well-known name 3) clusters all of its data
together.
There is no check that the object accessor methods have not
been called on the classname. If strict refs are on for those
methods, you'd blow up. If not, you get the eponymous metaobject.
What you do with -- or about -- this is up to you; previous
examples should suggest tricks and treatments respectively.
--
One the subject of ribbons: One person's (large) ribbon collection is
another person's clique. --Boyd Roberts
------------------------------
Date: 13 May 1999 20:01:50 GMT
From: orwant@repo-man.media.mit.edu (Jon Orwant)
To: "Mug-O-Milk" <webmaster@*nospam*mugomilk.freeserve.co.uk>
Subject: Re: Help with CGI Script Required!
Message-Id: <ORWANT.99May13160150@repo-man.media.mit.edu>
"Mug-O-Milk" <webmaster@*nospam*mugomilk.freeserve.co.uk> writes:
> Hello, I've been busy building a search engine - and its working quite well!
> http://www.mugomilk.freeserve.co.uk is its URL.
> Just some hints (or maybe some code(!) required to help me achieve the
> following: (I've only been using Perl for three months, and I've got the
> great Larry Wall "Programming Perl" book, but can't work out the following:
>
> - Can I access Unix Shell Commands using PERL?
Use system or `` or the Perl Power Tools: http://language.perl.com/ppt/
> -- How can I "Get" other HTML documents from other HTTP servers?, do I
> specify their URL in an array and treat it as a file name?
Use the LWP module: http://www.perl.com/CPAN/modules/by-module/LWP.
> -- How can I remove words such as "THE" from an @array
@array = grep (!/^the$/i, @array);
-Jon Orwant
--
------------------------------
Date: Thu, 13 May 1999 12:08:03 -0400
From: tadmc@metronet.com (Tad McClellan)
Subject: Re: Help with CGI Script Required!
Message-Id: <3dteh7.732.ln@magna.metronet.com>
Mug-O-Milk (webmaster@*nospam*mugomilk.freeserve.co.uk) wrote:
: Hello, I've been busy building a search engine - and its working quite well!
: http://www.mugomilk.freeserve.co.uk is its URL.
: Just some hints (or maybe some code(!) required to help me achieve the
: following: (I've only been using Perl for three months, and I've got the
: great Larry Wall "Programming Perl" book, but can't work out the following:
: - Can I access Unix Shell Commands using PERL?
Yes, if you are on a Unix system.
Here are three ways:
perldoc -f system
perldoc -f qx (backwards single quotes)
perldoc -f open (pipe open)
: -- How can I "Get" other HTML documents from other HTTP servers?,
use LWP::Simple;
$htmlfile = get('http://www.perl.com'); # easy huh?
The LWP modules are part of the libwww bundle available from:
http://www.perl.com/CPAN
: do I
: specify their URL in an array and treat it as a file name?
No.
URLs are URLs. Filenames are filenames. URLs are not filenames.
: -- How can I remove words such as "THE" from an @array
foreach (@array) {
s/\bTHE\b//g;
}
--
Tad McClellan SGML Consulting
tadmc@metronet.com Perl programming
Fort Worth, Texas
------------------------------
Date: Thu, 13 May 1999 21:06:31 GMT
From: "Marie Yelle-Whitwam" <whitwam@magma.NOSPAM.ca>
Subject: Help! sendmail problems
Message-Id: <r9H_2.7824$MR1.28233131@news.magma.ca>
Hi:
I am trying to get my perl program to send an e-mail containing
the info collected through a web page form.
I have tried the following:
open(SENDMAIL, "|/usr/lib/sendmail -oi -t")
or die "Can't fork for sendmail: $!\n";
print SENDMAIL <<"EOF";
From: $My_name <myemail_address\@host>
To: $Recipents_name <recipents_email\@otherhost>
Subject: A relevant subject line
Body of the message goes here, in as many lines as you like.
EOF
close(SENDMAIL) or warn "sendmail didn't close nicely";
It didn't work, so I changed the first line to:
open(SENDMAIL, "|/usr/lib/sendmail -oi -t recipents_email\@otherhost")
or die "Can't fork for sendmail: $!\n";
This worked but the sender and subject fileds were blank in the email.
Can someone tell me how to get the the script to pick up the
From: , To: and Subject from the SENDMAIL filehandle.
Marie
------------------------------
Date: 14 May 1999 06:32:00 GMT
From: austin95002887@yahoo.com (Austin Ming)
Subject: Re: How can i write perl script and ouput the base directory name to my browser?
Message-Id: <7hgg10$875$1@justice.csc.cuhk.edu.hk>
What is backticks ?
In article <373B138A.19F0EBC@genome.wi.mit.edu>, bwlang@genome.wi.mit.edu
says...
>
>you could try system or backticks to run a pwd
>
>
------------------------------
Date: Thu, 13 May 1999 21:46:26 GMT
From: jmsinstl@my-dejanews.com
Subject: Re: How to mail html files?
Message-Id: <7hfh7h$unt$1@nnrp1.deja.com>
Great. Thanks! I thought it would only send content-type=text/plain.
I'll give it a shot.
In article <1103_926582615@mi-note.alma.ch>,
mi @ alma.ch (MI) wrote:
> > I would like to mail an html file that can be viewed as html with my
> > mailreader (MSOutlook). I can tell that I need some Mime headers
to do
> > this properly. It looks like MIME::Lite is too lite, in that I
don't
> > think it sends content-type=text/html.
>
> It does if you (kindly) ask it to.
>
> > What modules do I need to do this? Are there any other good
resources?
>
> Look at http://alma.ch/perl/mail-sendmail-faq.htm#HTML
> The example uses Mail::Sendmail, but you can easily adapt it to any
mailer.
>
> The point is: Content-Type: multipart/alternative, and 2 parts:
text/plain and text/html
>
> MIME::Lite definitely can do it.
>
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Date: 13 May 1999 19:48:09 GMT
From: ada@fc.hp.com (Andrew Allen)
Subject: Re: imbedded subroutine
Message-Id: <7hfa9p$t7a$3@fcnews.fc.hp.com>
Andre Arpin (arpin@adan.kingston.net) wrote:
: I have not seen an exact definition of embedded subroutine but the following
: result puzzle me.
: sub a
: {
: my $x=shift;
: print " $x\n";
: b();
: sub b
: {
: print "$x\n";
: }
: }
use '-w', see the "Variable "%s" will not stay shared" entry in
perldiag, and the paragraph starting "Access to lexicals..." in
perlref.
Andrew
------------------------------
Date: Thu, 13 May 1999 19:24:55 GMT
From: pudge@pobox.com (Chris Nandor)
Subject: Re: Mac System calls
Message-Id: <pudge-1305991524580001@192.168.0.77>
In article <373788F1.7078FCBE@umich.edu>, mcshultz@umich.edu wrote:
# are there such things as system calls in MacPerl?
# obviously mac isn't command line oriented, so where could i find out
# what these calls are?
You cannot use syscall() in MacPerl. You can use system() to call any MPW
/ ToolServer tool you have installed. MPW is a command-line-like
development environment. ToolServer is a standalone app providing access
to these tools. You can call them with `` or system() if you have
ToolServer installed and configured. See the MacPerl book for more info,
or look around the various lists and documentation.
--
Chris Nandor mailto:pudge@pobox.com http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6'])
------------------------------
Date: Thu, 13 May 1999 16:37:59 -0500
From: rlb@intrinsix.ca (Lee)
Subject: man pages and FAQs: why posted?
Message-Id: <B360B0679668A5621A@0.0.0.0>
I'm wondering why all of the man pages and FAQs are being posted here.
Wouldn't it make more sense to write a short and simple "FAQ 0.0: Where to
start" that would point newbies to these resources, and post it every day
or two?
Or are they being posted for some other reason?
Lee
------------------------------
Date: 13 May 1999 21:39:48 GMT
From: gbacon@itsc.uah.edu (Greg Bacon)
Subject: Re: man pages and FAQs: why posted?
Message-Id: <7hfgr4$cqo$2@info2.uah.edu>
In article <B360B0679668A5621A@0.0.0.0>,
rlb@intrinsix.ca (Lee) writes:
: I'm wondering why all of the man pages and FAQs are being posted here.
: Wouldn't it make more sense to write a short and simple "FAQ 0.0: Where to
: start" that would point newbies to these resources, and post it every day
: or two?
I guess you haven't been reading this newsgroup for very long. Maybe
you haven't noticed the overabundance of questions that could be
answered after only a short read of Perl's documentation. I believe
the hope behind the FAQ and perlfunc posts is that people might read
them when they're in such small, easily digestible portions.
Interesting questions are so rare here these days. :-( I'm tired of
all the gimme-gimme and `hold my hand, I don't wanna read the docs'
posts. Everyone stop posting them. :-)
Greg
--
If you have tried your hand at something and failed, the next best thing is to
try your head.
------------------------------
Date: 13 May 1999 19:28:30 GMT
From: drbrain@ziemlich.org (markus)
Subject: NET::IRC question
Message-Id: <slrn7jm9ut.o09.drbrain@josefine.ben.tuwien.ac.at>
I'm using IRC::NET for a simple question/answer bot. Processing
questions takes sometimes a few seconds. If, in the meantime, someone asks the
bot another question, altough the bot is still processing the first question,
it is _not_ lost. It's queued, until the first question is answered. Thats a
good feature and the bot never misses a question, but i dont need/want this. I
need the bot to skip all questions in the meantime , so if he returns from the
first question, all other thousend questions should just be removed from the
queue and newly asked questions should be processed. Any idea how to do this ?
best regards,
Markus
--
(0- OpenSource
//\ join the revolution drbrain@gegen.kindersex.de
v_/_ http://drbrain.gegen.kindersex.de
gib Krieg, Rassismus und Gewalt gegen Kinder keine Chance
------------------------------
Date: 13 May 1999 15:54:59 -0400
From: Jay Rogers <jay@rgrs.com>
Subject: Re: Net::Telnet Module Question
Message-Id: <82675weodo.fsf@shell2.shore.net>
lr@hpl.hp.com (Larry Rosler) writes:
> In article <7hcimo$j4b$1@nnrp1.deja.com> on Wed, 12 May 1999 18:53:16
> GMT, jmsinstl@my-dejanews.com <jmsinstl@my-dejanews.com> says...
> > One of the servers that I telnet to does some processing after logging
> > in. It presents this message:
> > Attempting to get answerback. If terminal hangs here, press return.
> >
> > Well, my terminal hangs so I want the script to submit a carriage
> > return. After it submits a return, then I'll have my normal foo>>
> > prompt from which I can work.
> >
> > How do I get the script to submit a return?
>
> print "\r";
No, with Net::Telnet that should actually be
$t->print("");
By default, Net::Telnet's output record separator is "\n". This
is because most of the time user's are dealing with some
interactive program on the remote side that expects commands to
be submitted by hitting the enter key.
Regarding the message, "Attempting to get answerback", that
smells like VMS. The host could be sending some escape sequence
to request info. The vt100 "what are you" is an example. You
can use dump_log() to see what that escape sequence is, and a
VT100 reference card to see how to respond.
http://www.cs.utk.edu/~shuford/terminal/vt100_reference_card.txt
--
Jay Rogers
jay@rgrs.com
------------------------------
Date: Thu, 13 May 1999 13:55:32 -0400
From: Ala Qumsieh <aqumsieh@matrox.com>
Subject: Re: Newbie question on CGI developing
Message-Id: <x3yhfpgonvv.fsf@tigre.matrox.com>
Scratchie <upsetter@ziplink.net> writes:
> I'm probably not the only Perl user on this group who would appreciate a
> pointer to some information on learning SGML.
Why would you expect a lot of Perl programmers would care about
learning SGML? I, for one, don't give a rat's ass.
Ala
------------------------------
Date: Fri, 14 May 1999 06:30:38 GMT
From: design@raincloud-studios.com (Charles R. Thompson)
Subject: Re: Newbie question on CGI developing
Message-Id: <MPG.11a58e7276ee3c3d9896c1@news>
[ Congratulations, Ronald J Kimball you could be a winner! Return to
comp.lang.perl.misc to claim your prize. ]
In article <1drrrf3.1kiojptz0olfuN@p29.block1.tc5.state.ma.tiac.net>,
Ronald J Kimball says...
> Charles R. Thompson <design@raincloud-studios.com> wrote:
>
> > # iterate through each of the hash keys...
> > while ( ($key, $value) = each %pagestuff){
> > # find all instances of the named key and replace it
> > # with a value from the hash
> > $pagelines =~ s/<replace="$key">/$pagestuff{$key}/;
> > }
>
> Hmm, that seems backwards to me. In particular, Perl has to recompile
> the regex each time, and you're doing extra work for keys that don't
> appear in the file. Also, without a /g, you only allow each template
> key to appear once in the file.
Still learning. Now that you *say* it, I see it. I can't believe I missed
the /g (grumble).
I was wondering if there was a way to get out of the loop, but I'll admit
it. I had no clue! :)
> $pagelines =~ s/<replace="([^"]*)">/
> exists $pagestuff{$1} ? $pagestuff{$1} : ''/eg;
Thanks... looks cool.
--
Charles R. Thompson
RainCloud Studios
"Have code, will mod."
------------------------------
Date: Thu, 13 May 1999 12:33:47 -0400
From: tadmc@metronet.com (Tad McClellan)
Subject: Re: Newbie question on CGI developing
Message-Id: <btueh7.362.ln@magna.metronet.com>
Ala Qumsieh (aqumsieh@matrox.com) wrote:
: Scratchie <upsetter@ziplink.net> writes:
: > I'm probably not the only Perl user on this group who would appreciate a
: > pointer to some information on learning SGML.
: Why would you expect a lot of Perl programmers would care about
: learning SGML? I, for one, don't give a rat's ass.
Me either.
Anyway, the "lookup" part of Arjun's reply ( "General Entities"
in SGML) is just a macro replacement sort of thing.
Very simple to roll your own for that.
It is the "beyond lookup" part of his reply that argues well
for using SGML.
But the original problem is not "beyond lookup", so a simple
macro replacement would suffice.
--
Tad McClellan SGML Consulting
tadmc@metronet.com Perl programming
Fort Worth, Texas
------------------------------
Date: Thu, 13 May 1999 19:16:47 GMT
From: David Sloan <ceedas@my-dejanews.com>
Subject: Next line
Message-Id: <7hf8es$o1m$1@nnrp1.deja.com>
How do I read in the next line from a file in order to manipulate it.
E.g.:
If I have the following lines:
load a
load b
loading complete
add a,b
store c
and I know the operation is performed once 'loading complete', and I
want to extract the arguments of the operation, how would I move on a
line, once I've been able to match the 'loading complete' message?
I hope someone understands what I am trying to achieve?
Thanks
Dave
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Date: Thu, 13 May 1999 21:02:22 GMT
From: r-watkins@worldnet.att.net (Robert Watkins)
Subject: Re: Next line
Message-Id: <7hfel7$kda$1@bgtnsc03.worldnet.att.net>
In article <7hf8es$o1m$1@nnrp1.deja.com>, ceedas@cee.hw.ac.uk wrote:
>How do I read in the next line from a file in order to manipulate it.
>E.g.:
>
>If I have the following lines:
>
>load a
>load b
>loading complete
>add a,b
>store c
>
>and I know the operation is performed once 'loading complete', and I
>want to extract the arguments of the operation, how would I move on a
>line, once I've been able to match the 'loading complete' message?
>
>I hope someone understands what I am trying to achieve?
>
Dave --
I think I understand:
The way I have done this in the past is to read each line, storing it in a
variable such as $last_line, which I test on the next go round.
while (<INPUT>) {
if ($last_line =~ /loading complete/) {
chomp($arguments = $_);
# do something with $arguments
next;
}
$last_line = $_;
}
Someone else may be able to offer a more efficient solution.
-- Robert
----------------------------------------
Robert Watkins
r-watkinsNO@SPAMworldnet.att.net
----------------------------------------
"I must go seek some dew-drops here,
And hang a Perl in every cowslips ear."
-- William Shakespeare
A Midsummer Night's Dream, II, i, 14
------------------------------
Date: Thu, 13 May 1999 19:22:10 GMT
From: "Stephen Warren" <swarren@www.wwwdotorg.org>
Subject: Re: OPEN command doesn't work on NT machine
Message-Id: <CDF_2.758$6x6.845@news.rdc1.sfba.home.com>
KW Lee <kuan-wee.lee@infineon.com> wrote in message
news:373A776E.B1421AF5@infineon.com...
>
> I'm migrating al my .pl files from a UNIX machine to an NT machine.
> There is one part of the code that needs to read a data file in the same
> directory as the .pl file. It works fine on the UNIX machine previously,
> but failed when running on NT machine.
First off, being rather pedantic, it's the open function, not the OPEN
command...
But, a couple of things to help you...
1) Make sure you have -w enabled
2) Make sure you use strict
These will tell you a lot of mistakes:
#!/usr/local/bin/perl -w
#The above will also work on Win32
use strict ;
If you haven't used these before on your script, there might be a lot of
errors/warnings when you run it... However, the errors/warnings produced
might not go anywhere obvious (they should go to your Web server's error
log file), so you may also wish to add:
use CGI::Carp qw( fatalsToBrowser ) ;
right near the start (e.g. just after use strict) This will send the error
messages to the browser client, so that you can see them easily.
> open (REFID, "SCPLReferenceID.dat") or
> die("Error: SCPLReferenceID.dat can't open to read!\n");
First off, you definitely _do_ need the > at the start of the filename.
Also, including $! in the error message will give you more useful
information on why it's failing:
> my $filname = 'SCPLReferenceID.dat' ;
> open (REFID, "<$filename") or
> die("Error: '$filename' can't open to read: $!\n");
This should help you track down the real source of the problem.
--
Stephen Warren, Snr Systems Engineer, Technology House, San Francisco
mailto:swarren@techhouse.com http://www.techhouse.com/
mailto:swarren@wwwdotorg.org http://www.wwwdotorg.org/
MIME, S/MIME and HTML mail are acceptable
------------------------------
Date: 13 May 1999 16:19:10 -0400
From: groenvel@cse.psu.edu (John D Groenveld)
Subject: Re: Oraperl help - inserting perl vars
Message-Id: <7hfc3u$mtr$1@tholian.cse.psu.edu>
Where's your error handling?
With DBI, you can
$dbh = DBI->connect('dbi:Oracle:mySID','myusername','mypassword',
{RaiseError=>1});
or you can
$sth->execute('HPR01',$sys_date[0],$logname,$times[0],$times[$counter-1])
or die $DBI::errstr;
I used to be an oraperl and later Oraperl.pm user, but DBI now has a much
more powerful interface.
John
groenveld@acm.org
------------------------------
Date: 12 Dec 98 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Special: Digest Administrivia (Last modified: 12 Dec 98)
Message-Id: <null>
Administrivia:
Well, after 6 months, here's the answer to the quiz: what do we do about
comp.lang.perl.moderated. Answer: nothing.
]From: Russ Allbery <rra@stanford.edu>
]Date: 21 Sep 1998 19:53:43 -0700
]Subject: comp.lang.perl.moderated available via e-mail
]
]It is possible to subscribe to comp.lang.perl.moderated as a mailing list.
]To do so, send mail to majordomo@eyrie.org with "subscribe clpm" in the
]body. Majordomo will then send you instructions on how to confirm your
]subscription. This is provided as a general service for those people who
]cannot receive the newsgroup for whatever reason or who just prefer to
]receive messages via e-mail.
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.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
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.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
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 V8 Issue 5656
**************************************
