[29737] in Perl-Users-Digest
Perl-Users Digest, Issue: 981 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Oct 26 18:09:36 2007
Date: Fri, 26 Oct 2007 15:09:03 -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 Fri, 26 Oct 2007 Volume: 11 Number: 981
Today's topics:
Re: configurable variables in own file? xhoster@gmail.com
Re: EU:MM and custom installation path <ben@morrow.me.uk>
Re: IPC::Open3 and the error filehandle <ced@blv-sam-01.ca.boeing.com>
Re: IPC::Open3 and the error filehandle <ben@morrow.me.uk>
Re: IPC::Open3 and the error filehandle xhoster@gmail.com
Re: PID of exec xhoster@gmail.com
Re: PID of exec hendedav@gmail.com
Re: PID of exec hendedav@gmail.com
Re: PID of exec <ben@morrow.me.uk>
Re: PID of exec xhoster@gmail.com
Re: TeX pestilence <dak@gnu.org>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 26 Oct 2007 18:27:03 GMT
From: xhoster@gmail.com
Subject: Re: configurable variables in own file?
Message-Id: <20071026142705.282$ls@newsreader.com>
Ted Zlatanov <tzz@lifelogs.com> wrote:
> On Wed, 24 Oct 2007 03:29:32 -0000 ivowel@gmail.com wrote:
>
> i> optimally, I would like syntax like
>
> i> package mypackage:
> i> require Exporter;
> i> our @ISA= qw(Exporter);
> i> our @EXPORT = qw( v1 v2 v3 v4 );
> i> include mypackageconfig;
> i> our ($v2, $v3, $v4) = ("a", "b", "c");
> i> ($v1=~ /whatisit/);
> i> ## a lot more stuff, a lot more variables, etc.
>
> i> and the file mypackageconfig would just contain
>
> i> our $v1= "user-please-set";
>
> With AppConfig:
>
> V1 = user-please-set
> # V2 is a hash
> V2 key1 = value1
> V2 key2 = value2
I already know what a hash looks like in Perl. Why spend the
effort to learn what a hash looks like in some other language, too,
without some compelling reason?
> # V3 is a list
> V3 = one
> V3 = two
> V3 = three
>
> YAML and XML can do this as well. YAML will handle multi-level hashes
> and lists, while XML may be better depending on your environment. Any
> one of them is easily parseable by other languages as well--don't limit
> your data to just Perl interpretation.
That is a good idea if you have some inkling that your configuration file
will need to be read by some other language. But how frequent is that?
If the configuration is for my Perl program, why would anything other
than Perl and the person doing the configuration need to be able to read
it?
> The method you described has security and maintenance risks,
The security risk seems to be largely a red herring to me. If the
potentially malicious user is going to be running the perl program as
himself, then he can already make the program do anything he wants just by
changing the main code itself, with no need to trick it by changing the
configuration file. If the potentially malicious user is going to be
running the code as me, well, 99% of the time I'm no more going to make the
configuration file writable by him than I am going to make the main code
itself writable by him, regardless of what mechanism is used to hold the
configuration.
And I'm not sure what you mean be maintenance risk. Any program that
actually needs a configuration in the first place is not going to run
correctly if that configuration is done wrong. This is true regardless of
what mechanism is used for holding the configuration.
There are good reasons for using text-only configuration, but those reasons
are not universally applicable, and in my experience in Perl they are not
even very common.
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, 26 Oct 2007 20:17:25 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: EU:MM and custom installation path
Message-Id: <53r9v4-sg5.ln1@osiris.mauzo.dyndns.org>
Quoth Teo <matteo.corti@gmail.com>:
>
> am using ExtUtils::MakeMaker for the distribution of a Perl script.
No, you're using Module::Install. The distinction is important.
> The Perl script (not a module a standalone script) is a plugin for a
> software tool (Nagios) and has to be installed in a particular
> location (e.g., /usr/lib/nagios/plugins/contrib) instead of the
> canonical /usr/local/bin on a Unix platform.
>
> This is how one of my many test Makefile.PL looks like:
>
> # Load the Module::Install bundled in ./inc/
> use inc::Module::Install;
>
> ##############################################################################
> # Define metadata (we read it from the binary)
> name 'check_dir';
> all_from 'check_dir';
>
> ##############################################################################
> # Specific dependencies
> requires 'Carp' => 0;
> requires 'English' => 0;
> requires 'File::stat' => 0;
> requires 'Getopt::Long' => 0;
> requires 'Nagios::Plugin' => 0;
> requires 'Nagios::Plugin::Threshold' => 0;
> requires 'Pod::Usage' => 0;
> requires 'version' => 0;
>
> install_script 'check_dir';
>
> WriteMakefile(
> INSTALLDIRS => 'site',
> INSTALLSITEBIN => '/usr/lib/nagios/plugins/contrib',
> INSTALLSCRIPT => '/usr/lib/nagios/plugins/contrib',
> );
>
> I tried many combinations of INSTALLDIR values and INSTALL* variables
> but I was never able to install the script in a place different from /
> usr/local/bin.
>
> Any hint?
The following works for me (in that it installs the script in the
correct place).
use inc::Module::Install;
name 'check_dir';
all_from 'check_dir';
install_script 'check_dir';
WriteMakefile(
INSTALLDIRS => 'site',
INSTALLSITESCRIPT => '/home/mauzo/foo',
);
auto_install;
Note that both 'auto_install' is required, or you don't get any
dependancies.
Ben
------------------------------
Date: Fri, 26 Oct 2007 12:35:20 -0700
From: "comp.llang.perl.moderated" <ced@blv-sam-01.ca.boeing.com>
Subject: Re: IPC::Open3 and the error filehandle
Message-Id: <1193427320.472631.152930@i38g2000prf.googlegroups.com>
On Oct 26, 6:33 am, Peter Makholm <pe...@makholm.net> wrote:
> I'm trying to use IPC::Open3 but have some problem with the error
> filehandle not being used. Try the following script:
>
> #!/usr/bin/perl
>
> use IPC::Open3;
> use Data::Dumper;
>
> my ( $in, $out, $err );
> open3($in,$out,$err, "/usr/bin/sort");
>
> print Dumper [$in, $out, $err];
>
> __END__
>
> I would expect output like:
>
> $VAR1 = [
> \*Symbol::GEN0,
> \*Symbol::GEN1,
> \*Symbol::GEN2,
> ];
>
> but I get output like
>
> $VAR1 = [
> \*Symbol::GEN0,
> \*Symbol::GEN1,
> undef
> ];
>
> Reading the documentation, it clearly states that:
>
> If CHLD_ERR is false, or the same file descriptor as CHLD_OUT, then
> STDOUT and STDERR of the child are on the same filehandle. The
> CHLD_IN will have autoflush turned on.
>
> and $err is undef, which is clearly false. But what would be the
> correct way to call open3?
>
> The following works:
>
> #!/usr/bin/perl
>
> use IPC::Open3;
> use Symbol;
> use Data::Dumper;
>
> my ( $in, $out, $err );
> $err = gensym;
> open3($in,$out,$err, "/usr/bin/sort");
>
> print Dumper [$in, $out, $err];
>
> __END__
>
> but calling gensym by hand seems oldschool. But is there a better way?
There was a thread about this not too long ago.
The open3 doc's aren't really informative IMO
since they don't clarify that you usually want to open a stderr
filehandle prior to the open3 call which just dup's to that opened fh.
(unless you pass "" which causes it to use stdout IIRC)
I usually do something like this:
open my $errfh ... or die...
open3( $in, $out, $errfh ) ...
--
Charles DeRykus
------------------------------
Date: Fri, 26 Oct 2007 21:22:20 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: IPC::Open3 and the error filehandle
Message-Id: <ssu9v4-ml5.ln1@osiris.mauzo.dyndns.org>
Quoth Peter Makholm <peter@makholm.net>:
> I'm trying to use IPC::Open3 but have some problem with the error
> filehandle not being used. Try the following script:
>
> #!/usr/bin/perl
>
> use IPC::Open3;
> use Data::Dumper;
>
> my ( $in, $out, $err );
> open3($in,$out,$err, "/usr/bin/sort");
>
<snip>
>
> Reading the documentation, it clearly states that:
>
> If CHLD_ERR is false, or the same file descriptor as CHLD_OUT, then
> STDOUT and STDERR of the child are on the same filehandle. The
> CHLD_IN will have autoflush turned on.
>
> and $err is undef, which is clearly false. But what would be the
> correct way to call open3?
>
> The following works:
>
> #!/usr/bin/perl
>
> use IPC::Open3;
> use Symbol;
> use Data::Dumper;
>
> my ( $in, $out, $err );
> $err = gensym;
> open3($in,$out,$err, "/usr/bin/sort");
>
> print Dumper [$in, $out, $err];
>
> __END__
>
> but calling gensym by hand seems oldschool. But is there a better way?
No.
Ben
------------------------------
Date: 26 Oct 2007 20:47:11 GMT
From: xhoster@gmail.com
Subject: Re: IPC::Open3 and the error filehandle
Message-Id: <20071026164713.962$3q@newsreader.com>
Peter Makholm <peter@makholm.net> wrote:
>
> but calling gensym by hand seems oldschool. But is there a better way?
There is, but the better way would break backwards compatibility, which is
probably why it hasn't been implemented.
The better way, IMHO, would be to make your own wrapper around open3
that only sends STDERR to STDOUT if ERRFH is false but defined. If ERRFH
is undefined, then it would be converted into a file handle with gensym,
just like the other two are. Maybe this behavior could be put into
IPC::Open3, but only turned on with a import flag. That way backwards
compatibility would be preserved.
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: 26 Oct 2007 18:32:02 GMT
From: xhoster@gmail.com
Subject: Re: PID of exec
Message-Id: <20071026143204.240$5s@newsreader.com>
hendedav@gmail.com wrote:
> On Oct 26, 12:29 pm, xhos...@gmail.com wrote:
> > hende...@gmail.com wrote:
> > > Also, this
> > > script seems to be generating zombies. Anyone have ideas on how to
> > > clear that up?
> >
> > You could double-fork.
> >
> > > I was hoping that the "local $SIG{CHLD} = "IGNORE";"
> > > line would do the trick (as it stated in the perldoc's), but I guess
> > > not.
> >
> > What if the "local" expires before the child does? Then IGNORE is no
> > longer in effect and you leave zombies. Did the docs say to set
> > $SIG{CHLD} to IGNORE with local? That seems like a manifestly bizarre
> > thing to do. The effects of $SIG{CHLD} are inherently global and
> > pretending it can be localized is going to get you no where fast.
> >
>
> No I don't recall the doc's saying to use local, but while working
> with another part of the project, I was searching for answers and come
> upon that as a solution. Anyhow, I removed the 'local' portion, but I
> am still receiving zombies. I will post the entire script now for
> review:
First, are the zombies something to worry about? If they go away by
soon enough so they don't clog up the kernel anyway, don't worry about
them.
....
>
> The top if statement only gets executed once (to start a process which
> is monitored by the pollJob section), then the pollJob gets called
> between 2-3 seconds until the job is done. This job is only running
> for 30 seconds (because of the test.sh script), but I accumulate
> several many zombies. Any ideas?
Since the code you show only forks once and is only run once, it couldn't
give rise to many zombies. The zombies must be coming from someplace else.
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, 26 Oct 2007 11:52:09 -0700
From: hendedav@gmail.com
Subject: Re: PID of exec
Message-Id: <1193424729.068749.234230@d55g2000hsg.googlegroups.com>
On Oct 26, 2:32 pm, xhos...@gmail.com wrote:
> hende...@gmail.com wrote:
> > On Oct 26, 12:29 pm, xhos...@gmail.com wrote:
> > > hende...@gmail.com wrote:
> > > > Also, this
> > > > script seems to be generating zombies. Anyone have ideas on how to
> > > > clear that up?
>
> > > You could double-fork.
>
> > > > I was hoping that the "local $SIG{CHLD} = "IGNORE";"
> > > > line would do the trick (as it stated in the perldoc's), but I guess
> > > > not.
>
> > > What if the "local" expires before the child does? Then IGNORE is no
> > > longer in effect and you leave zombies. Did the docs say to set
> > > $SIG{CHLD} to IGNORE with local? That seems like a manifestly bizarre
> > > thing to do. The effects of $SIG{CHLD} are inherently global and
> > > pretending it can be localized is going to get you no where fast.
>
> > No I don't recall the doc's saying to use local, but while working
> > with another part of the project, I was searching for answers and come
> > upon that as a solution. Anyhow, I removed the 'local' portion, but I
> > am still receiving zombies. I will post the entire script now for
> > review:
>
> First, are the zombies something to worry about? If they go away by
> soon enough so they don't clog up the kernel anyway, don't worry about
> them.
>
> ....
>
>
>
> > The top if statement only gets executed once (to start a process which
> > is monitored by the pollJob section), then the pollJob gets called
> > between 2-3 seconds until the job is done. This job is only running
> > for 30 seconds (because of the test.sh script), but I accumulate
> > several many zombies. Any ideas?
>
> Since the code you show only forks once and is only run once, it couldn't
> give rise to many zombies. The zombies must be coming from someplace else.
>
> 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.
The reason that I know that they come from this script is because it
is the only file with its name shown in the ps listing with a
"<defunct>" statement beside each occurance. I end up with about 4 or
5 zombies (that I have paid attention to) for just the 30 seconds of
the test.sh script, but what if the script runs for minutes or hours?
The script shown isn't run just once, it is run every 2-3 seconds
until the test.sh script (which will eventually be replaced with
another script that performs an actual job) is completed.
Dave
------------------------------
Date: Fri, 26 Oct 2007 12:04:35 -0700
From: hendedav@gmail.com
Subject: Re: PID of exec
Message-Id: <1193425475.275019.281840@o80g2000hse.googlegroups.com>
On Oct 26, 2:32 pm, xhos...@gmail.com wrote:
> hende...@gmail.com wrote:
> > On Oct 26, 12:29 pm, xhos...@gmail.com wrote:
> > > hende...@gmail.com wrote:
> > > > Also, this
> > > > script seems to be generating zombies. Anyone have ideas on how to
> > > > clear that up?
>
> > > You could double-fork.
>
> > > > I was hoping that the "local $SIG{CHLD} = "IGNORE";"
> > > > line would do the trick (as it stated in the perldoc's), but I guess
> > > > not.
>
> > > What if the "local" expires before the child does? Then IGNORE is no
> > > longer in effect and you leave zombies. Did the docs say to set
> > > $SIG{CHLD} to IGNORE with local? That seems like a manifestly bizarre
> > > thing to do. The effects of $SIG{CHLD} are inherently global and
> > > pretending it can be localized is going to get you no where fast.
>
> > No I don't recall the doc's saying to use local, but while working
> > with another part of the project, I was searching for answers and come
> > upon that as a solution. Anyhow, I removed the 'local' portion, but I
> > am still receiving zombies. I will post the entire script now for
> > review:
>
> First, are the zombies something to worry about? If they go away by
> soon enough so they don't clog up the kernel anyway, don't worry about
> them.
>
> ....
>
>
>
> > The top if statement only gets executed once (to start a process which
> > is monitored by the pollJob section), then the pollJob gets called
> > between 2-3 seconds until the job is done. This job is only running
> > for 30 seconds (because of the test.sh script), but I accumulate
> > several many zombies. Any ideas?
>
> Since the code you show only forks once and is only run once, it couldn't
> give rise to many zombies. The zombies must be coming from someplace else.
>
> 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.
Actually I put some tracking in the script and I get a zombie for
every execution of that script. This last run executed 17 times and I
had 17 zombies. That can't be good for the kernel if run over a long
period of time.
------------------------------
Date: Fri, 26 Oct 2007 21:26:30 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: PID of exec
Message-Id: <m4v9v4-ml5.ln1@osiris.mauzo.dyndns.org>
Quoth hendedav@gmail.com:
> [snip] Also, this
> script seems to be generating zombies. Anyone have ideas on how to
> clear that up? I was hoping that the "local $SIG{CHLD} = "IGNORE";"
> line would do the trick (as it stated in the perldoc's), but I guess
> not.
Setting SIGCHLD to IGNORE to clean up zombies is non-portable. Possibly
your system doesn't have this behaviour: you will need to wait for your
children yourself.
Ben
------------------------------
Date: 26 Oct 2007 20:37:04 GMT
From: xhoster@gmail.com
Subject: Re: PID of exec
Message-Id: <20071026163706.997$tE@newsreader.com>
hendedav@gmail.com wrote:
> On Oct 26, 2:32 pm, xhos...@gmail.com wrote:
> >
> > > The top if statement only gets executed once (to start a process
> > > which is monitored by the pollJob section), then the pollJob gets
> > > called between 2-3 seconds until the job is done. This job is only
> > > running for 30 seconds (because of the test.sh script), but I
> > > accumulate several many zombies. Any ideas?
> >
> > Since the code you show only forks once and is only run once, it
> > couldn't give rise to many zombies. The zombies must be coming from
> > someplace else.
> >
>
> Actually I put some tracking in the script and I get a zombie for
> every execution of that script.
But isn't the part of your code that does the fork only executed once?
> This last run executed 17 times and I
> had 17 zombies. That can't be good for the kernel if run over a long
> period of time.
What was run 17 times, the runner code or the monitor code? The monitoring
part of the code might be executed several times, but that part doesn't
fork anything, right?
Rather than having the runner and the monitor be the same script just with
different parameters, make them be different scripts. Then see which one
is the zombie---the runner or monitor.
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, 26 Oct 2007 23:13:41 +0200
From: David Kastrup <dak@gnu.org>
Subject: Re: TeX pestilence
Message-Id: <85d4v137ga.fsf@lola.goethe.zz>
Brian Blackmore <blb8@po.cwru.edu> writes:
> In comp.text.tex David Kastrup <dak@gnu.org> wrote:
>
>> But as a programming language, it is a steaming pile of crap. And
>> that's not least because it is a team from a blind and a lame
>> programming system: only TeX's stomach can _affect_ a variable, but
>> only TeX's mouth can _look_ at a variable and make decisions based on
>> its values, decisions for which a resulting action again can only be
>> done by the blind stomach. Both systems kick in at different points
>> of time and different circumstances. And you must not employ the
>> stomach in the middle of typesetting a word, or kernings and ligatures
>> will break.
>
> But if I compare these things to what I actually said in my post (which
> I will now reinsert), namely regarding the problem that I see in CS
> students these days...
>
>> ... I think every f...ing CS grad should have to do a semester of
>> TeX _programming_. I see too many CS grads these days that can't
>> do anything unless there's already a java module to do it, and then
>> they get confused about using the module according to the
>> documentation. Most of these people would garner nothing but
>> benefit from having to spend time _thinking_, and that is one thing
>> that TeX programming requires.
>
>> In many cases, helping people with TeX is just making them realize
>> how to think about the problem in the correct way (for the system
>> at hand). The ability to `change gears' in this fashion is [an
>> aspect of problem solving that they seem to lack].
>
> I find that you're quite making my point for me. That TeX is foul
> or difficult is, to a newbie, often a matter of trying to do the
> wrong things, in my experience.
And the wrong things with TeX is usually trying to program it in the
first place.
> The delineation between stomach and mouth is intrinsic to using the
> system and a requirement as one moves forward with TeX programming.
> I can think of no greater example of having to use the system
> "according to the documentation" and to approach "the problem in the
> correct way".
But the "correct way" sucks or is non-existent. The first task in the
appendix "Dirty Tricks" from the TeXbook tries to define a macro
containing a variable number of asterisks. The solutions are all
complicated, most have quadratic behavior or worse, several are in
danger of exhausting TeX's limits in normal use cases, and Knuth does
not manage to come up with a single expandable solution which could be
used without breaking ligatures or kerns. So one of the most basic
programming tasks to be imagined is a "Dirty Trick" and the author of
the language does not have a solution close to satisfactory.
> This, increasingly, seems to be what younger `programmers' lack, the
> ability to be bothered with any detail, however major, and most
> especially if it's in the documentation.
Your theory would be tantamount to saying that really good bicyclists
should be trained on creaky old holland bikes because those tax the
legs hardest.
It does not work that way. The relation between investment and payoff
is so terrible that you never arrive at the point where you pick up
enough speed to actually get enough fun together to get into a
positive feedback cycle where it is fun pushing yourself.
> Then there's TeX the program itself, and from a number-of-bugs point
> of view, I think they have a lot that could be learned.
Again, I disagree. From a software engineering point of view, TeX is
an idiosyncratic one-person masterpiece. Making it do something
different makes it break all over the place in unexpected ways. Too
many shortcuts and inherent assumptions. It took a genius to create,
and it takes a genius to maintain it. That's not engineering, that's
art. And one can teach only the appreciation of great art, not its
creation. Creative genius is not created in schools or universities.
It is not a dependable resource. It is pointless to teach what can't
bear fruition without a special spark.
> If "programming TeX really sucks", I find it surprising that you're
> the expert, etcetera. It seems reasonable to me to label you as
> such --- no problem there --- but if it blows so heavily, why are
> you still doing it?
Because nobody else does.
> Would not a better argument be based on seeing you program in
> something else?
You'll find me programming in Lua when LuaTeX becomes stable enough.
Until that time, there is no reasonably available system producing
typeset text which can be reasonably programmed in a non-braindead
language. LuaTeX will be a chimera, sure. But at least it has one
sane head you can talk with.
> Yes, I've made an assumption, so I will quickly correct it. I agree
> in part simply because I'd never set out to program an OS kernel in
> TeX, nor some hardware driver, etcetera. I wonder how much of that
> can be blamed on TeX, however, versus blaming the nonexistence of
> those types of interfaces at the time it was designed. COBOL comes
> to mind.
Program something like bigfoot.dtx, or even just binhex.dtx. Those
are not hypothetical applications.
> It seems to me that if we take the arguments you've put forth, there
> are a rather large number of sucky programming languages.
I know no "programming language" (TeX is not a language but rather a
system) where it takes two completely different systems with utterly
different semantics to assign to a variable and to use its value.
> I could complain about having to worry about scope in C: "Wah, I
> can't change a variable in here because it hasn't been passed in by
> reference, but if I try to change it in here then something outside
> breaks". Or in Perl: "Wah, 'print (1+2)+4' does not print seven".
> These sorts of statements are a fundamental misunderstanding of the
> operation of the system in use and that, as far as I am concerned,
> is a statement of lack in the programmer, not the language.
Your comparisons don't make it look like you have programmed serious
tasks both in C and in TeX.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
UKTUG FAQ: <URL:http://www.tex.ac.uk/cgi-bin/texfaq2html>
------------------------------
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 981
**************************************
