[30227] in Perl-Users-Digest
Perl-Users Digest, Issue: 1470 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Apr 22 17:27:54 2008
Date: Tue, 22 Apr 2008 14:27:41 -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, 22 Apr 2008 Volume: 11 Number: 1470
Today's topics:
Unlink command for opened files <prasanths89@gmail.com>
Re: Unlink command for opened files <joost@zeekat.nl>
Re: Unlink command for opened files <1usa@llenroc.ude.invalid>
Re: Unlink command for opened files <1usa@llenroc.ude.invalid>
Re: Unlink command for opened files <ben@morrow.me.uk>
Re: Unlink command for opened files <jurgenex@hotmail.com>
Re: Unlink command for opened files <syscjm@sumire.gwu.edu>
Re: Unlink command for opened files xhoster@gmail.com
Re: Unlink command for opened files <jurgenex@hotmail.com>
Re: Unlink command for opened files <ben@morrow.me.uk>
weird bug <socyl@987jk.com.invalid>
Re: weird bug xhoster@gmail.com
Re: weird bug <ben@morrow.me.uk>
Re: weird bug xhoster@gmail.com
Re: weird bug <ben@morrow.me.uk>
win32api::file translation of c-code to perl: help pls <swest@gmx.de>
Re: win32api::file translation of c-code to perl: help <smallpond@juno.com>
WWW::Mechanize doesn't always follow_link(text <mikaelb@df.lth.se>
Re: WWW::Mechanize doesn't always follow_link(text <john@castleamber.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 16 Apr 2008 06:06:51 -0700 (PDT)
From: Prasanth <prasanths89@gmail.com>
Subject: Unlink command for opened files
Message-Id: <270a0c78-9d5e-4486-8b35-b429c4d61755@u36g2000prf.googlegroups.com>
When a file is open does unlink automatically deletes the file or it
generates an error. Because I wrote a program to delete a file and
regenerate the file. if the file is not deleted the data simply gets
appended to the existing file. which results in wrong results
------------------------------
Date: Wed, 16 Apr 2008 15:21:27 +0200
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: Unlink command for opened files
Message-Id: <87hce2gcko.fsf@zeekat.nl>
Prasanth <prasanths89@gmail.com> writes:
> When a file is open does unlink automatically deletes the file or it
> generates an error. Because I wrote a program to delete a file and
> regenerate the file. if the file is not deleted the data simply gets
> appended to the existing file. which results in wrong results
Unlink removes inodes, and it should succeed in that even if the file is
opened by any process. It does not empty files, if that's what you mean.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: Wed, 16 Apr 2008 13:25:16 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Unlink command for opened files
Message-Id: <Xns9A825FD49BA57asu1cornelledu@127.0.0.1>
Prasanth <prasanths89@gmail.com> wrote in
news:270a0c78-9d5e-4486-8b35-b429c4d61755
@u36g2000prf.googlegroups.co
m:
> When a file is open does unlink automatically deletes the file or
> it generates an error. Because I wrote a program to delete a file
> and regenerate the file. if the file is not deleted the data
> simply gets appended to the existing file. which results in wrong
> results
Hmmmm ... What is the question?
If you script opened the file, close it before calling unlink.
If the file is opened in exclusive mode by another process, I am not
sure deleting it is the correct action in the first place.
If you don't want your script to continue if unlink failed, you
should check the return value of unlink.
On the other hand, not that this will solve whatever problem you are
having, I would not have messed with unlink at all:
open my $out_h, '>', 'report.txt'
or die "Cannot open 'report.txt': $!";
That truncates the file if it can be opened and would die if it
cannot. Beats appending junk to a file.
There are just two many combinations of problems and solutions that
might apply to your post. Please elaborate after reading the posting
guidelines for this group and may be taking a look at the following
page:
http://blogs.msdn.com/oldnewthing/archive/2008/04/15/8397753.aspx
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
------------------------------
Date: Wed, 16 Apr 2008 13:29:19 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Unlink command for opened files
Message-Id: <Xns9A826084CF564asu1cornelledu@127.0.0.1>
Joost Diepenmaat <joost@zeekat.nl> wrote in
news:87hce2gcko.fsf@zeekat.nl:
> Prasanth <prasanths89@gmail.com> writes:
>
>> When a file is open does unlink automatically deletes the file or
>> it generates an error. Because I wrote a program to delete a file
>> and regenerate the file. if the file is not deleted the data
>> simply gets appended to the existing file. which results in wrong
>> results
>
> Unlink removes inodes, and it should succeed in that even if the
> file is opened by any process. It does not empty files, if that's
> what you mean.
I am guessing the OP is on Windows where
http://windowshelp.microsoft.com/Windows/en-US/help/47b3ce2b-3aec-401d-8be3-74434a1999831033.mspx
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
------------------------------
Date: Wed, 16 Apr 2008 14:56:23 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Unlink command for opened files
Message-Id: <75dhd5-vce.ln1@osiris.mauzo.dyndns.org>
Quoth Joost Diepenmaat <joost@zeekat.nl>:
> Prasanth <prasanths89@gmail.com> writes:
>
> > When a file is open does unlink automatically deletes the file or it
> > generates an error. Because I wrote a program to delete a file and
> > regenerate the file. if the file is not deleted the data simply gets
> > appended to the existing file. which results in wrong results
>
> Unlink removes inodes, and it should succeed in that even if the file is
> opened by any process. It does not empty files, if that's what you mean.
Unlink removes *filenames*. Inodes are refcounted, and self-destruct
when there are no refs to them (including open file descriptors).
This only applies to Unixish filesystems, of course. Win32 won't let
you unlink an open file (under normal circumstances).
Ben
------------------------------
Date: Wed, 16 Apr 2008 15:08:40 GMT
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Unlink command for opened files
Message-Id: <1i5c045g412bbmljt3b2131qdpueotjcv6@4ax.com>
Prasanth <prasanths89@gmail.com> wrote:
>When a file is open does unlink automatically deletes the file or it
>generates an error.
That depends on the file system and/or operating system that you are
using.
jue
------------------------------
Date: Wed, 16 Apr 2008 10:46:40 -0500
From: Chris Mattern <syscjm@sumire.gwu.edu>
Subject: Re: Unlink command for opened files
Message-Id: <slrng0c7qt.d0a.syscjm@sumire.gwu.edu>
On 2008-04-16, Prasanth <prasanths89@gmail.com> wrote:
> When a file is open does unlink automatically deletes the file or it
> generates an error. Because I wrote a program to delete a file and
> regenerate the file. if the file is not deleted the data simply gets
> appended to the existing file. which results in wrong results
This is not a Perl question, this is a question about the filesystem
semantics for your particular operating system; the answer can differ
from OS to OS. I'll talk about Unix/Linux, because that's the one I
understand :-). In Unix/Linux, when you delete the file, you actually
only delete the directory entry for the file. If there are other directory
entries for the file (that is what a hard link is) it will continue to
exist and be accessible under the other pathnames. If you are holding the
file open, the file will continue to exist and it will accessible by the
file handle you have. You will not get any error message or code because
no error has occured; the directory entry was deleted without error. The
file will not actually be marked as free space until all directory entries
are unlinked and no process holds it open. However, the file has no association
with the old name any more: if you create a new file with the same name, you
will not get the old file back, you will get a new, empty file.
--
Christopher Mattern
NOTICE
Thank you for noticing this new notice
Your noticing it has been noted
And will be reported to the authorities
------------------------------
Date: 16 Apr 2008 16:39:43 GMT
From: xhoster@gmail.com
Subject: Re: Unlink command for opened files
Message-Id: <20080416123945.436$Gc@newsreader.com>
Prasanth <prasanths89@gmail.com> wrote:
> When a file is open does unlink automatically deletes the file or it
> generates an error. Because I wrote a program to delete a file and
> regenerate the file. if the file is not deleted the data simply gets
> appended to the existing file. which results in wrong results
This depends on your OS.
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, 16 Apr 2008 16:56:36 GMT
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Unlink command for opened files
Message-Id: <akbc04ls86vcd19s683hb38b41rhncflqv@4ax.com>
Chris Mattern <syscjm@sumire.gwu.edu> wrote:
>On 2008-04-16, Prasanth <prasanths89@gmail.com> wrote:
>> When a file is open does unlink automatically deletes the file or it
>> generates an error. Because I wrote a program to delete a file and
>> regenerate the file. if the file is not deleted the data simply gets
>> appended to the existing file. which results in wrong results
>
>This is not a Perl question, this is a question about the filesystem
>semantics for your particular operating system; the answer can differ
>from OS to OS. I'll talk about Unix/Linux, because that's the one I
>understand :-). In Unix/Linux, when you delete the file, you actually
>only delete the directory entry for the file.
This is getting somewhat off topic, but now you triggered my curiousity.
Does the behaviour really depend on the OS (as you seem to imply) or
does it depend on the file system? Or on both?
Example: FAT32 mounted on Linux. FAT32 does not have inodes or link
counts and I would guess that Linux would not allow deletion of a file
from a FAT32 partition as long as there is an open file descriptor
dangling. Is this true or does Linux simulate an inode and link count
structure on top of FAT?
jue
jue
------------------------------
Date: Wed, 16 Apr 2008 18:27:19 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Unlink command for opened files
Message-Id: <ngphd5-dpl1.ln1@osiris.mauzo.dyndns.org>
Quoth Jürgen Exner <jurgenex@hotmail.com>:
>
> This is getting somewhat off topic, but now you triggered my curiousity.
> Does the behaviour really depend on the OS (as you seem to imply) or
> does it depend on the file system? Or on both?
> Example: FAT32 mounted on Linux. FAT32 does not have inodes or link
> counts and I would guess that Linux would not allow deletion of a file
> from a FAT32 partition as long as there is an open file descriptor
> dangling. Is this true or does Linux simulate an inode and link count
> structure on top of FAT?
For both FAT and NFS (which doesn't support close-behind either) Linux
will fake the unlink by renaming the file to something 'unique', and
really deleting it after it's closed. Grep the kernel source for
'sillyrename'.
I don't know if all OSen provide (or attempt to provide) consistent
semantics across all filesystems they support.
Ben
------------------------------
Date: Fri, 18 Apr 2008 17:27:10 +0000 (UTC)
From: kj <socyl@987jk.com.invalid>
Subject: weird bug
Message-Id: <fualle$7ms$1@reader2.panix.com>
The following short module illustrates a puzzling bug:
use strict;
package Foo;
my $x = +{ 1 => 'one' };
sub foo {
keys %$x if 0; # should do nothing
my $y = eval '$x'; die if $@;
printf "%d\n", scalar keys %$y;
}
1;
__END__
OK, now: the following one-liner produces the expected output:
% perl -MFoo -e 'Foo::foo()'
1
...but if one comments-out the first line of Foo::foo, the output changes:
% perl -MFoo -e 'Foo::foo()'
0
Note that the line that was commented out should do nothing, because
it ends with the conditional qualifier "if 0". Therefore, this
line is essentially a no-op and should have absolutely no effect
on the execution of this code.
I'm seeing this behavior with v. 5.8.8. Does anyone see it also
with more recent versions?
I have no doubt that this is a bug, but I can't begin to figure
out why it's happening. Any light that may be thrown on this puzzle
would be much appreciated.
Also, is there a better solution to this problem than including
silly "voodoo code" like the first line in Foo::foo?
TIA!
Kynn
--
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.
------------------------------
Date: 18 Apr 2008 17:51:32 GMT
From: xhoster@gmail.com
Subject: Re: weird bug
Message-Id: <20080418135133.960$h5@newsreader.com>
kj <socyl@987jk.com.invalid> wrote:
> The following short module illustrates a puzzling bug:
>
> use strict;
> package Foo;
> my $x = +{ 1 => 'one' };
>
> sub foo {
> keys %$x if 0; # should do nothing
> my $y = eval '$x'; die if $@;
> printf "%d\n", scalar keys %$y;
> }
>
> 1;
> __END__
The appearance of $x in %$x causes the subroutine to take out and
hold a "reference" to $x. The appearance of $x in the string eval
doesn't cause that happen. I assume that when the __END__ is encountered,
the "my $x" goes out of scope, decrementing the refcount. In the one
case, the refcount is decremented to zero, and $x is freed. Later, when
the string eval is invoked, it operates on this freed $x.
> Also, is there a better solution to this problem than including
> silly "voodoo code" like the first line in Foo::foo?
Change
my $y = eval '$x';
to
my $y = eval {$x};
That way, the use of $x is not hidden from the subroutine so it knows to
keep a reference to $x.
Unless there is a good reason you were using '$x' instead of {$x} in the
first place. I can't think of such a reason off the top of my head.
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: Fri, 18 Apr 2008 18:59:42 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: weird bug
Message-Id: <e54nd5-pi7.ln1@osiris.mauzo.dyndns.org>
Quoth kj <socyl@987jk.com.invalid>:
>
> The following short module illustrates a puzzling bug:
>
> use strict;
> package Foo;
> my $x = +{ 1 => 'one' };
>
> sub foo {
> keys %$x if 0; # should do nothing
> my $y = eval '$x'; die if $@;
> printf "%d\n", scalar keys %$y;
> }
>
> 1;
> __END__
>
>
> OK, now: the following one-liner produces the expected output:
>
> % perl -MFoo -e 'Foo::foo()'
> 1
>
> ...but if one comments-out the first line of Foo::foo, the output changes:
>
> % perl -MFoo -e 'Foo::foo()'
> 0
This can be reduced to
package Foo;
my $x = 1;
sub foo {
#$x;
my $y = eval '$x';
printf "from %s: %s\n",
scalar caller, defined $y ? $y : '<undef>';
}
foo;
1;
which gives
~% perl -MFoo -eFoo::foo
from Foo: 1
from main: <undef>
with all perls I have to hand (5.6, 5.8, 5.10, blead). This is a
longstanding bug in eval STRING: it won't capture variables from an
outer lexical scope unless they are explicitly mentioned in the
immediately surrounding scope. Any mention, such as the line commented
out, is sufficient.
What I don't understand is 1. why it works when called from the same
file and 2. I though this had been fixed in 5.10. I guess not...
> Also, is there a better solution to this problem than including
> silly "voodoo code" like the first line in Foo::foo?
Fix perl's eval-handling to work properly? :)
Ben
------------------------------
Date: 18 Apr 2008 18:27:28 GMT
From: xhoster@gmail.com
Subject: Re: weird bug
Message-Id: <20080418142730.948$VT@newsreader.com>
Ben Morrow <ben@morrow.me.uk> wrote:
>
> This can be reduced to
>
> package Foo;
> my $x = 1;
> sub foo {
> #$x;
> my $y = eval '$x';
> printf "from %s: %s\n",
> scalar caller, defined $y ? $y : '<undef>';
> }
> foo;
> 1;
>
> which gives
>
> ~% perl -MFoo -eFoo::foo
> from Foo: 1
> from main: <undef>
>
> with all perls I have to hand (5.6, 5.8, 5.10, blead). This is a
> longstanding bug in eval STRING: it won't capture variables from an
> outer lexical scope unless they are explicitly mentioned in the
> immediately surrounding scope. Any mention, such as the line commented
> out, is sufficient.
>
> What I don't understand is 1. why it works when called from the same
> file
When it is called in the same file, the variable is still "in scope" in its
own right because the file scope has not yet ended. Once the file
scope has ended, the variable contents are destroyed unless something else
(like a subroutine stuffed into the symbol table) keeps it alive.
By replacing file-scope with extra curlies, you can get the same thing
without using packages.
perl -le ' {my $x=1; sub foo { print eval q{$x}}; foo; } foo;'
I don't see how this could be fixed. Either you parse the eval string
at compile time (which is not usually possible--if the string can't
change between compile time and run time, why use string eval rather than
block eval in the first place?), or you don't do garbage collection on any
lexical variable which happens to be in scope when a string eval is
encountered during the compilation pass. Or maybe when using a variable
whose contents have already been freed should throw an error rather than
treating it as undefined.
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: Fri, 18 Apr 2008 20:08:05 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: weird bug
Message-Id: <l58nd5-2p8.ln1@osiris.mauzo.dyndns.org>
Quoth xhoster@gmail.com:
> Ben Morrow <ben@morrow.me.uk> wrote:
> >
> > What I don't understand is 1. why it works when called from the same
> > file
>
> When it is called in the same file, the variable is still "in scope" in its
> own right because the file scope has not yet ended. Once the file
> scope has ended, the variable contents are destroyed unless something else
> (like a subroutine stuffed into the symbol table) keeps it alive.
Yup. Thank you: I was confusing locating an entry in the lexical pad
with refcounting of the contents of that entry.
Ben
------------------------------
Date: Mon, 21 Apr 2008 15:20:19 +0200
From: Susanne West <swest@gmx.de>
Subject: win32api::file translation of c-code to perl: help pls
Message-Id: <6a9aa$480c9492$544b8434$20257@news.hispeed.ch>
i have the following c-code that sould send out a
command through deviceIO using win32api::file, and
i'm struggling with the proper handling of the code.
the result of my DeviceIoControl() command is always
NULL...
#! perl
# -------------------------------
# c-code:
# define BUFF_SIZE 0x2c
# HANDLE hHandle = CreateFileA("\\\\.\\APPDRV",
# GENERIC_READ|GENERIC_WRITE, 0,
# NULL, OPEN_EXISTING, 0x80, NULL);
#
# char buffer[BUFF_SIZE];
# memset(buffer, 0, BUFF_SIZE);
# buffer[0] = 0x04;
# buffer[1] = 0x00;
# buffer[2] = 0x06;
# buffer[3] = 0x00;
# buffer[4] = 7;
# buffer[5] = 7;
#
# DWORD bytesReturned;
# BOOL result = DeviceIoControl(hHandle, 0x23209C,
# buffer, BUFF_SIZE, buffer, BUFF_SIZE, &bytesReturned, NULL);
#-------------------------------
#
#for testing, this should translate into the following:
$hDevice = createFile("\\\\.\\APPDRV", "rw", '' );
if (! $hDevice){ die("Could not open device! \n"); }
print "Device open\n"; #this seems to be working
$buffer = chr(04) . chr(0) . chr(06) . chr(0) .
7 . 7 . chr(0) . chr(0) .
chr(0) . chr(0) . chr(0) . chr(0) .
chr(0) . chr(0) . chr(0) . chr(0) .
chr(0) . chr(0) . chr(0) . chr(0) .
chr(0) . chr(0) . chr(0) . chr(0) .
chr(0) . chr(0) . chr(0) . chr(0) .
chr(0) . chr(0) . chr(0) . chr(0) .
chr(0) . chr(0) . chr(0) . chr(0) .
chr(0) . chr(0) . chr(0) . chr(0);
$res = DeviceIoControl( $hDevice, 0x23209C, $buffer, 44, $opOutBuf, 44,
$olRetBytes, $pOverlapped );
if (! $res){ print "IO control failed\n"; } # this fails
am i missing something here?
thanks for any hints...
------------------------------
Date: Mon, 21 Apr 2008 09:56:29 -0700 (PDT)
From: smallpond <smallpond@juno.com>
Subject: Re: win32api::file translation of c-code to perl: help pls
Message-Id: <0913f430-53d7-48ad-a6df-7d4d5bd8259d@u36g2000prf.googlegroups.com>
On Apr 21, 9:20 am, Susanne West <sw...@gmx.de> wrote:
> i have the following c-code that sould send out a
> command through deviceIO using win32api::file, and
> i'm struggling with the proper handling of the code.
> the result of my DeviceIoControl() command is always
> NULL...
>
> #! perl
#!/usr/bin/perl
use warnings;
use strict;
> am i missing something here?
>
Yes. You are missing the error messages for your
undefined functions.
--S
------------------------------
Date: Sun, 20 Apr 2008 19:45:13 +0200
From: "M.O.B. i L." <mikaelb@df.lth.se>
Subject: WWW::Mechanize doesn't always follow_link(text
Message-Id: <fufvf9$d1a$1@news.lth.se>
I'm using WWW::Mechanize 1.34 and have a problem.
This doesn't work:
$agent->follow_link(text => 'Edit Librarians', n => 1);
It doesn't work in the sense that the link isn't followed and the $agent
is still on the same page. Is there a bug in my code or is there a known
bug in WWW::Mechanize. I've tried to change to space but that
didn't work.
This works:
$agent->follow_link(url_regex => qr/librarians/, n => 1);
The corresponding XHTML code is:
<a href="mkbAdmin?func=librarians&lang=en">Edit Librarians</a>
I want it to work since I use HTTP::Recorder to generate the code
automatically as I surf using a proxy and it generates code of the type
that doesn't work.
This works:
$agent->follow_link(text => 'Logout', n => 1);
By the way HTTP::Recorder actually generates:
$agent->follow_link(text => 'Edit Librarians', n => '1');
------------------------------
Date: 21 Apr 2008 17:34:49 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: WWW::Mechanize doesn't always follow_link(text
Message-Id: <Xns9A877FFA9257castleamber@130.133.1.4>
"M.O.B. i L." <mikaelb@df.lth.se> wrote:
> I'm using WWW::Mechanize 1.34 and have a problem.
> This doesn't work:
> $agent->follow_link(text => 'Edit Librarians', n => 1);
> It doesn't work in the sense that the link isn't followed and the $agent
> is still on the same page. Is there a bug in my code or is there a known
> bug in WWW::Mechanize. I've tried to change to space but that
> didn't work.
>
> This works:
> $agent->follow_link(url_regex => qr/librarians/, n => 1);
>
> The corresponding XHTML code is:
> <a href="mkbAdmin?func=librarians&lang=en">Edit Librarians</a>
>
> I want it to work since I use HTTP::Recorder to generate the code
> automatically as I surf using a proxy and it generates code of the type
> that doesn't work.
>
> This works:
> $agent->follow_link(text => 'Logout', n => 1);
>
> By the way HTTP::Recorder actually generates:
> $agent->follow_link(text => 'Edit Librarians', n => '1');
HTML::TreeBuilder, or a module it's using, returns as a single
character, it might be that you have to
use the code instead.
Comment on http://johnbokma.com/perl/search-term-suggestion-tool.html
says: ( , stored as char 225)
So you might want to try: "Edit\xe1Librarians".
Wild guess.
--
John
Arachnids near Coyolillo
http://johnbokma.com/perl/
------------------------------
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 1470
***************************************
