[30045] in Perl-Users-Digest
Perl-Users Digest, Issue: 1288 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Feb 19 00:09:39 2008
Date: Mon, 18 Feb 2008 21:09:06 -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 Mon, 18 Feb 2008 Volume: 11 Number: 1288
Today's topics:
Re: Linux, IO::Socket::INET and recv'ing broadcasted UD <ben@morrow.me.uk>
Re: Linux, IO::Socket::INET and recv'ing broadcasted UD <DJStunks@gmail.com>
Re: Number of days since 1/1/2000 xhoster@gmail.com
Re: Number of days since 1/1/2000 <uri@stemsystems.com>
Re: Number of days since 1/1/2000 <uri@stemsystems.com>
Re: Number of days since 1/1/2000 <uri@stemsystems.com>
Re: Number of days since 1/1/2000 <jl_post@hotmail.com>
Re: Number of days since 1/1/2000 <noreply@gunnar.cc>
Re: Number of days since 1/1/2000 <noreply@gunnar.cc>
Re: Number of days since 1/1/2000 <stoupa@practisoft.cz>
Re: Regular Expression to Replace UPPER Case Text with <cwilbur@chromatico.net>
Re: Searching within XLS files - is it good approach ? <telemach@go2.pl>
Re: Searching within XLS files - is it good approach ? xhoster@gmail.com
Re: Searching within XLS files - is it good approach ? <telemach@go2.pl>
Re: Searching within XLS files - is it good approach ? <tadmc@seesig.invalid>
Re: Searching within XLS files - is it good approach ? <arifsaha@yahoo.com>
Re: TRAC - Trac, Project Leads, Python, and Mr. Noah Ka <deets@nospam.web.de>
Re: TRAC - Trac, Project Leads, Python, and Mr. Noah Ka <george.sakkis@gmail.com>
Re: Writers Block <dalestubblefield@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 18 Feb 2008 23:42:07 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Linux, IO::Socket::INET and recv'ing broadcasted UDP
Message-Id: <fnhp85-jm7.ln1@osiris.mauzo.dyndns.org>
Quoth DJ Stunks <DJStunks@gmail.com>:
>
> Still no luck. Have tried with Flags => 1 in the IO::Socket::INET
> constructor.
The Flags => 1 was in the Net::DHCP::Packet constructor.
> The DHCPOFFER is broadcasted regardless (Ethernet
> destination MAC = ff:ff:ff:ff:ff:ff; destination IP = 255.255.255.255;
> destination udp port = 68) but my socket never receives it.
That's... odd. Can you recieve other broadcast datagrams?
Have you tried using a PF_PACKET socket?
Ben
------------------------------
Date: Mon, 18 Feb 2008 16:16:18 -0800 (PST)
From: DJ Stunks <DJStunks@gmail.com>
Subject: Re: Linux, IO::Socket::INET and recv'ing broadcasted UDP
Message-Id: <c3e1bfdd-6072-4dc0-a5d9-b27af0351c1b@i7g2000prf.googlegroups.com>
On Feb 18, 4:42 pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth DJ Stunks <DJStu...@gmail.com>:
>
>
>
> > Still no luck. Have tried with Flags => 1 in the IO::Socket::INET
> > constructor.
>
> The Flags => 1 was in the Net::DHCP::Packet constructor.
Right, my bad. I think I tried that too, but I'll repeat to be sure.
> > The DHCPOFFER is broadcasted regardless (Ethernet
> > destination MAC = ff:ff:ff:ff:ff:ff; destination IP = 255.255.255.255;
> > destination udp port = 68) but my socket never receives it.
>
> That's... odd. Can you recieve other broadcast datagrams?
>
> Have you tried using a PF_PACKET socket?
I thought it was odd too, but I'm continuing to research (so
frustrated! ;-)) and I think what I'm finding is that it's not that
odd...
Here's a post from Solaris' bug tracker: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4191980.
The originator had a similar problem, but with Java. The response
was:
"The Solaris (& Linux for that matter) behavior is
that to be able to receive broadcasts a UDP socket has to be bound to
the
wildcard address (aka anylocal). This has been the defacto standard
behavior
since the days of BSD 4.3. Win32 behaviors differs from that. So the
only way
to be guaranteed to receive the broadcasts on any platform is to bind
to
the wildcard address."
So I tried changing my IO::Socket::INET constructor to use INADDR_ANY,
but no luck. The constructor seems to ignore PeerAddr => '0.0.0.0';
This page (http://wiki.forum.nokia.com/index.php/
How_to_use_udp_broadcast) shows how to set up a Python socket for UDP
broadcast.
So now my question is, how do I set up a Perl socket similarly? Can I
still use IO::Socket::INET to set PF_INET (is that the same as
PF_PACKET?) or do I have to use Socket instead?
As I'm sure everyone can tell, I'm out of my depth, but learning...
slowly.
Thanks Ben,
-jp
------------------------------
Date: 18 Feb 2008 23:55:37 GMT
From: xhoster@gmail.com
Subject: Re: Number of days since 1/1/2000
Message-Id: <20080218185539.890$fS@newsreader.com>
oprah.chopra@gmail.com wrote:
> J. Gleixner wrote:
> > Whenever I see that, instead of sprintf, I say to myself,
> "Inexperienced > coder."
>
> Well I have been coding perl for seven years and and count on one
> hand the number of times I used sprintf. print is simple , why make
> code more unreadable by unncessarily cluttering it with esoteric
> functions?
Except that sprintf wasn't being proposed as an alternative to print.
If you think it was, than your code is even more unreadable to you than
it is to us.
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: Tue, 19 Feb 2008 00:28:45 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Number of days since 1/1/2000
Message-Id: <x73arplrgh.fsf@mail.sysarch.com>
>>>>> "oc" == oprah chopra <oprah.chopra@gmail.com> writes:
oc> since 1/1/2000 . Is there any possible bug in it? I know I can use
oc> Date::Manip but it will slow down my program which is around 100 kb
oc> long.
and how much time have you wasted on your code?
oc> while ($MTH <= ($mon + 1) && $YRW == $year || $MTH <= 12 && $YRW <
oc> $year) {
oc> ## test for leap year
oc> my $yeardiv = ($YRW / 4);
oc> my $yearint = int($yeardiv);
oc> my $yeardiv1 = ($YRW / 100);
year 2000 WAS a leap year and it is divisible by 100
oc> my $yearint1 = int($yeardiv1);
oc> if ($yeardiv eq $yearint && $yeardiv1 ne $yearint1) {
oc> $TM[1] = 29;
oc> }else { $TM[1] = 28;
oc> }
do you do that for all the leap years in a period of dates? i don't see
an array of days for each year.
oc> if ($MTH == ($mon + 1) && $YRW == $year) {
oc> while (++$TDD <= $mday) { $total_days += 1; }
oc> }else{
oc> while (++$TDD <= $TM[$MTH - 1]) { $total_days += 1; }
that looks like nonsense code. counting up for each date? ever heard of
addition or subtraction?
use a module.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Architecture, Development, Training, Support, Code Review ------
----------- Search or Offer Perl Jobs ----- http://jobs.perl.org ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Tue, 19 Feb 2008 00:32:25 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Number of days since 1/1/2000
Message-Id: <x7y79hkcpy.fsf@mail.sysarch.com>
>>>>> "oc" == oprah chopra <oprah.chopra@gmail.com> writes:
oc> J. Gleixner wrote:
>> Whenever I see that, instead of sprintf, I say to myself,
oc> "Inexperienced > coder."
oc> Well I have been coding perl for seven years and and count on one
oc> hand the number of times I used sprintf. print is simple , why
oc> make code more unreadable by unncessarily cluttering it with
oc> esoteric functions? At least that has always been my
oc> philosophy. Yes there may be more 'technically correct' ways to do
oc> things, but I am running a business and have to look at the bigger
oc> picture . If I hire a new perl programmer, will they know the
oc> difference between print and sprintf?
sprintf is not esoteric. you are thinking baby perl if you assume
that. the bigger picture is better code for MOST perl hackers, not just
the kiddies you think are out there.
oc> I can tell you have a PhD, because you suffer from the classic
oc> ostrich mentality, i.e head is stuck in the ground lookiing at
oc> details, while you can't see the train coming..
wow. no more soup for you!
PS. i do perl code review for a living. i don't tolerate clients who
don't appreciate quality criticism.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Architecture, Development, Training, Support, Code Review ------
----------- Search or Offer Perl Jobs ----- http://jobs.perl.org ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Tue, 19 Feb 2008 00:36:46 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Number of days since 1/1/2000
Message-Id: <x7tzk5kcio.fsf@mail.sysarch.com>
>>>>> "oc" == oprah chopra <oprah.chopra@gmail.com> writes:
oc> J. Gleixner wrote:
>> Whenever I see that, instead of sprintf, I say to myself,
oc> "Inexperienced > coder."
oc> Well I have been coding perl for seven years and and count on one
oc> hand the number of times I used sprintf. print is simple , why make
oc> code more unreadable by unncessarily cluttering it with esoteric
oc> functions? At least that has always been my philosophy. Yes there may
oc> be more 'technically correct' ways to do things, but I am running a
oc> business and have to look at the bigger picture . If I hire a new
oc> perl programmer, will they know the difference between print and
oc> sprintf?
while (++$TDD <= $mday) { $total_days += 1; }
}else{
while (++$TDD <= $TM[$MTH - 1]) { $total_days += 1; }
and is + more esoteric than ++ or += 1??
that code is some of the poorest and slowest code i have seen in a
while. i will steal it for some bad code examples i will use in
teaching. you don't mind, do you?
note the masssive redundancy of all but the <= part. note the
inconsistant use of ++ vs += 1. note the absence of basic math with
subtraction and addition being unused but increment in a loop is used.
esoteric indeed!
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Architecture, Development, Training, Support, Code Review ------
----------- Search or Offer Perl Jobs ----- http://jobs.perl.org ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Mon, 18 Feb 2008 17:15:11 -0800 (PST)
From: "jl_post@hotmail.com" <jl_post@hotmail.com>
Subject: Re: Number of days since 1/1/2000
Message-Id: <3c95d54e-8ad2-4434-aaa0-30db5bad2ec4@d21g2000prf.googlegroups.com>
On Feb 18, 1:22 pm, oprah.cho...@gmail.com wrote:
>
> One problem with Date::Manip is it is not a standard module and not
> available on some of the servers I run the code on.
I've had similar problems. I've often had to write Perl scripts
for customers who either don't have access to CPAN or are forbidden to
install additional packages (outside of the Perl script I write). As
a result, I tend to prefer solutions that can be implemented with
standard modules.
In my opinion, any code that contains an array with the days of the
month, like this:
my @TM = (31,28,31,30,31,30,31,31,30,31,30,31);
is a hint that the program is going down the wrong path. For one
thing, it requires a loop that has to have knowledge if the second
element is correct (which it won't be on leap years).
This approach might seem simple for you, but it's error prone and
difficult for other maintainers (that is, people who are NOT you) to
debug and make sure is correct and accurate.
If you're adamant on not using Date::Manip, try the following
algorithm which happens to not have any loops in it:
# Returns the number of days since January 1, 2000:
sub calc_days
{
# Calculate the epoch time for midnight, January 1, 2000:
use Time::Local; # for timegm()
my $epochTimeFor2000Jan1 = timegm(0,0,0, 1,0,100);
# Get the number of seconds that have elapsed since then:
my $elapsedSeconds = time() - $epochTimeFor2000Jan1;
# Calculate the number of days that have elapsed since then:
my $elapsedDays = int( $elapsedSeconds / (60*60*24) );
return $elapsedDays;
}
And that's it! Notice that the calc_days() subroutine only has
three lines of code (not counting the "use" and "return" lines).
There are no loops involved. Also, the Time::Local module is a
standard module, which means that all the servers you run it on should
already have it.
Here's something to be aware of: My code above uses the timegm()
function, which assumes the time passed in (that is, midnight on
January 1, 2000) is in UTC time, and not local time. If you really
want to use local time, you probably will want to change timegm() to
timelocal(). (But be aware that, when using localtime, not every day
of the year has 24*60*60 seconds, as there are usually two days per
year that have a different amount. Usually this shouldn't be much of
an issue, but just be aware of it anyway.)
You might think that a while-loop with a large block is easier to
read than these three lines of code that use epoch time, but many
maintainers will beg to differ, especially since your while-loop
condition contains || and several &&s.
By the way, if you want to check if the answer from the programs is
correct, you can write a short one-line Perl script. For example, if
your program output:
The number of days since 1/1/2000 is 2971
then type the following:
perl -MTime::Local=timegm_nocheck -lwe "print scalar gmtime
timegm_nocheck(0,0,0,2971+1,0,100)"
(Remember to change the "timegm"s to "timelocal"s if you're using
local time.)
If the date you get back is today's date, then your script calculated
the correct number of days since January 1, 2000. If it didn't, then
you need to track down the bug.
I hope this helps.
-- Jean-Luc
P.S. I happen to agree with the others that using the Date::Manip
module won't include that much overhead. If anything, it'll simplify
your code, and possibly make it even faster in that it would allow you
to eliminate your while-loop.
------------------------------
Date: Tue, 19 Feb 2008 02:53:53 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Number of days since 1/1/2000
Message-Id: <61ur1uF214sikU1@mid.individual.net>
J. Gleixner wrote:
> oprah.chopra@gmail.com wrote:
>> I am using the following subroutine to calculate the number of days
>> since 1/1/2000 . Is there any possible bug in it? I know I can use
>> Date::Manip but it will slow down my program which is around 100 kb
>> long.
>
> It's doubtful that using Date::Manip would slow it down much, if at
> all. So what if using it added .001 second to the run time?
http://search.cpan.org/perldoc?Date%3A%3AManip#SHOULD_I_USE_DATE::MANIP
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Tue, 19 Feb 2008 02:53:58 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Number of days since 1/1/2000
Message-Id: <61ur23F214sikU2@mid.individual.net>
oprah.chopra@gmail.com wrote:
> I am using the following subroutine to calculate the number of days
> since 1/1/2000 . Is there any possible bug in it? I know I can use
> Date::Manip but it will slow down my program which is around 100 kb
> long.
Then use the standard module Time::Local.
use Time::Local;
my $start = timelocal 0, 0, 0, 1, 0, 2000;
my $today = timelocal 0, 0, 0, (localtime)[3..5];
my $days = sprintf '%.0f', ($today - $start) / 86400;
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Tue, 19 Feb 2008 03:17:32 +0100
From: "Petr Vileta" <stoupa@practisoft.cz>
Subject: Re: Number of days since 1/1/2000
Message-Id: <fpdf8s$15n7$1@ns.felk.cvut.cz>
oprah.chopra@gmail.com wrote:
> Martijn Lievaart wrote:
>>
>> Seeing you use a loop to calculate the difference, are you sure
>> Date::Manip is slower? Did you benchmark it? You might be surprised.
>> >
>
> One problem with Date::Manip is it is not a standard module and not
> available on some of the servers I run the code on. Since my code is
> alrady 100+kb long, I would think requireinf another few hundred kb
> would be overkill for something I can do in one subroutine?
Please correct me anybody if I'm wrong.
You can copy your Date.pm module with whole subdirectory structure to some
directory on server (say /home/modules/) and add path to @INC near the script
top. Hosting company will not be happy but this work fine :-)
--
Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your
mail from another non-spammer site please.)
Please reply to <petr AT practisoft DOT cz>
------------------------------
Date: 18 Feb 2008 23:59:35 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: Regular Expression to Replace UPPER Case Text with lower case text
Message-Id: <87fxvp4k3s.fsf@mithril.chromatico.net>
>>>>> "p" == penny <kevin.penny@gmail.com> writes:
p> The reason I didn't go the CFusion newsgroup first is that CF
p> runs with a limited perl engine and I figured you guys would
p> know more about regex than the cf group (eek)
Er, no, while CF may have a PCRE library glommed into it somewhere, it
has no Perl content at all; and "Perl compatible" regular expressions aren't.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Mon, 18 Feb 2008 15:17:23 -0800 (PST)
From: Telemach <telemach@go2.pl>
Subject: Re: Searching within XLS files - is it good approach ?
Message-Id: <b1eb53b7-66d0-4c2a-a2aa-6b1c6f215d2f@s12g2000prg.googlegroups.com>
> Try this one:http://search.cpan.org/~szabgab/Spreadsheet-ParseExcel-0.32/
Do you suggest making a foreach loop that will go thru all of
worksheets matching $variable with every single cell Val ?
I'm asking because there is no direct sub or command to make a search
and I'm wondering if this module will be enough.
- Telemach -
------------------------------
Date: 18 Feb 2008 23:46:19 GMT
From: xhoster@gmail.com
Subject: Re: Searching within XLS files - is it good approach ?
Message-Id: <20080218184622.348$iV@newsreader.com>
Telemach <telemach@go2.pl> wrote:
> > As far as I can tell, most of those will only work on Windows.
>
> I need to get this working under linux
Then Spreadsheet::ParseExcel is the only one I know of.
>
> > Even more can probably be found if you search for "excel" on
> > <http://search.cpan.org/>
>
> I found some but still can't get a decent documentation how to search
> and not only read.
If you aren't using Windows, Excel can't do the searching for you. Do it
in Perl.
Read, test, read, test, read, test.
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: Mon, 18 Feb 2008 15:52:27 -0800 (PST)
From: Telemach <telemach@go2.pl>
Subject: Re: Searching within XLS files - is it good approach ?
Message-Id: <1211b88f-6b80-4628-88a1-fa99c41aceb1@s13g2000prd.googlegroups.com>
> Read, test, read, test, read, test.
From what I understand there is no sub for searching and dedicated
loop will be needed.
- Telemach -
------------------------------
Date: Mon, 18 Feb 2008 20:29:39 -0600
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: Searching within XLS files - is it good approach ?
Message-Id: <slrnfrkfoj.g0a.tadmc@tadmc30.sbcglobal.net>
Telemach <telemach@go2.pl> wrote:
>> Read, test, read, test, read, test.
>
> From what I understand there is no sub for searching and dedicated
> loop will be needed.
That's correct.
Now that you know what is needed, all that's left is to write
code that does what is needed.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Mon, 18 Feb 2008 22:20:57 -0500
From: S P Arif Sahari Wibowo <arifsaha@yahoo.com>
Subject: Re: Searching within XLS files - is it good approach ?
Message-Id: <alpine.OSX.1.00.0802182218180.277@imac2006.local>
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--0-1495459876-1203391259=:277
Content-Type: TEXT/PLAIN; charset=ISO-2022-JP; format=flowed
On Mon, 18 Feb 2008, Telemach wrote:
> Do you suggest making a foreach loop that will go thru all of
> worksheets matching $variable with every single cell Val ?
Why not? An excel spreadsheet basically is a 3D array, how else
you find a value in a 3D array? That's not difficult to code,
right?
> I'm asking because there is no direct sub or command to make a
> search
Might as well, since giving the particular function won't give
much advantage anyway.
--
(stephan paul) Arif Sahari Wibowo
_____ _____ _____ _____
/____ /____/ /____/ /____
_____/ / / / _____/ http://www.arifsaha.com/
Xinnian Kuaile! 新年快樂 Gongxi Facai 恭喜發財
--0-1495459876-1203391259=:277--
------------------------------
Date: Tue, 19 Feb 2008 00:56:38 +0100
From: "Diez B. Roggisch" <deets@nospam.web.de>
Subject: Re: TRAC - Trac, Project Leads, Python, and Mr. Noah Kantrowitz (sanitizer)
Message-Id: <61uk9uF20gb1qU1@mid.uni-berlin.de>
cokofreedom@gmail.com schrieb:
> Dear Ilias,
>
> Post in a single reply.
He has to, in hopes to gain the traction he desires - as otherwise he's
pretty much ignored these days. Which is a good thing of course...
Diez
------------------------------
Date: Mon, 18 Feb 2008 16:51:40 -0800 (PST)
From: George Sakkis <george.sakkis@gmail.com>
Subject: Re: TRAC - Trac, Project Leads, Python, and Mr. Noah Kantrowitz (sanitizer)
Message-Id: <6b03b610-1d7d-4fe8-be77-5e0639301557@d21g2000prf.googlegroups.com>
On Feb 18, 6:56 pm, "Diez B. Roggisch" <de...@nospam.web.de> wrote:
> cokofree...@gmail.com schrieb:
>
> > Dear Ilias,
>
> > Post in a single reply.
>
> He has to, in hopes to gain the traction he desires
^^^^
Was the pun intended ? ;-)
------------------------------
Date: Mon, 18 Feb 2008 20:16:20 -0800 (PST)
From: dale <dalestubblefield@gmail.com>
Subject: Re: Writers Block
Message-Id: <9abf69e2-514f-4a39-a6c6-b0aac86f0275@o10g2000hsf.googlegroups.com>
On Feb 18, 4:02 am, Dave Weaver <zen13...@zen.co.uk> wrote:
> dale <dalestubblefi...@gmail.com> wrote:
> > ############################################# Clean up #########
> > `rm -f /root/bin/temp`;
> > `rm -f /root/bin/tempGID`;
> > `rm -f /root/bin/tempUID`;
> > ###########################################################
>
> Ick!
>
> The `` backticks operator runs a shell command and returns its standard
> output. If you don't want that output, use system() instead.
>
> But there's no need to do that just to delete some files. Perl has its own
> built-in "rm", spelled "unlink".
Dave - thanks man. That is exactly the kind of advice I was looking
for. I will work on implementing this. I come from a bash scripting
background so I am using those crutches until I learn replacement Perl
commands.
J.G. - THANKS!!! I had spent so much time going over this that I
didn't notice the $. Adding that made the script starting error
checking the UID properly.
You are right - normally, a person would not care about the UID.
However, in this case, it is necessary for the UIDs of the accounts to
be in a particular range in the environments I work in. (Fake
Example: UIDs starting with 500 would be for admin accounts and UIDs
starting with 1000 would be user accounts.)
------------------------------
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 1288
***************************************
