[11983] in Perl-Users-Digest
Perl-Users Digest, Issue: 5583 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu May 6 14:07:19 1999
Date: Thu, 6 May 99 11:01:31 -0700
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 6 May 1999 Volume: 8 Number: 5583
Today's topics:
Slice [N..end] of unnamed array? (Sam Nelson)
Re: Slice [N..end] of unnamed array? <uri@sysarch.com>
Re: Slice [N..end] of unnamed array? (Sean McAfee)
split, pop, and cut <prsinfo@profrecovery.com>
Re: split, pop, and cut (Brian Peisley)
Re: syswrite() lies (Larry Rosler)
Re: syswrite() lies <uri@sysarch.com>
testing expressions in the IF statement <bvargas@hntb.com>
Re: testing expressions in the IF statement <Allan@due.net>
Re: The Perl Index Project (Thomas L. Shinnick)
Re: unos problemitas <cassell@mail.cor.epa.gov>
Re: using $, (was Re: having problems) <uri@sysarch.com>
Re: What is the opposite of bind() ? (Kenny McCormack)
Re: Whats wrong? <cassell@mail.cor.epa.gov>
Re: writing binary file (Ethan H. Poole)
Special: Digest Administrivia (Last modified: 12 Dec 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 6 May 1999 15:56:23 GMT
From: sam@cs.stir.ac.uk (Sam Nelson)
Subject: Slice [N..end] of unnamed array?
Message-Id: <7gse37$t1a$1@wallace.stir.ac.uk>
If I just generated an array whose length I don't know, how do I take a slice
containing item N onwards? Obviously I can put the slice into an intermediate
array (@Temp, say) and slice `@Temp[$N..-1]' or something like that but while
the syntax makes sense, a slice like `(split(':'))[$N..-1]' always seems
to get me nothing at all. Is there some obvious reason I'm missing why this
can't work, or should I be doing this some other way, or must I simply use the
named temporary?
--
SAm. (Insert bandwidth-wasting disclaimer here)
`Let's hurry up and take this before Billy's slippers wear off...'
------------------------------
Date: 06 May 1999 13:00:53 -0400
From: Uri Guttman <uri@sysarch.com>
Subject: Re: Slice [N..end] of unnamed array?
Message-Id: <x7so9aw2t6.fsf@home.sysarch.com>
>>>>> "SN" == Sam Nelson <sam@cs.stir.ac.uk> writes:
SN> If I just generated an array whose length I don't know, how do I
SN> take a slice containing item N onwards? Obviously I can put the
SN> slice into an intermediate array (@Temp, say) and slice
SN> `@Temp[$N..-1]' or something like that but while the syntax makes
SN> sense, a slice like `(split(':'))[$N..-1]' always seems to get me
SN> nothing at all. Is there some obvious reason I'm missing why this
SN> can't work, or should I be doing this some other way, or must I
SN> simply use the named temporary?
@Temp[$N..-1] makes no sense unless $N is negative. .. is an operator and
not a slice generator. same for (split(':'))[$N..-1]. remember that
negative indexes are individual indexes and .. has no knowledge that it
is being used in a slice.
without knowing the length you can't find the last index directly. but
what are you doing with the data? how are you generating it? maybe there
is a better solution but you haven't shown any code regarding your
problem.
a stab in the dark might be:
( @junk[0 .. $N - 1], @rest) = split(':') ;
so i think you have to go to the real array.
uri
--
Uri Guttman ----------------- SYStems ARCHitecture and Software Engineering
uri@sysarch.com --------------------------- Perl, Internet, UNIX Consulting
Have Perl, Will Travel ----------------------------- http://www.sysarch.com
The Best Search Engine on the Net ------------- http://www.northernlight.com
------------------------------
Date: Thu, 06 May 1999 17:02:45 GMT
From: mcafee@waits.facilities.med.umich.edu (Sean McAfee)
Subject: Re: Slice [N..end] of unnamed array?
Message-Id: <VWjY2.126$tb.2585@news.itd.umich.edu>
In article <7gse37$t1a$1@wallace.stir.ac.uk>,
Sam Nelson <sam@cs.stir.ac.uk> wrote:
>If I just generated an array whose length I don't know, how do I take a slice
>containing item N onwards? Obviously I can put the slice into an intermediate
>array (@Temp, say) and slice `@Temp[$N..-1]' or something like that but while
>the syntax makes sense, a slice like `(split(':'))[$N..-1]' always seems
>to get me nothing at all.
Of course. $N..-1 means "a list of the integers from $N to -1, inclusive".
If $N >= 0, this list is empty, giving you a zero-length list slice.
>Is there some obvious reason I'm missing why this
>can't work, or should I be doing this some other way, or must I simply use the
>named temporary?
I've never found a nice way to do this without using a temporary array.
One of the messier ways is to use a pair of reverses:
@list = reverse((reverse split ':')[0..$N-1]);
Since you're using split, though, there's yet another way to do it:
@list = split ':', (split ':', $_, $N)[-1];
(Be careful, as this will return something even if $_ contains fewer than $N
fields.)
--
Sean McAfee mcafee@umich.edu
print eval eval eval eval eval eval eval eval eval eval eval eval eval eval
q!q@q#q$q%q^q&q*q-q=q+q|q~q:q? Just Another Perl Hacker ?:~|+=-*&^%$#@!
------------------------------
Date: Thu, 06 May 1999 12:26:02 -0400
From: Peter Eisengrein <prsinfo@profrecovery.com>
Subject: split, pop, and cut
Message-Id: <3731C299.23BCFD9C@profrecovery.com>
I am looking for a way to split not by delimiter (which is like the UNIX
'cut -d'), but instead by character count, like the UNIX 'cut -c'
command. I know I can cut off the end with pop, but that isn't exactly
right either.
I can't find this anywhere in the man pages or on the Web. Any help you
can offer is greatly appreciated. Thanks.
------------------------------
Date: Thu, 06 May 1999 17:36:33 GMT
From: brian@helka.mutagenic.org (Brian Peisley)
Subject: Re: split, pop, and cut
Message-Id: <slrn7j3ksg.mk.brian@helka.mutagenic.org>
Peter Eisengrein <prsinfo@profrecovery.com> writes:
>I can't find this anywhere in the man pages or on the Web. Any help you
>can offer is greatly appreciated. Thanks.
Are you sure? I found a perfectly good example in perlfaq5:
"How can I manipulate fixed-record-length files?"
--
Brian Peisley
bdp@mutagenic.org
------------------------------
Date: Thu, 6 May 1999 09:07:45 -0700
From: lr@hpl.hp.com (Larry Rosler)
Subject: Re: syswrite() lies
Message-Id: <MPG.119b5e23d57371009899db@nntp.hpl.hp.com>
In article <slrn7j3bll.sgs.sholden@pgrad.cs.usyd.edu.au> on 6 May 1999
15:01:13 GMT, Sam Holden <sholden@pgrad.cs.usyd.edu.au> says...
> On Thu, 6 May 1999 07:28:29 -0700, Larry Rosler <lr@hpl.hp.com> wrote:
...
> >Nowhere in the paragraph above does the word 'platform' appear (nor the
> >words 'broken' or 'brain-dead'). Programs that don't use binmode() are
> >not portable. Period.
>
> My references to brokeness were just using the same language as the post
> I was replying to. Although I used 'feature' since I can't see why using
> two characters for one logical character could have been thought of as
> a good thing to do given the technical reasons for doing so no longer
> applied.
Historical continuity of design and data are just as important in the
CP/M -> DOS -> Windows evolution as in other technological streams. The
divergence from Unix methodology was a design decision. Unlike the Y2K
design decisions, this has cost and is costing and will continue to cost
the world millions of dollars in programmer sweat, not billions.
The original 'brilliant' decision in Unix was to reinterpret the ASCII
LF (line-feed) character "\012" to mean "start a new line", which
required (in the TTY devices of those days) a combination of ASCII CR
(carriage-return) "\015" and LF. The translation from one character to
two on output was left to the device driver. The B and C language
reinterpretation of LF as "\n" was one character in code and in external
storage; it was expanded to two characters in the TTY data stream only.
The CP/M decision was to retain the literal meaning of LF (which
simplifies the TTY driver a smidgen) and to translate the "\n" to CR/LF
not only in the TTY driver but also in the external-storage drivers.
Not only did this require dropping the CR on input from external files;
far more serious was that it destroyed portability of such files between
different operating systems. This may have been considered a Good
Thing, but I doubt that anyone gave it a moment's thought. Nor were
they concerned about creating a logical distinction between 'raw'
(binary) files and 'cooked' (text) files.
So we are stuck forever with text files that have more bytes when stored
externally than internally, with FTP 'ASCII' and 'binary' modes, with
here-docs that don't terminate, and ...
The Apple folks made a similar idiosyncratic choice in using CR rather
than LF to represent "\n", but I don't know enough about the history to
comment on it. The pain of that choice seems less, though, partly
because it is a one-to-one mapping, and partly because there are so many
fewer Apple systems. :-)
...
> Windows people don't seem to read the documentation as much (I have no
> evidence, it's my opinion - I'm probably wrong) as unix people.
If true, that changes fast when they encounter Perl! :-)
> Unix people read about binmode in that documentation and then should use
> it (many write non-portable code and don't use it, but that is OK in a lot
> of situations (code that does very unixy things for example)).
>
> Windows people don't read about binmode and thus don't use it.
No. They don't see it in the examples or in the code they are copying,
and thus don't use it.
> If it was unix that needed binmode all would be well. If it was unix people
> that didn't read the documentation all would be well. But we have the
> wrong mix, and thus we have this mistake happening over and over again.
>
> >The C Standard is by design platform-independent. The Unix origins of
> >the C Library are quite apparent, but the functions are documented for
> >program portability. So should Perl functions be! (If there were to be
> >a Perl Standard and I were to be on the Technical Committee, they would
> >be. But don't anyone hold their breath until that happens. :-)
>
> The perl documentation tends to treat the whole world as unix, and anything
> else as wrong. Thus in the open documentation it mentions binmode but says
> that you don't need it on 'modern operating systems'. In my opinion that
> isn't very helpful, since most people would consider Windows 98 to be more
> modern than unix (I don't care about the histories of both, it's general
> opinion I'm talking about).
>
> I doubt it will change, I'm not going to submit a documentation bug about it,
> TomC would strike me down for possibly hinting that unix users should do
> something to make it easier for windows users ;)
It is a slippery slope from 'in-humor' (such as 'modern operating
systems' excluding Windows) to snideness to maliciousness to
destructiveness.
At the time when C was dominated by Unix, Bill Plauger -- who developed
and sold dozens of implementations of the C library for dozens of other
operating systems -- insisted that the Standard C Library be designed
and documented in a platform-independent, equitable manner. That alone
is the reason why Perl and perl port so easily to many environments.
The portable file-system and I/O models in the Standard C Library make
it possible.
It is not unreasonable to demand that Perl documentation take the same,
even-handed approach. Unfortunately, TomC couldn't care less. And he
is wrong. And Perl will suffer until this approach is changed.
I am not afraid of being 'struck down' for saying this. (Hunting
frantically for lightning rod :-)
--
(Just Another Larry) Rosler
Hewlett-Packard Company
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: 06 May 1999 12:48:36 -0400
From: Uri Guttman <uri@sysarch.com>
Subject: Re: syswrite() lies
Message-Id: <x7vhe6w3dn.fsf@home.sysarch.com>
>>>>> "LR" == Larry Rosler <lr@hpl.hp.com> writes:
LR> Historical continuity of design and data are just as important in the
LR> CP/M -> DOS -> Windows evolution as in other technological streams. The
LR> divergence from Unix methodology was a design decision. Unlike the Y2K
LR> design decisions, this has cost and is costing and will continue to cost
LR> the world millions of dollars in programmer sweat, not billions.
LR> The CP/M decision was to retain the literal meaning of LF (which
LR> simplifies the TTY driver a smidgen) and to translate the "\n" to CR/LF
LR> not only in the TTY driver but also in the external-storage drivers.
LR> Not only did this require dropping the CR on input from external files;
LR> far more serious was that it destroyed portability of such files between
LR> different operating systems. This may have been considered a Good
LR> Thing, but I doubt that anyone gave it a moment's thought. Nor were
LR> they concerned about creating a logical distinction between 'raw'
LR> (binary) files and 'cooked' (text) files.
you are missing a little history here. cp/m derived from dec's RT-11 and
all of dec's OS's used cr/lf in the files. the different behavior of the
2 chars is still evident in glass tty's where a printed bare cr will do
just that, move the cursor to the beginning of the line. unix's genius
here was in moving the knowledge of translating \n to cr/lf into the
driver and using only lf in the files and in c which makes for simpler
coding.
and there are no differences in files on winblows, only in how you
interpret them. you can read any file with/without binmode. only one way
will make sense for any given file. since the default is text mode with
cr/lf translation in the io library, and most files processed by perl
are text, this leads to the fine complacency of winblows perl
hackers. then they get bit by not understanding their platforms and
perl.
as for the docs stating to use binmode in open, open doesn't care about
the file format. the i/o and platform care so the hacker should know
about those things. and since we have empirical proof that winblows perl
hackers don't rtfm (except you larry), we have an impasses. but a
mention there might be in order so we can lower the noise level of this
issue.
uri
--
Uri Guttman ----------------- SYStems ARCHitecture and Software Engineering
uri@sysarch.com --------------------------- Perl, Internet, UNIX Consulting
Have Perl, Will Travel ----------------------------- http://www.sysarch.com
The Best Search Engine on the Net ------------- http://www.northernlight.com
------------------------------
Date: Thu, 6 May 1999 11:10:04 -0500
From: "UUNET" <bvargas@hntb.com>
Subject: testing expressions in the IF statement
Message-Id: <7gsevj$o1i$1@ffx2nh3.news.uu.net>
Is it possible to test 2 expressions in an IF statement?
For example, can I use something similar to the following statement?
if ($x < 5 and $x > 2)
Thanks.
------------------------------
Date: Thu, 6 May 1999 12:35:33 -0400
From: "Allan M. Due" <Allan@due.net>
Subject: Re: testing expressions in the IF statement
Message-Id: <7gsfua$ejs$1@nntp1.atl.mindspring.net>
UUNET wrote in message <7gsevj$o1i$1@ffx2nh3.news.uu.net>...
:Is it possible to test 2 expressions in an IF statement?
:
:For example, can I use something similar to the following statement?
:
:if ($x < 5 and $x > 2)
What happened when you tried it? You had typed that much already, why not
go ahead see what happens? I bet you would be pleasently surprised <g>.
Absolutely unbelievable. My sig quote came up completely at random. It
actually kind of freaked me out.
AmD
--
$email{'Allan M. Due'} = ' All@n.Due.net ';
--random quote --
Empiricism is dead, it seems...
- Sean McAfee (responding in cplm to a classic what would happen if...
question)
------------------------------
Date: Thu, 06 May 1999 06:43:28 GMT
From: tshinnic@io.com (Thomas L. Shinnick)
Subject: Re: The Perl Index Project
Message-Id: <37313989.42049974@news.io.com>
On Wed, 05 May 1999 01:39:11 -0500, silver <silver@silverchat.com> wrote:
>http://www.silverchat.com/~silver/perlindex
>The Perl Index Project
While lusting after anything that will help me quickly find that
one item that resolves a question (that's a YES to "good idea?"),
I am unsure how broad and deep you are aiming for.
For instance, would it be good enough to have an traditional
index, albeit across multiple books, that extends and consolidates
entries and subjects already found in the current indexes?
Or would it better be an extension of question/answer format
like the FAQs, but using the books as reference materials?
Or an amalgam of both, with a good search engine.
Perhaps some examples of mis(sed)indexing in Prog.Perl 2E will
help me explain my uncertainty. Wandering through my marked
up index I find:
1) Already in index is
arrays,
last element of, 49
which should instead be
index of last element, 49
and should be accompanied by
accessing last element, 199
and
lists,
accessing last element, 199
Of course, what is really needed are references to accessing
elements relative to the current end of an array/list (e.g.
ary[-3]) which could be done as a discussion with references
to other books, which have lots more examples of such use.
2) Already in index is
files
test operators, 19
which references the 'lite' discussion but not the 'heavy'?
test operators, 19, 85-87
Similarly
opening
files, 229, 441
references sysopen and FileCache, but not open?
files, 191, 229, 441
And
time,
script running, 87
should instead be
script start time ($^T), 87, 137, 403
Thus the online index could be seen as the 'fixed' index
for these books. The experience of those _using_ books is
worth a great deal (and we would like to gain from that)
but no publisher can afford to print the 2.1th edition
just to fix the index.
3) After reading the referenced pages for a indexed topic,
such as
hashes, 7, 36, 50
you can find the answer to a question like how to initialize
hashes with data (using lists), but an expanded index would
certainly have the missing entry for quick reference,
initializing with lists, 8, 50
Thus the online index (with accompanying search engine) could
become the "index as large as the text" that no publisher can
afford to produce.
4) Already present in the index are
match (m//) operator,
modifiers for, 69
and
modifiers, statement, 96
but a search engine or index expansion would help us find
modifiers, match, 69
The person in need of a quick fix may not wish to (or be able
to) psych out what the mindset of the indexer was, in order
to find the correct search path in a printed index.
So I can see many directions to go here and have wanted all
of these possibilities at one time or another. But you will
have to establish limits just to make the project possible.
Perhaps you could initially limit it to the expanded, corrected,
combined index that I with my six Perl book bookshelf could use
today. But then also have links to free-format discussions and
web pages, perhaps as an on/off option for the individual user?
As for your question about
>Phase 2: Permission
I would think it laughable for any publisher to refuse to permit
what is in essence a cataloging project, where the end results
are references to the publisher's product. As long as the
project doesn't generate pirated _content_, where is the harm?
--
Whatsoever thy hand findeth to do, do it with thy might;
for there is no work, nor device, nor knowledge, nor wisdom,
in the grave, whither thou goest.
Ecclesiates 9:10 (King Solomon knew managers?)
------------------------------
Date: Thu, 06 May 1999 09:23:15 -0700
From: David Cassell <cassell@mail.cor.epa.gov>
Subject: Re: unos problemitas
Message-Id: <3731C1F3.B8D3499@mail.cor.epa.gov>
Cameron Dorey wrote:
>
> Tom Christiansen wrote:
> >
> > [courtesy cc of this posting sent to cited author via email]
> >
> > In comp.lang.perl.misc, bart.lateur@skynet.be (Bart Lateur) writes:
> > : open (FILE, ">$fn") || print "Problemo: $!";
> >
> > Cool -- a new language! "problemo" is not a word in any language I have
> > ever heard of. What language was that?
> >
> > [etymology lesson snipped]
>
> Well, I don't find "modulo" in Webster's (or Cassell's), either, but you
^^^^^^^
------------->>>>>>>>>>>>>>>
> seem to find it used around here quite a bit. ;)
>
> BTW, "problemo" predates the Simpsons or other TV shows I've seen listed
> in this thread by quite a few years. I remember hearing/using it 35-40
> years ago, when I was a kid. Pig-Spanish, I think.
[as per another ongoing thread:]
Cameron, I want you to cease and desist citing my personal dictionary
until your lawyers have paid appropriate moolah to my lawyers. And
modulo is in *my* dictionary. I just have a proprietary interface
which includes a patented lexical sort different from Webster's.
:-)
HAND,
David
--
David Cassell, OAO cassell@mail.cor.epa.gov
Senior Computing Specialist phone: (541) 754-4468
mathematical statistician fax: (541) 754-4716
------------------------------
Date: 06 May 1999 12:30:41 -0400
From: Uri Guttman <uri@sysarch.com>
Subject: Re: using $, (was Re: having problems)
Message-Id: <x7yaj2w47i.fsf@home.sysarch.com>
>>>>> "BL" == Bart Lateur <bart.lateur@skynet.be> writes:
BL> Uri Guttman wrote:
>> i imagine in some awkish -p or -n loop $, might be useful.
BL> Huh?
>> has anyone ever seen or used it in production code?
BL> What do you mean? Do I use $, in production code? Yes, all the time. I
BL> use it to create "tab delimited text files" in a simple, reliable
BL> manner.
BL> ($\,$,) = ("\n","\t");
BL> print qw(a b c);
BL> print qw(d e f);
but as i said, join has been shown to be faster. i have created many tab
seperated files (and today i will be creating a new script to do another
one) and i will use join.
BL> The disadvantage is that those special variables are global, and not
BL> associated with a specific filehandle, e.g. the one currently
BL> select()-ed.
the code in IO::Handle implies a local but the camel says it is
global. i have run into that problem with $/ before. you can localize it
in a block while using it which works fine. and join is local by its nature.
so what advantage does it have over join unless you want all output to
have $, used? and that is what i meant about awkish code, where the OFS
is more important to use since it has no other easy way to do it, unlike
perl.
minor side note: the mnemonic for $, in the camel says its what you output
when you have , in your print. but the examples we have been playing
with in this thread mostly use a single array with no , in the args to
print. not sure what my point is but the mnemonic is still ok.
uri
--
Uri Guttman ----------------- SYStems ARCHitecture and Software Engineering
uri@sysarch.com --------------------------- Perl, Internet, UNIX Consulting
Have Perl, Will Travel ----------------------------- http://www.sysarch.com
The Best Search Engine on the Net ------------- http://www.northernlight.com
------------------------------
Date: 6 May 1999 12:10:56 -0500
From: gazelle@yin.interaccess.com (Kenny McCormack)
Subject: Re: What is the opposite of bind() ?
Message-Id: <7gsif0$as0$1@yin.interaccess.com>
In article <ssirg7.hi6.ln@magna.metronet.com>,
Tad McClellan <tadmc@metronet.com> wrote:
>
>: Thank you for totally derailing this thread.
>
>
> The point being that you are the only person who knows
> what book you are using, hence what code you are using.
If I thought it was particularly relevant, I'd have included it.
The question is almost more of a Unix question than a Perl question,
so the actual code being used didn't seem important.
The question is: Is there an unbind() system call in Unix? The answer
appears to be "No - but you can work around it by using SO_REUSEADDR."
------------------------------
Date: Thu, 06 May 1999 09:56:51 -0700
From: David Cassell <cassell@mail.cor.epa.gov>
Subject: Re: Whats wrong?
Message-Id: <3731C9D3.B798B7D3@mail.cor.epa.gov>
Todd Smith wrote:
>
> Sam Holden wrote:
>
> > On 02 May 1999 23:23:22 -0400, esalmon@packet.net <esalmon@packet.net> wrote:
> > >How do I make the following systen command work? And possibly return the
> > >results?
> > >
> > >$userid = 'whoami';
> >
> > You read the documentation in perlop and use the the quotes it says to use.
>
> oh just answer the guy - it would only have taken two words - "use backticks."
Wait a minute. Sam was using an important principle often seen in
this ng: the give-a-man-a-fish principle.
It is better to teach someone how to find their answer in the docs
[especially an answer this simple] thna to give it to him and, by
denying him the meta-knowledge, force him to come back here groveling
for every new scrap of assistance.
Where's your sense of decency, man? :-) Give this poor soul
esalmon@packet.net the kind of help that will help him in future
too.
Although Sam *could* have told him how to use perldoc... :-)
the troublemaker
--
David Cassell, OAO cassell@mail.cor.epa.gov
Senior Computing Specialist phone: (541) 754-4468
mathematical statistician fax: (541) 754-4716
------------------------------
Date: Mon, 03 May 1999 01:49:10 -0400
From: ehpoole@ingress.com (Ethan H. Poole)
Subject: Re: writing binary file
Message-Id: <iLUhqiSl#GA.206@rejz.ij.net>
In article <372CE1FE.5B553871@home.com>, rick.delaney@home.com says...
>
>Frank Hale wrote:
>>
>> How do you write a binary file in Perl?
>
>#!/usr/local/bin/perl -w
>
>format STDOUT =
>a binary file
>.
>
>write
Personally, I think the following would be a bit more direct:
binmode (STDOUT);
Now anything sent to the STDOUT filehandle is handled as binary.
If reading in a binary file, don't forget to binmode() the input file as
well.
--
Ethan H. Poole | Website Design and Hosting,
| CGI Programming (Perl & C)..
========Personal=========== | ============================
* ehpoole @ ingress . com * | --Interact2Day, Inc.--
| http://www.interact2day.com/
=======FREE WEBSITE DESIGN PROMOTION UNTIL 5/31/99!=======
------------------------------
Date: 12 Dec 98 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Special: Digest Administrivia (Last modified: 12 Dec 98)
Message-Id: <null>
Administrivia:
Well, after 6 months, here's the answer to the quiz: what do we do about
comp.lang.perl.moderated. Answer: nothing.
]From: Russ Allbery <rra@stanford.edu>
]Date: 21 Sep 1998 19:53:43 -0700
]Subject: comp.lang.perl.moderated available via e-mail
]
]It is possible to subscribe to comp.lang.perl.moderated as a mailing list.
]To do so, send mail to majordomo@eyrie.org with "subscribe clpm" in the
]body. Majordomo will then send you instructions on how to confirm your
]subscription. This is provided as a general service for those people who
]cannot receive the newsgroup for whatever reason or who just prefer to
]receive messages via e-mail.
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.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
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.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
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 V8 Issue 5583
**************************************
