[29536] in Perl-Users-Digest

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

Perl-Users Digest, Issue: 780 Volume: 11

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Aug 21 14:14:22 2007

Date: Tue, 21 Aug 2007 11:14:13 -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           Tue, 21 Aug 2007     Volume: 11 Number: 780

Today's topics:
    Re: Symbolic representation of logical operators (Mark Hobley)
    Re: Symbolic representation of logical operators <mritty@gmail.com>
    Re: Symbolic representation of logical operators (Mark Hobley)
    Re: Symbolic representation of logical operators <mritty@gmail.com>
    Re: Symbolic representation of logical operators <mritty@gmail.com>
    Re: Symrefs (was: how to call sub by value in variable) <nobull67@gmail.com>
    Re: Symrefs <nobull67@gmail.com>
    Re: Symrefs <jurgenex@hotmail.com>
    Re: Symrefs <uri@stemsystems.com>
    Re: Using Subroutines with CGI::Session::MySQL? <ljames@apollo3.com>
    Re: Using Subroutines with CGI::Session::MySQL? <paduille.4061.mumia.w+nospam@earthlink.net>
    Re: Using Subroutines with CGI::Session::MySQL? <ljames@apollo3.com>
        writing array to file? <davechunny@gmail.com>
    Re: writing array to file? <mritty@gmail.com>
    Re: writing array to file? <jgibson@mail.arc.nasa.gov>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

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

Date: Tue, 21 Aug 2007 10:08:03 GMT
From: markhobley@hotpop.deletethisbit.com (Mark Hobley)
Subject: Re: Symbolic representation of logical operators
Message-Id: <21qqp4-hc1.ln1@neptune.markhobley.yi.org>

Mark Hobley <markhobley@hotpop.deletethisbit.com> wrote:

> I know the empty strings and non zero values are fine for logicals, I just 
> didn't expect some of the results.

I found some more apparent weirdness:

 print ("apples" || "pears"); # apples
 print ("apples" && "pears"); # pears

Regards,

Mark.

-- 
Mark Hobley
393 Quinton Road West
QUINTON
Birmingham
B32 1QE

Email: markhobley at hotpop dot donottypethisbit com

http://markhobley.yi.org/



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

Date: Tue, 21 Aug 2007 03:23:56 -0700
From:  Paul Lalli <mritty@gmail.com>
Subject: Re: Symbolic representation of logical operators
Message-Id: <1187691836.658046.261880@w3g2000hsg.googlegroups.com>

On Aug 21, 6:08 am, markhob...@hotpop.deletethisbit.com (Mark Hobley)
wrote:

> I found some more apparent weirdness:
>
>  print ("apples" || "pears"); # apples
>  print ("apples" && "pears"); # pears


Why are you calling this "weirdness"?  As has already been explained,
the logical operators return the last value they have to evaluate to
determine the truthfullness.  So || returns the first true value (or
the last value if they're all false), and && returns the first false
value (or the last value if they're all true).

This allows us to, among other things, use the operators to set
defaults:

my $fruit = $choice || "apples";
#if $chioce is a true value, $fruit = $choice.
#Else, $fruit = "apples";

Paul Lalli



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

Date: Tue, 21 Aug 2007 14:08:15 GMT
From: markhobley@hotpop.deletethisbit.com (Mark Hobley)
Subject: Re: Symbolic representation of logical operators
Message-Id: <h95rp4-6o1.ln1@neptune.markhobley.yi.org>

Paul Lalli <mritty@gmail.com> wrote:

> Why are you calling this "weirdness"?  As has already been explained,
> the logical operators return the last value they have to evaluate to
> determine the truthfullness.  So || returns the first true value (or
> the last value if they're all false), and && returns the first false
> value (or the last value if they're all true).

I'm sorry Paul. I am new to Perl, and my understanding is somewhat limited, 
and I feel that the documentation is letting me down here. Anyhow, I am trying 
to follow this.

You are saying || returns the first true value.

print (2 || 7);  # 7, both true, but the first value is 2, why return 7?
print ("apples" || "pears"); # apples, both true, but why return "apples"?

I am still not yet clear on why the numerical one, returns the opposite
argument. My background is assembly language, and electronics, so I think that
is clouding my judgement or thought process. Maybe I need some good documents
that explain this, with lots of examples. I think the issue is that I am not
able to foresee the behaviour from the either the perlop manual (or certainly
 not from the page I was looking at, or from my expensive Professional Perl
Programming book.
 
Looking at &&, you are saying first false, or last value. That is what I 
am getting:

print (2 && 7); # 7, Ok, that matches my understanding of your theory
print ("apples" && "pears"); # pears, Ok, so does that

Excellent, thanks for that! (Unless I understand for a wrong reason, maybe, or
 maybe don't understand but, think I do, Huh!)

I am still having a problem with XOR:

print ("apples" xor "pears"); s (true), incorrect, should be 0(false)

With "apples" and "pears" both being true, I was expecting a result of false
here.

Regards,

Mark.

-- 
Mark Hobley
393 Quinton Road West
QUINTON
Birmingham
B32 1QE

Email: markhobley at hotpop dot donottypethisbit com

http://markhobley.yi.org/



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

Date: Tue, 21 Aug 2007 08:04:28 -0700
From:  Paul Lalli <mritty@gmail.com>
Subject: Re: Symbolic representation of logical operators
Message-Id: <1187708668.112504.84980@22g2000hsm.googlegroups.com>

On Aug 21, 10:08 am, markhob...@hotpop.deletethisbit.com (Mark Hobley)
wrote:
> Paul Lalli <mri...@gmail.com> wrote:
> > Why are you calling this "weirdness"?  As has already been
> > explained, the logical operators return the last value they
> > have to evaluate to determine the truthfullness.  So ||
> > returns the first true value (or the last value if they're
> > all false), and && returns the first false value (or the last
> > value if they're all true).
>
> I'm sorry Paul. I am new to Perl, and my understanding is
> somewhat limited, and I feel that the documentation is letting
> me down here.

No apologies are necessary, I'm sorry if I implied such.  I'm just
confused because I thought this was already explained previously in
this thread.  Perhaps not.

> Anyhow, I am trying to follow this.
>
> You are saying || returns the first true value.

Yes.  Because in order for a chain of arguments connected by || to be
true, only one of those values has to be true.  Thus, as soon as we
come to the first true one, Perl can stop looking at the rest.  This
is known as short circuit evaluation.

> print (2 || 7);  # 7, both true, but the first value is 2,

No it doesn't, unless you have some very old or obscure version of
Perl installed:

$ perl -le'print (2 || 7);'
2
$

When you run that, it produces 7?  Really?  If so, please copy and
paste the output of this:
perl -v

> print ("apples" || "pears");
> # apples, both true, but why return "apples"?

Because as soon as "apples" was found to be true (all strings other
than "" and "0" are true), there was no need to look at the other
arguments.  Perl never even saw "pears" in this evaluation.  As soon
as it found one argument to be true, the whole expression is true.

> I am still not yet clear on why the numerical one, returns the
> opposite argument.

It doesn't.  Please check that again.

> I think the issue is that I am not able to foresee the behaviour
> from the either the perlop manual (or certainly not from the page
> I was looking at, or from my expensive Professional Perl
> Programming book.

There's really only a couple things you have to make sure you
understand, for this to be clear:  The operators (and, or, &&, ||) all
use short circuit evaluation.  As soon as it's possible to determine
the results of the entire expression, the operator returns.  And they
always return the last value evaluated.  For || or or to be true, only
one of the chain of values need be true.  For || or or to be false,
they all must be false.  The opposite is true for && or and: to be
true, they must all be true.  To be false, they must all be false.

If all values are true, || returns the first one, && returns the last:
$x = 1 || 2 || 3 || 4;   #1
$x = 1 && 2 && 3 && 4;   #4

If all values are false, || returns the last one, && returns the
first:

$x = 0 || "0" || undef || '';  #''
$y = 0 && "0" && undef && '';  #0

If there is a mixture, || returns the first true value, && returns the
first false value:

$x = 0 || 1 || undef || 5;  #1
$x = 0 && 1 && undef && 5;  #0

> Looking at &&, you are saying first false, or last value.
> That is what I am getting:
>
> print (2 && 7); # 7, Ok, that matches my understanding
> of your theory

It's not a theory, it's simply what is. :-)

> print ("apples" && "pears"); # pears, Ok, so does that
>
> Excellent, thanks for that! (Unless I understand for a wrong
> reason, maybe, or  maybe don't understand but, think I do, Huh!)

Nope, you've got it.

> I am still having a problem with XOR:
>
> print ("apples" xor "pears"); s (true), incorrect, should be 0
> (false)

Again, it doesn't return true for me.  I don't know what's making you
think it does.  For me, it returns the empty string, which is false:

$ perl -le'print ("apples" xor "pears");'

$

> With "apples" and "pears" both being true, I was expecting a
> result of false here.

Yes, and that's exactly what it produces.  What output are you seeing
that contradicts that?  Please copy and paste your actual code and
output, rather than typing in a comment what you think you're seeing.

Paul Lalli



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

Date: Tue, 21 Aug 2007 08:24:19 -0700
From:  Paul Lalli <mritty@gmail.com>
Subject: Re: Symbolic representation of logical operators
Message-Id: <1187709859.178492.257110@r29g2000hsg.googlegroups.com>

On Aug 21, 11:04 am, Paul Lalli <mri...@gmail.com> wrote:

> There's really only a couple things you have to make sure you
> understand, for this to be clear:  The operators (and, or, &&,
> ||) all use short circuit evaluation.  As soon as it's possible
> to determine the results of the entire expression, the operator
> returns.  And they always return the last value evaluated.  For
> || or or to be true, only one of the chain of values need be
> true.  For || or or to be false, they all must be false.  The
> opposite is true for && or and: to be true, they must all be
> true.  To be false, they must all be false.

ACK!  That should read:
The opposite is true for && or and: to be true, they must all be
true.  To be false, only one need be false.

Sorry about that!
Paul Lalli



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

Date: Tue, 21 Aug 2007 09:39:46 -0700
From:  Brian McCauley <nobull67@gmail.com>
Subject: Re: Symrefs (was: how to call sub by value in variable)
Message-Id: <1187714386.928118.252980@k79g2000hse.googlegroups.com>

On Aug 20, 4:21 am, Gunnar Hjalmarsson <nore...@gunnar.cc> wrote:
> Brian McCauley wrote:
> > manually doing ...
>
> > %dispatch = ( foo => \&foo, bar => \&bar, baz => \&baz);
>
> > ... would be wrong.
>
> Considering the numerous postings in this group that warn for using
> symrefs, I'm surprised to see that and other comments in this thread. Is
>
>      perldoc -q "variable name"
>
> totally out of date?

Definitely not. It doesn't talk about CODE symrefs.



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

Date: Tue, 21 Aug 2007 09:54:03 -0700
From:  Brian McCauley <nobull67@gmail.com>
Subject: Re: Symrefs
Message-Id: <1187715243.335194.101220@57g2000hsv.googlegroups.com>

On Aug 20, 4:42 am, Uri Guttman <u...@stemsystems.com> wrote:

> i don't agree with using symrefs (in any form) for a dispatch table. i
> haven't heard a decent argument from the OP why it can't be done in
> advance as he knows the names of the subs in the DB. if he is worried
> about hand editing a dispatch table with entries of 'foo' => \&foo then
> that can be trivially automated. one easy answer is to put all the subs
> into a separate module (namespace isn't important) and run a simple
> filter to extract all the sub names into a dispatch table (modify that
> module or write a fresh one).

There are things worse that symrefs.  Code preprocessors are one of
them. And they are bad for exactly the same reason.  Just like eval()
and symref() they blur the code/data divide.

> similarly a simple dbi query can dump the
> names and be used to generate the dispatch table. this is no different
> than using modules to generate accessors. in fact you could even do this
> in some way with AUTOLOAD but that is clunky.

I don't think the is talking about accessors that could be auto-
generated.

> checking the symbol table (even with prefix names) is no different than
> using a dispatch table (as someone has said)

That would be me.

> but it also means other
> code can inject legal subs into the symbol table which are not
> anticipated. only by controlling the dispatch table as a lexical do you
> have the full safety you want.

If code is maliciously putting stuff in packages that don't "belong"
to it then this is just as much of a problem whether or not that
package is being used as a dispatch table.



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

Date: Tue, 21 Aug 2007 17:05:31 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: Symrefs
Message-Id: <vXEyi.11953$5y3.7087@trndny07>

Brian McCauley wrote:
> Just like eval()
> and symref() they blur the code/data divide.

That's exactly what made me feel uneasy from the very beginning.

    Thou shalt not mix code and data

Therefore I would argue that the OPs idea of having the database control the 
program execution is not a good idea in the first place and I would 
investigate, if there is some better way to design the overall system.

However, if it really can't be helped, then at the very least very clearly 
document why are violating this best practise and make it obvious in the 
code, too. I would probably go with eval() in this case. It is bad, but it 
is known to be bad and it is obvious that it is bad and therefore there must 
be something very special going on, otherwise nobody would use it.

Trying to mask the bad code by casting it into on the surface inconspicous 
code only confuses future maintainers of the code.

jue 




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

Date: Tue, 21 Aug 2007 17:17:30 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Symrefs
Message-Id: <x7ir78remu.fsf@mail.sysarch.com>

>>>>> "JE" == Jürgen Exner <jurgenex@hotmail.com> writes:

  JE> Brian McCauley wrote:
  >> Just like eval()
  >> and symref() they blur the code/data divide.

  JE> That's exactly what made me feel uneasy from the very beginning.

  JE>     Thou shalt not mix code and data

  JE> Therefore I would argue that the OPs idea of having the database
  JE> control the program execution is not a good idea in the first
  JE> place and I would investigate, if there is some better way to
  JE> design the overall system.

  JE> However, if it really can't be helped, then at the very least very
  JE> clearly document why are violating this best practise and make it
  JE> obvious in the code, too. I would probably go with eval() in this
  JE> case. It is bad, but it is known to be bad and it is obvious that
  JE> it is bad and therefore there must be something very special going
  JE> on, otherwise nobody would use it.

  JE> Trying to mask the bad code by casting it into on the surface
  JE> inconspicous code only confuses future maintainers of the code.

even though there may be duplication in the sub names and dispatch table
entry keys, i agree that having the DB hold those names is a bad idea. i
know reasons why you do that such as a personal list of plugins to load,
etc. but those names could be different than the actual sub names or
even map 1 to many (or many to 1) so a dispatch table (even manually
created) is safer as the coder controls what is allowed to be
called. using the symbol table to check for sub existance is bad because
of the possibility of calling code not under your control. as brian
said, that is nasty regardless of dispatch tables but it is just safer
IMO. i would consider the names in the DB as data that request
operations to be called rather than explicit sub names to be called by
symrefs.

uri

-- 
Uri Guttman  ------  uri@stemsystems.com  -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs  ----------------------------  http://jobs.perl.org


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

Date: Tue, 21 Aug 2007 09:26:02 -0000
From:  "L. D. James" <ljames@apollo3.com>
Subject: Re: Using Subroutines with CGI::Session::MySQL?
Message-Id: <1187688362.397439.300840@50g2000hsm.googlegroups.com>

On Aug 21, 1:18 am, xhos...@gmail.com wrote:

Hi, Xhoster.

Does my last script, the testio produce errors on your computer?

-- L. James

--
L. D. James
ljames@apollo3.com
www.apollo3.com/~ljames



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

Date: Tue, 21 Aug 2007 07:13:26 -0500
From: "Mumia W." <paduille.4061.mumia.w+nospam@earthlink.net>
Subject: Re: Using Subroutines with CGI::Session::MySQL?
Message-Id: <13clo45asvo1q36@corp.supernews.com>

On 08/20/2007 11:29 PM, L. D. James wrote:
> [...]
> # ----- Code -----
> #!/usr/local/bin/perl
> 
> use warnings;
> use strict;
> use CGI qw(:standard);
> use Switch;
> use CGI::Carp qw(fatalsToBrowser);
> 
> print header;
> 
> my $count;
> 
> if (  open (FILEIN,"testio.out")  )
> {
>     $count = <FILEIN> || "0";
>     close ( FILEIN );
> }
> 
> open (FILEOUT,">testio.out") || die "Can't open output file...";
> 
> sub testio()

Leave off the parentheses. Prototypes are generally not needed with Perl.

> {
>     &menu1();

The ampersand is the old way of calling Perl subs. Don't use it for
modern Perl code unless you know what it does. Read "perldoc perlsub"

>     $count++;
>     print "<br>The Count: $count";
>     print FILEOUT "$count";

Quoting $count is unnecessary; read "perldoc -q quoting."

> }
> 
> sub menu1()
> {
>     print "<a href=testio.pl?cmd=testio>Testio<a>";
> }
> 
> my $s = param('cmd') || $ARGV[0];
> 
> switch($s)
> {
>     case "testio" { testio() }
>     else       { menu1()   }
> }
> 
> close FILEOUT;
> exit;
> 
> # ----- Code End -----
> 
> -- L. James

Invoking testio.pl without a parameter resets the counter on my system. 
Perhaps that was intended.



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

Date: Tue, 21 Aug 2007 14:12:07 -0000
From:  "L. D. James" <ljames@apollo3.com>
Subject: Re: Using Subroutines with CGI::Session::MySQL?
Message-Id: <1187705527.885327.216660@o80g2000hse.googlegroups.com>

On Aug 21, 8:13 am, "Mumia W." <paduille.4061.mumia.w
+nos...@earthlink.net> wrote:
> > sub testio()
>
> Leave off the parentheses. Prototypes are generally not needed with Perl.
>
> > {
> >     &menu1();
>
> The ampersand is the old way of calling Perl subs. Don't use it for
> modern Perl code unless you know what it does. Read "perldoc perlsub"
>
> >     $count++;
> >     print "<br>The Count: $count";
> >     print FILEOUT "$count";
>
> Quoting $count is unnecessary; read "perldoc -q quoting."
>
>
>
> > }
>
> > sub menu1()
> > {
> >     print "<a href=testio.pl?cmd=testio>Testio<a>";
> > }
>
> > my $s = param('cmd') || $ARGV[0];
>
> > switch($s)
> > {
> >     case "testio" { testio() }
> >     else       { menu1()   }
> > }
>
> > close FILEOUT;
> > exit;
>
> > # ----- Code End -----
>
> > -- L. James
>
> Invoking testio.pl without a parameter resets the counter on my system.
> Perhaps that was intended.

Thanks for the references.  I'm studying them in detail.  Before using
strict and warning I used to always call the subroutines without the
ampersand and parentheses.  When I got the bareword not allowed using
strict, I kind of went overboard to avoid errors.  But I'll study the
references and clean up my code to use what's required in each
instance.

The resetting of count was incidental.  I cut a part of my main from
my program that included enough to duplicate what I did throughout to
get an opinion about the correctness.

I have another question on optimizing, but will start a new topic on
the new subject.

It'll take me a few hours to grab a small part and clean it up so that
it will work without the thousand lines of subroutines that are
intertwined with it.

The problem it takes an extremely long time to take 500 lines of colon
delineated data and update a 15,000 record MySQL table.  It takes
between a minute and a  half to three minutes.

-- L. James

--
L. D. James
ljames@apollo3.com
www.apollo3.com/~ljames



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

Date: Tue, 21 Aug 2007 16:40:57 -0000
From:  elroyerni <davechunny@gmail.com>
Subject: writing array to file?
Message-Id: <1187714457.955337.306830@x35g2000prf.googlegroups.com>

Hi -

I have a array that i initialize for using this in my perl script:
my @array_data = qx(cat /home/dchun/logs/$date/stat.log|grep "System
took"|cut -c 56-62);

I know this is really simple but I can't seem to figure it out. How do
i write this array to a text file in my home directory? I just want to
save it for later. If the file already exists, i just want to write
over it.

I tried using a system command.. but that didn't work. Any suggestions
on a simple way to do this?

system `cat /home/ssi9gwy/logs/$date/rco.log|grep "OTS took"|cut -c
56-62 > /u/dchun/rco_stats/$date.rco_stat.log`;



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

Date: Tue, 21 Aug 2007 09:48:32 -0700
From:  Paul Lalli <mritty@gmail.com>
Subject: Re: writing array to file?
Message-Id: <1187714912.386000.231750@r29g2000hsg.googlegroups.com>

On Aug 21, 12:40 pm, elroyerni <davechu...@gmail.com> wrote:
> I have a array that i initialize for using this in my perl script:
> my @array_data = qx(cat /home/dchun/logs/$date/stat.log|grep "System
> took"|cut -c 56-62);

Okay... if you wanted to just do that in Perl rather than shelling out
to three system commands, it would be:

open my $fh, '<', "/home/dchun/logs/$date/stat.log" or die $!;
my @array_data;
while (my $line = <$fh>) {
   if ($line =~ /System took/) {
      push @array_data, substr($line, 55, 6);
   }
}


>
> I know this is really simple but I can't seem to figure it out.
> How do i write this array to a text file in my home directory? I
> just want to save it for later. If the file already exists, i
> just want to write over it.

Open the file for writing, print the array to the file.

open my $ofh, '>', 'file_to_write.txt' or die $!;
for my $line (@array_data) {
  print $ofh "$line\n";
}


> I tried using a system command..

You seem unusually dependent on shelling out to external programs.
Perl is more than a shell scripting language.  You should take some
time to explore the rest of its features.  I suggest you read:
perldoc -f open
perldoc perlopentut
perldoc -f print


> but that didn't work. Any suggestions
> on a simple way to do this?
>
> system `cat /home/ssi9gwy/logs/$date/rco.log|grep "OTS took"|cut -c
> 56-62 > /u/dchun/rco_stats/$date.rco_stat.log`;

This says to run the command between ``, and then attempt to execute
that command's *output*.  backticks execute a command and return the
output.  system() executes a command and returns the return value.


Paul Lalli



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

Date: Tue, 21 Aug 2007 10:02:33 -0700
From: Jim Gibson <jgibson@mail.arc.nasa.gov>
Subject: Re: writing array to file?
Message-Id: <210820071002337955%jgibson@mail.arc.nasa.gov>

In article <1187714457.955337.306830@x35g2000prf.googlegroups.com>,
elroyerni <davechunny@gmail.com> wrote:

> Hi -
> 
> I have a array that i initialize for using this in my perl script:
> my @array_data = qx(cat /home/dchun/logs/$date/stat.log|grep "System
> took"|cut -c 56-62);
> 
> I know this is really simple but I can't seem to figure it out. How do
> i write this array to a text file in my home directory? I just want to
> save it for later. If the file already exists, i just want to write
> over it.
> 
> I tried using a system command.. but that didn't work. Any suggestions
> on a simple way to do this?
> 
> system `cat /home/ssi9gwy/logs/$date/rco.log|grep "OTS took"|cut -c
> 56-62 > /u/dchun/rco_stats/$date.rco_stat.log`;
> 

Perl has input and output facilities for reading and writing files,
regular expressions for searching for patterns in strings, and
functions for manipulating strings. You should consider using them
(untested):

#!/usr/local/bin/perl
#
use warnings;
use strict;
my $date = '???';
my $infile = "/home/ssi9gwy/logs/$date/rco.log";
my $outfile = "/u/dchun/rco_stats/$date.rco_stat.log";
open(my $in, '<', $infile) or die("Can't open $infile: $!");
open(my $out, '>', $outfile) or die("Can't open $outfile: $!");
while(<$in>) {
  next unless /OTS took/;
  print $out substr($_,56,7), "\n";
}
close($in) or die("Error closing $infile: $!");
close($out) or die("Error closing $outfile: $!");
__END__

See
  perldoc -f open
  perldoc -f substr
  perldoc perlre
  perldoc perlop (search for 'I/O Operators')

-- 
Jim Gibson

 Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
    ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------        
                http://www.usenet.com


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

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 V11 Issue 780
**************************************


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