[30877] in Perl-Users-Digest

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

Perl-Users Digest, Issue: 2122 Volume: 11

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jan 14 00:09:43 2009

Date: Tue, 13 Jan 2009 21:09:08 -0800 (PST)
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, 13 Jan 2009     Volume: 11 Number: 2122

Today's topics:
    Re: Function like print with optional filehandle? <tadmc@seesig.invalid>
    Re: Function like print with optional filehandle? (Tim McDaniel)
    Re: Function like print with optional filehandle? xhoster@gmail.com
        Getting a temporary file name. <ryan.mccoskrie@gmail.com>
    Re: Getting a temporary file name. <spamtrap@dot-app.org>
    Re: Getting a temporary file name. <tadmc@seesig.invalid>
    Re: how to encrypt password stored in ftp script <woland99@gmail.com>
    Re: opening a file <george@example.invalid>
    Re: opening a file <tim@burlyhost.com>
    Re: opening a file <tim@burlyhost.com>
        unable to open file <"kteague at pobox dot com">
    Re: unable to open file <jurgenex@hotmail.com>
    Re: unable to open file <jimsgibson@gmail.com>
    Re: unable to open file <"kteague at pobox dot com">
    Re: unable to open file <tim@burlyhost.com>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

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

Date: Tue, 13 Jan 2009 15:22:50 -0600
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: Function like print with optional filehandle?
Message-Id: <slrngmq1ha.lgf.tadmc@tadmc30.sbcglobal.net>

Steve Roscio <Steve.Roscio@hp.com> wrote:

> How do I write a function that accepts arguments like print(), 


You can't.

You can write one that accepts arguments almost like print though...


> where a 
> filehandle is optional.  For example, a function myprint() that can be 
> used like this:
>
> 	myprint "foo", "bar";
> 	myprint STDERR "foo", "bar";
                ^^^^^^

This one cannot be done, but that isn't much of a handicap since
it is a form of only historical interest.


> 	myprint $fh "foo", "bar";
> 	myprint {$xyz->{fh}} "foo", "bar";
                ^          ^
                ^          ^ a hash ref?


------------------------
#!/usr/bin/perl
use warnings;
use strict;

sub myprint {
    if ( ref $_[0] eq 'GLOB' )
        { print {shift} @_ }
    else
        { print @_ }
}

open my $fh, '>', "out.1" or die "could not open $!";

my $xyz;
open $xyz->{fh}, '>', "out.2" or die "could not open $!";

myprint "foo", "bar";
myprint $fh, "foo1", "bar1";
myprint $xyz->{fh}, "foo2", "bar2";
------------------------


-- 
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"


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

Date: Tue, 13 Jan 2009 21:41:13 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Function like print with optional filehandle?
Message-Id: <gkj1pp$dm6$1@reader1.panix.com>

In article <slrngmq1ha.lgf.tadmc@tadmc30.sbcglobal.net>,
Tad J McClellan  <tadmc@seesig.invalid> wrote:
>Steve Roscio <Steve.Roscio@hp.com> wrote:
>> 	myprint {$xyz->{fh}} "foo", "bar";
>                ^          ^
>                ^          ^ a hash ref?

A code ref.  "man perlsub" shows how users could declare their own
subs with prototypes that match those of builtin functions.  One
example is

    sub mygrep (&@)    mygrep { /foo/ } $a, $b, $c
           
-- 
Tim McDaniel, tmcd@panix.com


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

Date: 14 Jan 2009 00:16:37 GMT
From: xhoster@gmail.com
Subject: Re: Function like print with optional filehandle?
Message-Id: <20090113191903.082$q7@newsreader.com>

tmcd@panix.com (Tim McDaniel) wrote:
> In article <slrngmq1ha.lgf.tadmc@tadmc30.sbcglobal.net>,
> Tad J McClellan  <tadmc@seesig.invalid> wrote:
> >Steve Roscio <Steve.Roscio@hp.com> wrote:
> >>      myprint {$xyz->{fh}} "foo", "bar";
> >                ^          ^
> >                ^          ^ a hash ref?
>
> A code ref.  "man perlsub" shows how users could declare their own
> subs with prototypes that match those of builtin functions.  One
> example is

Since he specified he wants it to behave like print, then he wants it
to be neither a hashref nor a coderef, but rather a code-block, which is
what it would be with print.

>     sub mygrep (&@)    mygrep { /foo/ } $a, $b, $c

But in the absence of a prototype, it seems to be interpreted as a code
block, whose value is interpreted as an OO indirect object notation.  He
could use your prototype and then invoke the passed coderef to get the
handle to print to, but then the argument could no longer be optional, and
would have to wrapped in curlies even if it were a simple scalar.

Xho

-- 
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.


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

Date: Wed, 14 Jan 2009 12:05:34 +1300
From: Ryan McCoskrie <ryan.mccoskrie@gmail.com>
Subject: Getting a temporary file name.
Message-Id: <gkj6ol$lc$1@news.albasani.net>

I'm working on a two pass assembler cross assembler
in perl and I need a temporary file name to hold data
from the first pass.
Is there something like mkstemp(3) or tmpfile(3) that
I can use in perl?
-- 
Before you ask more questions, think about whether you really want to
know the answers.
		-- Gene Wolfe, "The Claw of the Conciliator"


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

Date: Tue, 13 Jan 2009 18:18:44 -0500
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: Getting a temporary file name.
Message-Id: <m1eiz6iyln.fsf@dot-app.org>

Ryan McCoskrie <ryan.mccoskrie@gmail.com> writes:

> I'm working on a two pass assembler cross assembler
> in perl and I need a temporary file name to hold data
> from the first pass.
> Is there something like mkstemp(3) or tmpfile(3) that
> I can use in perl?

If you need to know the filename, have a look at File::Temp - it's been part
of core Perl for a good long while now.

See 'perldoc -q temp' for more.

sherm--

-- 
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net


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

Date: Tue, 13 Jan 2009 17:22:53 -0600
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: Getting a temporary file name.
Message-Id: <slrngmq8id.nij.tadmc@tadmc30.sbcglobal.net>

Ryan McCoskrie <ryan.mccoskrie@gmail.com> wrote:
> I'm working on a two pass assembler cross assembler
> in perl and I need a temporary file name to hold data
> from the first pass.
> Is there something like mkstemp(3) or tmpfile(3) that
> I can use in perl?


    perldoc -q temporary


       How do I make a temporary file name?


-- 
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"


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

Date: Tue, 13 Jan 2009 17:27:26 -0800 (PST)
From: Woland99 <woland99@gmail.com>
Subject: Re: how to encrypt password stored in ftp script
Message-Id: <2bcc4a68-937c-4b7e-b6d4-996d7522630b@f20g2000yqg.googlegroups.com>

On Jan 12, 2:07=A0pm, Tim Greer <t...@burlyhost.com> wrote:
> Woland99 wrote:
> > Howdy - I want my script to make connection to FTP server and get some
> > files. I need that script to run everyday automatically on machine
> > that many people
> > have access to - but I do not want them to know the username or
> > password for that
> > FTP server. Is there a way to save encrypted password with the script
> > but prevent
> > people form modifying script to access the FTP server for different
> > purposes?
>
> > JT
>
> FTP is clear text, you can't encrypt it, unless you decrypt somewhere in
> the process (or on the other end), which probably defeats the purpose,
> since that's the method someone else would just be able to use anyway.
> I could only suggest using sftp, scp or rsync over SSH with a trusted
> key. =A0Of course, the problem is, if people have access to the system,
> it doesn't matter a whole lot, since the trusted key allows them access
> without a password. =A0Otherwise, they can see the password in plain
> text, which means they have the same trusted access once authenticated
> -- and besides having that access, they have the password as well.
>
> You can also time it with firewalls to only allow connections from the
> system to the server at certain times. =A0The best solution, is if you're
> uploading from the system, is to find the most secure way of doing it,
> but make it so that the FTP account it uploads to, is separate from
> anything else (not full or other access to the remote account you
> upload to). =A0Make it so you can only upload (the files can be hidden
> from view on the client end once they are uploaded). =A0For the script
> initiating this, you can try and hide the file name, the job, and also
> make it so only your user has read permissions on the script used (the
> last part is the most important -- how are you at risk of others
> reading the script or being able to log into your account that runs
> this process? =A0That's the biggest problem you should find a resolution
> for). =A0You make it sound like this is a system that anyone can access,
> is that the case? =A0If so, what's stopping people from reading any of
> your data or modifying that data?
>
> Ultimately, if this is a system where anyone can access and somehow view
> or gain access to the script or password, you should initiate the FTP
> session (or better yet, a more secure method) from the _server_ side
> (where you want the files stored) and have it connect to the system and
> transfer the files _from_ it, which is the best scenario in this case
> regardless of how people can access it (assuming the other end is more
> secure). =A0That way, none of the other users on the system you're
> wanting to transfer files from, will have a way to access the server
> end. =A0You can do that with trusted keys or some more secure transfer
> method, but FTP will work fine as well, assuming the server end can be
> trusted with the same dilemma you have on the system in question.
> --
> Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
> Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
> and Custom Hosting. =A024/7 support, 30 day guarantee, secure servers.
> Industry's most experienced staff! -- Web Hosting With Muscle!

Thanks for your comments - indeed the general concerns about data
security (on top of not giving away FTP login/passwd) are valid -
basically once I download files from the server I need to provide
some level of security for it. I do not know much at all about
security or encryption but my idea for protecting passwd/login
info in the script was something along the line:
I would have file containing encrypted password that would be
generated using encryption key. Using same key I could create
digital signature of the script that would try to get the password
out of that file. So everytime I edit the script I would need to
reset its digital signature in the file contains encrypted password.
If script comes in and asks for passwd and the digital signature
of the script (computed at that point) matches the signature that
was last stored with passwd then it would be give the password
value. Sorry if that is all gibberish - as I said security and
encryprions are a bit of new area for me.


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

Date: Tue, 13 Jan 2009 19:04:35 -0700
From: George <george@example.invalid>
Subject: Re: opening a file
Message-Id: <1gzbqhp11r5ax$.1dkazrleub26f$.dlg@40tude.net>

On Mon, 12 Jan 2009 10:38:35 +0100, Peter J. Holzer wrote:

>> Wir meinen damit daß das abwertend ist, fortran sonstwo zu üben.
>>
>> This translates as:
>>
>> We mean that the pejorative is fortran elsewhere to practice.
> 
> Your translation isn't correct, but it's quite good at a meta level: It
> sounds about as wrong in English as the original sounds wrong in German.
> I don't know Catherine, much less how how good her German is, but I see
> two possibilities:
> 
> 1) Her German isn't very good.
> 
> 2) Her German is very good and she made errors on purpose to make the
>    point: To me as a German speaker the sentence sounds about as wrong
>    as Mirco's script looks wrong to me as a Perl programmer. No German
>    speaker would say this sentence (except as a parody on non-native
>    Speakers) and no Perl programmer would write a script like Mirco's
>    (except as a parody on Fortran). Just like you can't translate
>    literally from one natural language to another word by word, you
>    can't translate literally from one programming language to another.
>    The result may "work", but it isn't pretty.

I think you misunderestimate my ability to adhere to an idiom, but I took a
gander at Duden 2: Stilwörterbuch to see what the definitive german
reference has to say.

In § V 2 they list the Nuancierungen:
scherzhaft
ironisch
abwertend
nachdrücklich
verhüllend
, where "abwertend" kennzeichnet eine Aussage, die ein ablehnendes Urteil
enthält: Schiebung, Wisch.

Whatever joke there was has clearly waned, but I have one more question
about this material.  Earlier you advised to use lexical filehandles,
something like:

open(my $fh, '<', $filename) or die "cannot open $filename: $!";

In chapter one of the camel book in the filehandles section, it just uses:

open(SESAME, "filename");

How does this differ from

open(my $SESAME, "filename");

, and does it make a difference?
-- 
George

On September 11 2001, America felt its vulnerability even to threats that
gather on the other side of the Earth. We resolved then, and we are
resolved today, to confront every threat from any source that could bring
sudden terror and suffering to America.
George W. Bush

Picture of the Day http://apod.nasa.gov/apod/


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

Date: Tue, 13 Jan 2009 18:40:18 -0800
From: Tim Greer <tim@burlyhost.com>
Subject: Re: opening a file
Message-Id: <ngcbl.7929$1L3.4728@newsfe20.iad>

George wrote:

> Whatever joke there was has clearly waned, but I have one more
> question about this material.  Earlier you advised to use lexical
> filehandles, something like:
> 
> open(my $fh, '<', $filename) or die "cannot open $filename: $!";
> 
> In chapter one of the camel book in the filehandles section, it just
> uses:
> 
> open(SESAME, "filename");
> 
> How does this differ from
> 
> open(my $SESAME, "filename");
> 
> , and does it make a difference?

The three argument method is simply the preferred way now.  Things
evolve over time and this has become the preferred method for many. 
There's really not a difference in a matter of speaking, it can just
make things easier down the road.  Having an argument for the
redirection character can sometimes make you think about what you're
doing and specifically specify the redirect character you want to use.

For example, instead of open(FILE, "file") or die $!, where it's opening
for 'read' by default, you tell it to specifically read open my
$filehandle, '<', "filename" or die $!.  I've seen a lot of people ask
why their files weren't updated and they didn't recall to add the
proper redirect character (>, >>, or whatever) to their open function. 
You can use whichever you feel more confortable with.  You should still
check if it was successful and report the failure (and why) if not.
-- 
Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
and Custom Hosting.  24/7 support, 30 day guarantee, secure servers.
Industry's most experienced staff! -- Web Hosting With Muscle!


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

Date: Tue, 13 Jan 2009 18:49:16 -0800
From: Tim Greer <tim@burlyhost.com>
Subject: Re: opening a file
Message-Id: <Nocbl.7930$1L3.1510@newsfe20.iad>

Tim Greer wrote:

> George wrote:
> 
>> Whatever joke there was has clearly waned, but I have one more
>> question about this material.  Earlier you advised to use lexical
>> filehandles, something like:
>> 
>> open(my $fh, '<', $filename) or die "cannot open $filename: $!";
>> 
>> In chapter one of the camel book in the filehandles section, it just
>> uses:
>> 
>> open(SESAME, "filename");
>> 
>> How does this differ from
>> 
>> open(my $SESAME, "filename");
>> 
>> , and does it make a difference?
> 
> The three argument method is simply the preferred way now.  Things
> evolve over time and this has become the preferred method for many.
> There's really not a difference in a matter of speaking, it can just
> make things easier down the road.  Having an argument for the
> redirection character can sometimes make you think about what you're
> doing and specifically specify the redirect character you want to use.
> 
> For example, instead of open(FILE, "file") or die $!, where it's
> opening for 'read' by default, you tell it to specifically read open
> my
> $filehandle, '<', "filename" or die $!.  I've seen a lot of people ask
> why their files weren't updated and they didn't recall to add the
> proper redirect character (>, >>, or whatever) to their open function.
> You can use whichever you feel more confortable with.  You should
> still check if it was successful and report the failure (and why) if
> not.

I misspoke that there are really no differences, as there actually are,
depending on the scenario.  Also, I should have actually added more
details about indirect file handles above.  However, instead of
repeating a few of the advantages to the three-argument open and
indirect file handles, please refer to
perldoc -f open  (on the web at 
http://perldoc.perl.org/functions/open.html)

As well as, you can get read up quickly at:
http://perldoc.perl.org/perlopentut.html  Specifically, refer to
"Simple Opens" and the latter mentioned 3-argument version.  Directly
below is "Indirect Filehandles", which you should find of particular
interest.  These outline the differences, again depending on the
scenario and provide all of the gory details.
-- 
Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
and Custom Hosting.  24/7 support, 30 day guarantee, secure servers.
Industry's most experienced staff! -- Web Hosting With Muscle!


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

Date: Tue, 13 Jan 2009 16:03:21 -0800
From: Ken Teague <"kteague at pobox dot com">
Subject: unable to open file
Message-Id: <98ydnatcoNdRtvDUnZ2dnUVZ_gWdnZ2d@giganews.com>

I've been tasked with fixing a broken web page which includes a perl
script.  I must warn you that I'm really new to perl, so please bear
with me.  Basically, the web page has a form with a search function.
The user inputs a number and it's supposed to open another page called
prodscript.html, but I'm getting an error "Can't open file prodscript.html!"

The file does exist in the /cgi-bin directory where the perl script is
located.  I've got a copy of the perl script at
http://pastebin.com/d65c8c4d2 or http://erxz.com/pb/14785 for your
viewing pleasure.

The HTML source to the web form in question is
http://pastebin.com/d321ddb08 and, no matter if I input a valid search
number or not, I tend to get the same error.  After inputting a search
criteria, it should be taking me to the prodscript.html page with a link
to the PDF.

It appears that it's failing here:
  (my $head, my $tmp, my $foot) = get_html($HTML_template);
 ... then, jumping down to the get_html subroutine, it calls for the
read_file subroutine:
  sub get_html{
	my @txt = read_file($_[0]);
 ... then read_file tries to open prodscript.html
  sub read_file{
	open(F, $_[0]) || error("Can't open file $_[0]!");
 ... which gives me the error.  Why?  If you need more information that
I've disclosed, please follow-up in a private e-mail.

At first, I thought it was a file permission issue, but I can open
prodscript.html by inputting its full path in my browser.

Alegedly, the only thing that has changed since this was working until
now is the server was upgraded from Winders 2000 to Winders 2003.

Any help is greatly appreciated.  Thanks in advance.

- Ken


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

Date: Tue, 13 Jan 2009 16:45:40 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: unable to open file
Message-Id: <u9dqm45ed5f9si6865ujpms5grtmbht7ie@4ax.com>

Ken Teague <"kteague at pobox dot com"> wrote:

>	open(F, $_[0]) || error("Can't open file $_[0]!");
>... which gives me the error.  Why?  

Ask perl to tell you why it can't open the file:
	open(F, $_[0]) or error("Can't open file $_[0] because $! !");

jue


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

Date: Tue, 13 Jan 2009 16:50:19 -0800
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: unable to open file
Message-Id: <130120091650190072%jimsgibson@gmail.com>

In article <98ydnatcoNdRtvDUnZ2dnUVZ_gWdnZ2d@giganews.com>, Ken Teague
wrote:

> I've been tasked with fixing a broken web page which includes a perl
> script.  I must warn you that I'm really new to perl, so please bear
> with me.  Basically, the web page has a form with a search function.
> The user inputs a number and it's supposed to open another page called
> prodscript.html, but I'm getting an error "Can't open file prodscript.html!"
> 
> The file does exist in the /cgi-bin directory where the perl script is
> located.  I've got a copy of the perl script at
> http://pastebin.com/d65c8c4d2 or http://erxz.com/pb/14785 for your
> viewing pleasure.

[program excerpts snipped]

Try adding the full path to prodscript.html to the $HTML_template
variable. It is likely that the default directory is not the cgi-bin
directory when the Perl script executes.

-- 
Jim Gibson


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

Date: Tue, 13 Jan 2009 17:10:26 -0800
From: Ken Teague <"kteague at pobox dot com">
To: =?ISO-8859-1?Q?J=FCrgen_Exner?= <jurgenex@hotmail.com>
Subject: Re: unable to open file
Message-Id: <bYydnfMR248YpvDUnZ2dnUVZ_oidnZ2d@giganews.com>

J=FCrgen Exner wrote:
> Ask perl to tell you why it can't open the file:
> 	open(F, $_[0]) or error("Can't open file $_[0] because $! !");


Thanks, Jue.  "No such file or directory", which seems to lead to what
Jim is hinting to me in his follow-up reply.

Jim Gibson wrote:
> Try adding the full path to prodscript.html to the $HTML_template
> variable. It is likely that the default directory is not the cgi-bin
> directory when the Perl script executes.

Thanks, Jim.  After adding the extra code that Jue recommended, it looks
like you're right.  As far as adding the full path, I tried different
variations of paths without luck:
  * full windows file system path
  * full HTML path (/cgi-bin/prodscript.html and /htdocs/prodscript.html)=

  * relative path (./prodscript.html and .\prodscript.html)

Which path would it want?  The HTML path or file system path?  Is there
a way I could avoid absolute paths?  I tend to think they're evil in
source.  Thanks again!

- Ken


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

Date: Tue, 13 Jan 2009 18:31:47 -0800
From: Tim Greer <tim@burlyhost.com>
Subject: Re: unable to open file
Message-Id: <n8cbl.7928$1L3.1604@newsfe20.iad>

Ken Teague <"kteague at pobox dot com"> wrote:

> Jürgen Exner wrote:
>> Ask perl to tell you why it can't open the file:
>> open(F, $_[0]) or error("Can't open file $_[0] because $! !");
> 
> 
> Thanks, Jue.  "No such file or directory", which seems to lead to what
> Jim is hinting to me in his follow-up reply.
> 
> Jim Gibson wrote:
>> Try adding the full path to prodscript.html to the $HTML_template
>> variable. It is likely that the default directory is not the cgi-bin
>> directory when the Perl script executes.
> 
> Thanks, Jim.  After adding the extra code that Jue recommended, it
> looks
> like you're right.  As far as adding the full path, I tried different
> variations of paths without luck:
>   * full windows file system path
>   * full HTML path (/cgi-bin/prodscript.html and
>   /htdocs/prodscript.html) * relative path (./prodscript.html and
>   .\prodscript.html)
> 
> Which path would it want?  The HTML path or file system path?  Is
> there
> a way I could avoid absolute paths?  I tend to think they're evil in
> source.  Thanks again!
> 
> - Ken

Sometimes people mistake the absolute path.  If the file is there and
readable, then it must be some type of permissions on the file itself
or one of the directories in its path, or otherwise the wrong path --
in most situations anyway.  Did you do a test output to see the current
working directory, and what it would be in relation to the path to the
file?  If the file is in the cgi-bin directory, you shouldn't be able
to view a normal HTML file within it, unless it's not a true script
aliased directory.  Either way, you could create a script to upload to
the cgi-bin directory and have it output the environment to see what
the relative and absolute paths should be (in case you are mistaken
about the path).
-- 
Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
and Custom Hosting.  24/7 support, 30 day guarantee, secure servers.
Industry's most experienced staff! -- Web Hosting With Muscle!


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

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


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