[26094] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 8294 Volume: 10

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Jul 30 21:05:26 2005

Date: Sat, 30 Jul 2005 18:05:04 -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, 30 Jul 2005     Volume: 10 Number: 8294

Today's topics:
    Re: How does a scalar know what it is? <lfs.1@spam.net>
    Re: How does a scalar know what it is? <lfs.1@spam.net>
    Re: How does one find what PL_stack_sp is? <tassilo.von.parseval@rwth-aachen.de>
    Re: How does one find what PL_stack_sp is? <socyl@987jk.com.invalid>
    Re: Passing vars to a "require"d script <tadmc@augustmail.com>
    Re: PERL vs. Ruby <abigail@abigail.nl>
        Problem accessing fully qualified global var from anoth <sven-thorsten.fahrbach@gmx.net>
    Re: Where to ask mysql questions? <BLOCKSPAMfishfry@your-mailbox.com>
    Re: Where to ask mysql questions? <lfs.1@spam.net>
    Re: Where to ask mysql questions? <no@email.com>
    Re: Where to ask mysql questions? <andy@andyh.co.uk>
    Re: Where to ask mysql questions? <abigail@abigail.nl>
    Re: Where to ask mysql questions? <ignoramus27279@NOSPAM.27279.invalid>
    Re: Where to ask mysql questions? <zebee@zip.com.au>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Sat, 30 Jul 2005 14:42:57 -0500
From: "Tom" <lfs.1@spam.net>
Subject: Re: How does a scalar know what it is?
Message-Id: <Y7qdnRBHe_OJRXbfRVn-pw@comcast.com>


"Ala Qumsieh" <notvalid@email.com> wrote in message
news:odYFe.1262$iM7.1056@newssvr21.news.prodigy.com...
> Tom wrote:
> > again at the machine level, how does perl know
> > what it has?
>
> I'm curious to know why you ask this question. If you want a language
> that is closer to the hardware, then you know where to find C, or even
> assembly. The whole point of a higher level language like Perl is to
> unburden (is that a real word?) the user from such information. As a
> Perl user, you don't need to keep track of whether a scalar is an
> integer, string, reference or whatever. You can rest assured that:
>
> print $x;
>
> will do the Right Thing (tm) irrespective of what $x contains. This
> comes at the expense of more memory usage. If your goal is to optimize
> memory/performance, then you should be looking at a lower level language
> like C.
>
> --Ala
>

If you really want to understand how to use any
computer language whatever, it is very helpful to
understand how it works at the machine level.





------------------------------

Date: Sat, 30 Jul 2005 14:44:29 -0500
From: "Tom" <lfs.1@spam.net>
Subject: Re: How does a scalar know what it is?
Message-Id: <mf-dnYQf2eHtRXbfRVn-jg@comcast.com>


"Sisyphus" <sisyphus1@nomail.afraid.org> wrote in message
news:42e463b2$0$27469$afc38c87@news.optusnet.com.au...
>
> "Tom" <lfs.1@spam.net> wrote
>
> >
> > It looks to me that these scalars are carrying around
> > alot of baggage.  Does it need to carry this baggage
> > on the function calls?
> >
>
> Think of it as the scalars carrying around a pointer to the baggage
(rather
> than carrying around the actual baggage) - which is not such a big load to
> be carrying.
>
> Cheers,
> Rob
>
>

But this is not true.




------------------------------

Date: Sat, 30 Jul 2005 21:13:50 +0200
From: "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de>
Subject: Re: How does one find what PL_stack_sp is?
Message-Id: <slrndenkbe.ql.tassilo.von.parseval@localhost.localdomain>

Also sprach kj:

> I'm *astonished* anyone other than the authors can understand the
> Perl source.  How can *anyone* navigate this maze?  It's insane.
> (And how can the Perl community defend itself against the common
> charge of Perl's unreadability, when all a critic needs to do is
> point to the Perl source itself for an unparalleled example of
> illegibility?  Granted, the Perl source is not written in Perl,
> but it is obviously written by people who don't give a fig about
> the readability of the code.  All the piousness in the umpteen Perl
> style guides begins to ring hollow after one takes a look at the
> Perl source.)

What you forgot to mention is that perl is also one of the most portable
pieces of software ever written. This doesn't come for free. The maze of
preprocessor directives is the price you have to pay for it. It's beyond
words how much I hated that at the beginning as I couldn't find
anything. However, as time progressed...

> I've spent a couple of hours (and 100% of my patience) trying to
> find what PL_stack_sp is.  This is just *one* identifier out of
> thousands in the Perl source.  At this rate it will take me many
> months of solid work to have a sense of where things are *defined*,
> let alone figuring out what they do or how they're used.
>
> And yes, I grepped "stack_sp" in perlxstut, perlxs, perlapi, and
> perlguts, and pored over Extending and Embedding Perl by Jenness
> and Cozens.

You wont find it there because it's not part of the public API. 
PL_* are variables global to the perl interpreter. They are usually
wrapped in some other macros in case they are useful to extension
writers. In case of PL_stack_sp the macros in question are 'SP' and
'ST(x)' to access a single scalar in this stack. And those are
mentioned in perlapi.pod. 

> The best I was able to find (and purely by random accident, BTW)
> is that it is a macro defined in perlapi.h as
>
> (*Perl_Tstack_sp_ptr(aTHX))

That's how all global variables look before the preprocessor is done
with them. In thrdvar.h you find:

    PERLVAR(Tstack_sp,    SV **)

which is furhter mangled until it becomes 

    EXTERN_C SV*** Perl_Tstack_ptr(pTHX);

> Great.  More wild goose chases ahead.  I have not been able to find
> where aTHX is defined.  I looked in perlapi.h, and in all the files
> #include'd in it, and all the files included by those, etc.  Plus
> a huge list of other files (configuration files, make files, etc.),
> too long to fully enumerate.  aTHX is not even mentioned in any of
> these.

(p|a)THX_? are important macros to ensure that XS modules work both on
threaded and unthreaded perls. pTHX is used in function declarations:

    int function (pTHX_ int a, int b);

    /* for parameterless functions use version without underscore */

    int function (pTHX);

If your perl is threaded then these are expanded to

    register PerlInterpreter *my_perl

Functions thus declared are supposed to be called with the corresponding
aTHX macros:

    function(aTHX_ 1, 2);

In a threaded environment aTHX is replaced with the variable pointing to
the Perl interpreter of the currently executing thread. Thus it is
ensured that the interpreter can be accessed by macros and functions of
the Perl API. 

> Doing a recursive grep for Perl_Tstack_sp_ptr in the Perl source
> turns up *nothing*, other than the occurrences of this identifier
> in the RHS of some definitions (such as PL_stack_sp) in perlapi.h.

Have a closer look at what PERLVAR does. Note that it is overridden in
some headers so you have to be sure to look at the right one. In your
case:

    #define PERLVAR(v,t)  EXTERN_C t* Perl_##v##_ptr(pTHX);
    
> So, after hours of searching all I know is that PL_stack_sp is
> defined in terms of things I cannot find definitions for.
>
> OK, so what's the trick?  How does one navigate this insanity?

By practice and intuition. ;-)

There is a certain, albeit not always consistent, system of naming
conventions and preprocessor chains involved. PL_ are global variables
and they are usually mapped to something that is defined in thrdvar.h or
intrpvar.h using one of the various PERLVAR... macros. These two header
files are actually just the body of a C-structure declaration which you
can see in perl.h:

    struct interpreter {
    #  include "thrdvar.h"
    #  include "intrpvar.h"
    /*
     * The following is a buffer where new variables must
     * be defined to maintain binary compatibility with previous versions
     */
    PERLVARA(object_compatibility,30,	char)
    };

So these two huge header files combined define all the fields of 'struct
interpreter'. When you see something like PL_dirty and are curious
what it is, you do a grep for 'Tdirty' in these two headers, and it
yields:

PERLVARI(Tdirty,        bool, FALSE)    /* in the middle of tearing things down? */

So it's a boolean with initial value FALSE.

Tassilo
-- 
use bigint;
$n=71423350343770280161397026330337371139054411854220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);


------------------------------

Date: Sat, 30 Jul 2005 19:32:43 +0000 (UTC)
From: kj <socyl@987jk.com.invalid>
Subject: Re: How does one find what PL_stack_sp is?
Message-Id: <dcgkkr$e1h$1@reader2.panix.com>



Tassilo, thank you for your detailed explanation.  I'll study it
carefully.

kj

-- 
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.


------------------------------

Date: Sat, 30 Jul 2005 17:41:50 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Passing vars to a "require"d script
Message-Id: <slrndeo0he.53h.tadmc@magna.augustmail.com>

Bigus <personage@myabode.com> wrote:
> "Tad McClellan" <tadmc@augustmail.com> wrote in message 
> news:slrndeknir.6b6.tadmc@magna.augustmail.com...
>> Bigus <someone@somewhere.com> wrote:
>>
>>> If I call a separate script from within a CGI script using "require",

>> require does not "call" a "separate" program, it "includes" some
>> code in the _current_ program.


> then the 
> require'd script didn't seem to pull in the form data, which I assumed was 
> because a system call doesn't maintain the CGI context?


I dunno what you mean by "CGI context".

They have access to the same environment that the calling program
had when it called the external program.


>>> is
>>> there any (simple) way of passing a variable to it?
>>
>> Yes, but we should first address why you think that you need to do that.
>>
>> Why do you feel that you need to pass an argument to a require'd file?
> 
> Basically, I've got a set of server administration tools. Each tool is a 
> separate .pl script (along with a html control form) that is knitted 
> together into one web interface by a handler CGI (admin.cgi) script. 
> admin.cgi deals with the login and generates a session ticket which I want 
> to pass to the tool .pl that I'm requiring.
> 
>> Why not simply rewrite the .pl function to take a proper argument,
>> and then supply the argument in the main program's function call?
> 
> Well, yeah, I could reengineer everything but that involves changing a fair 
> few lines.


That is the price you pay when you proceed with a poor design.

Most of these issues would not have come up if you had designed 
your code with appropriate modularity in the first place.

(Are you perhaps, new to programming in general?)

Put subroutines (not code) in libraries (and a Real Module is much
better yet) and pass arguments from the main program.

Live and learn.  :-)


> also has an associated admin.pl which is purely a library of subs that I 
> call from admin.cgi, and for that matter some of the tool .pl's, so that is 
> presumably more like a correct model of usage?


Yes, subs in libraries, main code in main code.


> I found an article on "our()"


Was it:

   "Coping with Scoping":

      http://perl.plover.com/FAQs/Namespaces.html

??


>> If you really really need to "pass" variables (I doubt that you do),
>> you can do it thus:
>>
>> --------------------------
>> use warnings;   # foo.pl
>> use strict;
>> our $foo;
>> sub func1 { print $foo }
>> 1;
>> --------------------------
>> #!/usr/bin/perl
>> use warnings;  # main program
>> use strict;
>>
>> our $foo = 'foobar';
>> require 'foo.pl';
>>
>> func1();
>> --------------------------
> 
> thanks.. I'll use that method for now!


Ugh. You will re-live all the programming headaches of 
the 60s and 70s then.


Here is a "proper" redesign of what I posted (untested):

   use warnings;   # foo.pl
   use strict;
   sub func1 { print $_[0] }
   1;

and

   #!/usr/bin/perl
   use warnings;  # main program
   use strict;
   require 'foo.pl';

   my $foo = 'foobar';
   func1($foo);


Look Ma! Low coupling, no globals!

That wasn't very hard...


-- 
    Tad McClellan                          SGML consulting
    tadmc@augustmail.com                   Perl programming
    Fort Worth, Texas


------------------------------

Date: 30 Jul 2005 22:20:28 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: PERL vs. Ruby
Message-Id: <slrndenv9c.7fo.abigail@alexandra.abigail.nl>

kj (socyl@987jk.com.invalid) wrote on MMMMCCCLI September MCMXCIII in
<URL:news:dcgaab$cvo$1@reader2.panix.com>:
()  In <slrnden6a5.7fo.abigail@alexandra.abigail.nl> Abigail <abigail@abigail.nl> writes:
()  
() >I'd go for Python if I were you.
()  
()  Why do you prefer Python over Ruby?


Who says I do.


Abigail
-- 
perl -swleprint -- -_=Just\ another\ Perl\ Hacker


------------------------------

Date: Sat, 30 Jul 2005 20:43:09 +0200
From: Sven-Thorsten Fahrbach <sven-thorsten.fahrbach@gmx.net>
Subject: Problem accessing fully qualified global var from another package
Message-Id: <20050730204309.4e236b13.sven-thorsten.fahrbach@gmx.net>

I'm really busting my brains over the following problem:

I've got a script with several modules, including one that reads in data
from a configuration file. The module then stores the retrieved data in
global variables, e.g. one that is declared with 'our $dataDirectory'.
My log module needs to retrieve a path where to store its log file in,
which is also retrieved by the Config.pm module. Here is the code:

package Logalizer::Log4Logalizer;

use strict;
use warnings;
no warnings qw/ uninitialized /;
use Carp;
use Fcntl qw/ :DEFAULT :flock /;

use Logalizer::Config;

BEGIN {
    use Exporter();
    our ($VERSION, @ISA, @EXPORT);
    $VERSION = 1.00;
    @ISA = qw/ Exporter /;
    @EXPORT = qw/ $verboseLevel &init &log /;
}

our $verboseLevel = 0;
our $logName      = "$Logalizer::Config::logDirectory/logalizer.log";

our $LOG = \*LOG;

sub init {
    unless (-d $Logalizer::Config::logDirectory) {
        mkdir $Logalizer::Config::logDirectory, 0777
	or croak "Can't mkdir $Logalizer::Config::logDirectory", ": $!";
    }

    sysopen ($LOG, $logName, O_WRONLY | O_CREAT)
	or croak "Can't open $logName: $!";
}

[...]

I monitor $Logalizer::Config::logDirectory with carp()s and I get the correct path, let's say '/path/to/logfile'. I also monitor $logName, what I get, however, is '/logalizer.log', i.e. $Logalizer::Config::logDirectory doesn't seem to be interpolated in the above assignment. What's even more amazing is that the very same kind of assignment works in all the other modules. It's probably something obvious but I'm really at a loss here. Does anybody know what's going wrong and what I can do about it?

Any help will be greatly appreciated.

SveTho


------------------------------

Date: Sat, 30 Jul 2005 12:39:05 -0700
From: fishfry <BLOCKSPAMfishfry@your-mailbox.com>
Subject: Re: Where to ask mysql questions?
Message-Id: <BLOCKSPAMfishfry-59AA19.12390530072005@comcast.dca.giganews.com>

In article <slrnden76o.7fo.abigail@alexandra.abigail.nl>,
 Abigail <abigail@abigail.nl> wrote:

> fishfry (BLOCKSPAMfishfry@your-mailbox.com) wrote on MMMMCCCLI September
> MCMXCIII in 
> <URL:news:BLOCKSPAMfishfry-1C4C7F.19553529072005@comcast.dca.giganews.com>:
> []  I couldn't find a mysql newsgroup. Where is the appropriate place to ask 
> []  mysql questions that aren't Perl-related?
> 
> 
> I'd say, go to alt.binaries.pictures.furniture, and ask again.
> 

From time to time I have occasion to comment unfavorably about the tone 
on this newsgroup. And here we go again.

If you want to know why Java, PHP, Ruby, and Python are eating Perl's 
lunch, look no further than Abigail's remark. 

Go to an city on Craigslist, click on the Internet or Software jobs, and 
search for Perl versus PHP or Java, and you'll see why even the best 
Perl programmers have a hard time finding work these days.

In the beginning, Larry Wall's motto was, "there's more than one way to 
do it." Somehow the Perl community has morphed into "fuck you if you're 
not one of us."

Shame on those of you who should know better.


------------------------------

Date: Sat, 30 Jul 2005 14:46:34 -0500
From: "Tom" <lfs.1@spam.net>
Subject: Re: Where to ask mysql questions?
Message-Id: <NPWdnbrjhd9wRXbfRVn-hw@comcast.com>


"fishfry" <BLOCKSPAMfishfry@your-mailbox.com> wrote in message
news:BLOCKSPAMfishfry-59AA19.12390530072005@comcast.dca.giganews.com...
> In article <slrnden76o.7fo.abigail@alexandra.abigail.nl>,
>  Abigail <abigail@abigail.nl> wrote:
>
> > fishfry (BLOCKSPAMfishfry@your-mailbox.com) wrote on MMMMCCCLI September
> > MCMXCIII in
> >
<URL:news:BLOCKSPAMfishfry-1C4C7F.19553529072005@comcast.dca.giganews.com>:
> > []  I couldn't find a mysql newsgroup. Where is the appropriate place to
ask
> > []  mysql questions that aren't Perl-related?
> >
> >
> > I'd say, go to alt.binaries.pictures.furniture, and ask again.
> >
>
> From time to time I have occasion to comment unfavorably about the tone
> on this newsgroup. And here we go again.
>
> If you want to know why Java, PHP, Ruby, and Python are eating Perl's
> lunch, look no further than Abigail's remark.
>
> Go to an city on Craigslist, click on the Internet or Software jobs, and
> search for Perl versus PHP or Java, and you'll see why even the best
> Perl programmers have a hard time finding work these days.
>
> In the beginning, Larry Wall's motto was, "there's more than one way to
> do it." Somehow the Perl community has morphed into "fuck you if you're
> not one of us."
>
> Shame on those of you who should know better.

I thought Perl was eating everyone's lunch.  But
I have no horse in this race, so feel free to set
me straight as I would like to know the answer to
that one.




------------------------------

Date: Sat, 30 Jul 2005 21:45:34 +0100
From: Brian Wakem <no@email.com>
Subject: Re: Where to ask mysql questions?
Message-Id: <3l277eF10ekr0U1@individual.net>

fishfry wrote:

> I couldn't find a mysql newsgroup. Where is the appropriate place to ask
> mysql questions that aren't Perl-related?


Normally google or mysql's documentation will provide the answer.


Failing that, try http://forums.mysql.com/ or
http://www.google.com/search?q=mysql+forum


-- 
Brian Wakem



------------------------------

Date: Sat, 30 Jul 2005 22:42:10 +0100
From: Andy Hassall <andy@andyh.co.uk>
Subject: Re: Where to ask mysql questions?
Message-Id: <3tsne1te38lh53du0g4cf0fs5uo2hi3fp4@4ax.com>

On Fri, 29 Jul 2005 19:55:35 -0700, fishfry <BLOCKSPAMfishfry@your-mailbox.com>
wrote:

>I couldn't find a mysql newsgroup.

 Yes, there isn't one at the moment. comp.databases.mysql is in the process of
being created - there should be a call for votes going out at some point in the
not so distant future.

> Where is the appropriate place to ask 
>mysql questions that aren't Perl-related?

 Probably one of these: 

 http://lists.mysql.com/
 http://forums.mysql.com/

-- 
Andy Hassall / <andy@andyh.co.uk> / <http://www.andyh.co.uk>
<http://www.andyhsoftware.co.uk/space> Space: disk usage analysis tool


------------------------------

Date: 30 Jul 2005 22:23:24 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: Where to ask mysql questions?
Message-Id: <slrndenves.7fo.abigail@alexandra.abigail.nl>

fishfry (BLOCKSPAMfishfry@your-mailbox.com) wrote on MMMMCCCLI September
MCMXCIII in <URL:news:BLOCKSPAMfishfry-59AA19.12390530072005@comcast.dca.giganews.com>:
{}  In article <slrnden76o.7fo.abigail@alexandra.abigail.nl>,
{}   Abigail <abigail@abigail.nl> wrote:
{}  
{} > fishfry (BLOCKSPAMfishfry@your-mailbox.com) wrote on MMMMCCCLI September
{} > MCMXCIII in 
{} > <URL:news:BLOCKSPAMfishfry-1C4C7F.19553529072005@comcast.dca.giganews.com>:
{} > []  I couldn't find a mysql newsgroup. Where is the appropriate place to ask 
{} > []  mysql questions that aren't Perl-related?
{} > 
{} > 
{} > I'd say, go to alt.binaries.pictures.furniture, and ask again.
{} > 
{}  
{}  From time to time I have occasion to comment unfavorably about the tone 
{}  on this newsgroup. And here we go again.
{}  
{}  If you want to know why Java, PHP, Ruby, and Python are eating Perl's 
{}  lunch, look no further than Abigail's remark. 
{}  
{}  Go to an city on Craigslist, click on the Internet or Software jobs, and 
{}  search for Perl versus PHP or Java, and you'll see why even the best 
{}  Perl programmers have a hard time finding work these days.
{}  
{}  In the beginning, Larry Wall's motto was, "there's more than one way to 
{}  do it." Somehow the Perl community has morphed into "fuck you if you're 
{}  not one of us."


That's why I pointed him to alt.binaries.pictures.furniture! Those guys
love to point out were to go for non-furniture related questions. They 
know all the newsgroups, and can tell you exactly where to go.

Not us Perl people, who only know Perl.


Abigail
-- 
perl -we 'print q{print q{print q{print q{print q{print q{print q{print q{print 
               qq{Just Another Perl Hacker\n}}}}}}}}}'    |\
perl -w | perl -w | perl -w | perl -w | perl -w | perl -w | perl -w | perl -w


------------------------------

Date: Sat, 30 Jul 2005 22:54:19 GMT
From: Ignoramus27279 <ignoramus27279@NOSPAM.27279.invalid>
Subject: Re: Where to ask mysql questions?
Message-Id: <vyTGe.33719$p94.5255@fe73.usenetserver.com>

I think that no one is obligated to promote perl, as such.  Perl is a
tool, not a religion.

However, unfriendly attitude does make this newsgroup less helpful
than I would like it to be. I am quite thick skinned, so almost
nothing can piss me off, but not everyone is like that.

Plus, I hate wasting time by asking a question and then seeing an
asshole fest rather than an actual answer. In fairness, though, I must
say that about 50% of my questions have been answered with relevant
answers given. People here are very intelligent, but sometimes go off
into time wasting tirades instead of actually using their
intelligence.

As far as "perl jobs" are concerned, do not forget about a large
segment of non-perl jobs where knowledge of perl is a great plus. I am
a C++ programmer by trade, but my knowledge of perl has been supremely
helpful to getting stuff to actually work and "gluing" various
programs together. Most companies who do not need dedicated perl
programmers, consider knowledge of perl a great advantage. 

In fact, things get done in perl so quickly and usually work so well,
that having a dedicated perl programmer is not warranted.

i



------------------------------

Date: Sat, 30 Jul 2005 22:59:59 GMT
From: Zebee Johnstone <zebee@zip.com.au>
Subject: Re: Where to ask mysql questions?
Message-Id: <slrndeo1bc.12a.zebee@zeus.zipworld.com.au>

In comp.lang.perl.misc on 30 Jul 2005 22:23:24 GMT
Abigail <abigail@abigail.nl> wrote:
> 
> 
> That's why I pointed him to alt.binaries.pictures.furniture! Those guys
> love to point out were to go for non-furniture related questions. They 
> know all the newsgroups, and can tell you exactly where to go.
> 
> Not us Perl people, who only know Perl.

And neither user interfaces or documentation...

Did you expect him to go to that group?  IF so, the user interface
design was bad but you didn't realise it.

If you didn't, then the program worked as the programmer expected, but
not as the user expected, again a poor performance.

Addition of the explanation at the time the user needed it, rather than
buried right down in a bit of doco not even written at testing time
would have been much more sensible.

Zebee


------------------------------

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 8294
***************************************


home help back first fref pref prev next nref lref last post