[17061] in Perl-Users-Digest
Perl-Users Digest, Issue: 4473 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Sep 29 18:15:39 2000
Date: Fri, 29 Sep 2000 15:15:24 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <970265724-v9-i4473@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Fri, 29 Sep 2000 Volume: 9 Number: 4473
Today's topics:
Processing an "XML" file with mutliple character encodi <bart.lateur@skynet.be>
Re: Processing an "XML" file with mutliple character en ebohlman@omsdev.com
Re: question about regular expressions (shock, horror.. (Craig Berry)
Re: question about regular expressions (shock, horror.. (Craig Berry)
Re: question about regular expressions (shock, horror.. <lr@hpl.hp.com>
Re: question about regular expressions (shock, horror.. <godzilla@stomp.stomp.tokyo>
Re: Questions about space-saving techniques (James Weisberg)
Re: Read and Split Individual Text File Lines <tim@ipac.caltech.edu>
Re: Salary Range for Perl Programmers <nico@monnet.to>
Re: sending attachments with perl <dsimonis@fiderus.com>
Re: Sorry - TOTAL newbie <bart.lateur@skynet.be>
substituting for spaces at the beginning of a line <ldk006@email.mot.com>
Re: substituting for spaces at the beginning of a line <mauldin@netstorm.net>
Re: substituting for spaces at the beginning of a line <godzilla@stomp.stomp.tokyo>
Re: temporary file names nobull@mail.com
Re: temporary file names <abaxaba@my-deja.com>
Re: Very newbie! <dsimonis@fiderus.com>
Re: Very newbie! <jeff@vpservices.com>
Re: What could this mean? (Enchanted)
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 29 Sep 2000 18:57:01 GMT
From: Bart Lateur <bart.lateur@skynet.be>
Subject: Processing an "XML" file with mutliple character encodings
Message-Id: <q0p9tsojrcfb0jhg4td57g9990cdi9j2h6@4ax.com>
I have this file, which has the proper structure of an XML file. The
only problem is that is contains text of different character encodings,
depending on the "font", which is one of the attributes in one of the
tags. This tag attribute determines the character encoding of all bare
text contents (not of attributes, those are all Ascii) nested in that
tag. The ultimate goal is to turn all text into UTF8. How?
I am thinking of using XML parser, but then I need a way of tricking
into accepting my text whatever it contains. I'd like XML::Parser to
basically leave the characters as is, or maybe turn them into
pseudo-UTF8, as if the source was in ISO-Latin-1. But XML::Parser is
very picky: one "illegal" character, and the script dies.
I think that once past this hurdle, I can process the text.
Or, are there any other approaches that are less complicated?
--
Bart.
------------------------------
Date: 29 Sep 2000 19:10:12 GMT
From: ebohlman@omsdev.com
Subject: Re: Processing an "XML" file with mutliple character encodings
Message-Id: <8r2pek$1n8$5@news.enteract.com>
Bart Lateur <bart.lateur@skynet.be> wrote:
> I have this file, which has the proper structure of an XML file. The
> only problem is that is contains text of different character encodings,
> depending on the "font", which is one of the attributes in one of the
> tags. This tag attribute determines the character encoding of all bare
> text contents (not of attributes, those are all Ascii) nested in that
> tag. The ultimate goal is to turn all text into UTF8. How?
> I am thinking of using XML parser, but then I need a way of tricking
> into accepting my text whatever it contains. I'd like XML::Parser to
> basically leave the characters as is, or maybe turn them into
> pseudo-UTF8, as if the source was in ISO-Latin-1. But XML::Parser is
> very picky: one "illegal" character, and the script dies.
You could read the file into a string and then repeatedly call XML::Parser
on it inside an eval {} block. Each time you got an encoding error, you'd
parse the error message to find the location and then, based on the
attribute value (which you'd have gathered in one of your handlers),
recode the offending text into UTF-8 and repeat the process until no
errors were encountered, at which point you'd save the file.
------------------------------
Date: Fri, 29 Sep 2000 19:18:56 -0000
From: cberry@cinenet.net (Craig Berry)
Subject: Re: question about regular expressions (shock, horror.. )
Message-Id: <st9qp0geicdo4a@corp.supernews.com>
Steve Howe (stephen@bcl.com) wrote:
: for the clever people out there..
: what the _heck_ does the regular expression in this do, please?
:
: if ($query->param('save-as-filename') !~ /^[ \t]*$/) {
: $filename = $query->param('save-as-filename');
Take it apart piece by piece, working outward from the innards (a good
general rule for deciphering code). The regex /^[ \t]*$/ matches
beginning of string, followed by zero or more spaces or tabs, followed by
end of string or a newline. So, it's basically detecting what might be
called "blank" (whitespace-only) lines. Personally, I'd tend to write it
as /^\s*$/, which means almost the same thing and will behave identically
in most common situations where code like this would be used (e.g., no
embedded newlines in the string).
The binding operator !~ inverts the sense of the test, so that the
expression will be true if the regex does *not* match. So what it's
saying is "if the save-as-filename parameter isn't blank, set $filename to
this value." Again, this leads to a suggested rewrite:
if ($query->param('save-as-filename') =~ /\S/) {
$filename = $query->param('save-as-filename');
In other words, if the save-as-filename parameter has any non-whitespace
characters in it, use it, This is easier to read (IMHO).
: Steve Howe
Love your guitar work with Yes, btw. :)
--
| Craig Berry - http://www.cinenet.net/~cberry/
--*-- "Quidquid latine dictum sit, altum viditur."
|
------------------------------
Date: Fri, 29 Sep 2000 19:21:05 -0000
From: cberry@cinenet.net (Craig Berry)
Subject: Re: question about regular expressions (shock, horror.. )
Message-Id: <st9qt1aeav9p82@corp.supernews.com>
Larry Rosler (lr@hpl.hp.com) wrote:
: But it accepts a filename consisting only of a newline character. That
: is a valid character in a Unix filename (though anyone who uses it
: deserves chastisement -- think of what it does to an `ls` listing, for
: example).
:
: A purist would write that regex as /^\s*\z/
That still allows embedded as well as terminal newlines, since \n is in
\s.
--
| Craig Berry - http://www.cinenet.net/~cberry/
--*-- "Quidquid latine dictum sit, altum viditur."
|
------------------------------
Date: Fri, 29 Sep 2000 13:53:46 -0700
From: Larry Rosler <lr@hpl.hp.com>
Subject: Re: question about regular expressions (shock, horror.. )
Message-Id: <MPG.143ea1312a3786e898adde@nntp.hpl.hp.com>
In article <st9qt1aeav9p82@corp.supernews.com> on Fri, 29 Sep 2000
19:21:05 -0000, Craig Berry <cberry@cinenet.net> says...
> Larry Rosler (lr@hpl.hp.com) wrote:
> : But it accepts a filename consisting only of a newline character. That
> : is a valid character in a Unix filename (though anyone who uses it
> : deserves chastisement -- think of what it does to an `ls` listing, for
> : example).
> :
> : A purist would write that regex as /^\s*\z/
>
> That still allows embedded as well as terminal newlines, since \n is in
> \s.
The regex *matches* (not 'allows' -- it disallows!) strings consisting
only of whitespace (including newlines) anywhere, and rules them out.
My objection to using '$' at the end was to point out the loophole which
accepted a filename consisting only of a single newline character.
Each of us provided a Better Way (invert the test and accept any
filename with at least one non-whitepace character). So I don't get the
point of your remark.
--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Fri, 29 Sep 2000 14:25:05 -0700
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: question about regular expressions (shock, horror.. )
Message-Id: <39D508B1.E75DBD79@stomp.stomp.tokyo>
Larry Rosler wrote:
> Craig Berry wrote:
> > Larry Rosler wrote:
> > : But it accepts a filename consisting only of a newline character. That
> > : is a valid character in a Unix filename (though anyone who uses it
> > : deserves chastisement -- think of what it does to an `ls` listing, for
> > : example).
> > : A purist would write that regex as /^\s*\z/
> > That still allows embedded as well as terminal newlines, since \n is in
> > \s.
> The regex *matches* (not 'allows' -- it disallows!) strings consisting
> only of whitespace (including newlines) anywhere, and rules them out.
> My objection to using '$' at the end was to point out the loophole which
> accepted a filename consisting only of a single newline character.
> Each of us provided a Better Way (invert the test and accept any
> filename with at least one non-whitepace character). So I don't get the
> point of your remark.
There are other serious problems, Mr. Rosler, Mr. Berry, with
either method. A quick example, .htaccess would be allowed.
This could play havoc if an htaccess is written just the
right way, with malice intent, especially in parent directory.
My personal preference for file uploads is to restrict a
visitor to a very selective format, from a script viewpoint,
abcdefgh.ext
Only that format with numbers and underscore included. Obviously
our word character set and a single period, in a traditional
eight character DOS format, with a requirement of an extension
having three characters, precisely, avoiding unix single letter
extension funny business.
Part of my perference is this avoids the 'long file name' mess
created by Redmond under Win 9.x series and beyond. This has to
be amongst the most stupid changes Redmond made going from
powerful Win 3.x / DOS 6.x to Win 9.x / stripped down DOS.
Downloading long file names from a unix envioronment then
having to clean up those file names, is annoying.
Ever look at long file names and long directory names in
DOS under Win 9.x ?? Enough to make ya scream. So stupid.
Anyhow, file uploads are amongst those 'things' which should
be severely restricted in format for security.
Godzilla!
--
Dr. Kiralynne Schilitubi ¦ Cooling Fan Specialist
UofD: University of Duh! ¦ ENIAC Hard Wiring Pro
BumScrew, South of Egypt ¦ HTML Programming Class
------------------------------
Date: Fri, 29 Sep 2000 20:08:18 GMT
From: chadbour@wwa.com (James Weisberg)
Subject: Re: Questions about space-saving techniques
Message-Id: <SE6B5.7356$l35.144634@iad-read.news.verio.net>
In article <MPG.143d4f0c27bd52f398add4@nntp.hpl.hp.com>,
Larry Rosler <lr@hpl.hp.com> wrote:
>Sep 2000 19:49:44 GMT, James Weisberg <chadbour@wwa.com> says...
>> In article <MPG.143d224eb798330098add0@nntp.hpl.hp.com>,
>> Larry Rosler <lr@hpl.hp.com> wrote:
>> >In article <usKA5.5654$l35.133134@iad-read.news.verio.net> on Thu, 28
>> >Sep 2000 16:36:42 GMT, James Weisberg <chadbour@wwa.com> says...
>> >> If you're interested, I could use a suggestion on how to take a
>> >> typical packstring like: (LCCCaCaCCaCaCaaaaaaaaaaCCCaaaaaCCCaaaaaC)
>> >> and turn that into (LC3aCaC2aCaCa10C3a5C3a5C). Just as an exercise
>> >> in efficiency, ...
>
>> > s/(([A-Za-z])\2+)/$2 . length $1/eg
>>
>> Yes, well I was fully prepared to issue a less wordy challenge
>> and then respond with a 186-line post for why I needed it!
>
>Only 86 lines this time. :-)
Imagine what you could do with 86 lines of Perl code!
>> Why does my @r array not get fully expanded by the "a10" packstring
>> with unpack? It certainly works if I stuff my array with 1's instead of
>> a's and use a packstring of "i10" instead of "a10".
>...
>> is using your substition directive to turn the packstring:
>> (LCCCaCaCCaCaCaaaaaaaaaaCCCaaaaaCCCaaaaaC) to (LC3aCaC2aCaCa10C3a5C3a5C).
>> The problem, is that unpack isn't giving me back 10 ''s when I uncompress
>> the record string. What's up with that?
>
>What's up is that I unhelpfully didn't consider the semantics of your
>request, and dealt with it only as a syntactic exercise. In fact, as
>you discovered, the semantics of 'a10' and 'i10' or 'C10' are quite
>different. For 'a' it is a length; for the others it is a 'repeat
>count'.
Okay. Well, after considering this further, I decided to re-think
my compression routine anyway and came up with:
sub dbrec_compress {
my $packstr;
for (@_) {
$_ = -1 if not defined $_;
if ( $_ < 128 )
{ $packstr .= 'c'}
elsif ( $_ < 65536 )
{ $packstr .= 'S'}
elsif ( $_ < 4294967296)
{ $packstr .= 'L'}
else { die "Field record $_ too large to pack.\n")}
}
$packstr =~ s/(([A-Za-z])\2+)/$2 . length $1/eg; # Thanx Larry Rosler!
my $packlen = length($packstr);
return pack("Ca$packlen$packstr", $packlen, $packstr, @_);
}
Instead of even worrying about undefined values, I'll just turn them
into -1's and store them, along with anything else < 128 as a signed char.
Not only do I get the desired repeat count behavior of writing cN in the
unpack string, but I also create very short pack strings for null records
or even records where all field values are < 128 (for a 40-field record,
it could be as simple as "c40").
This approach has *greatly* reduced the amount of memory being used
at the cost of a more expensive uncompress operation.
--
World's Greatest Living Poster
------------------------------
Date: Fri, 29 Sep 2000 11:53:58 -0700
From: Tim Conrow <tim@ipac.caltech.edu>
Subject: Re: Read and Split Individual Text File Lines
Message-Id: <39D4E546.EE7BC26C@ipac.caltech.edu>
pgodkin@my-deja.com wrote:
>
> This should be easy. All I want to do is step through the first 4 lines
> of a text file, split each line and get the second field value. I don't
> want to use a while statement as the file is large.
What frightens you about using a while statement on a large file?
while(<DATA>) {
my ($field1, $field2) = split;
last if $. == 4;
}
--
-- Tim Conrow tim@ipac.caltech.edu |
------------------------------
Date: Fri, 29 Sep 2000 20:05:45 +0100
From: "Nicolas MONNET" <nico@monnet.to>
Subject: Re: Salary Range for Perl Programmers
Message-Id: <xY4B5.95$N3.6371@tengri.easynet.fr>
What the fuck was Uri Guttman <uri@sysarch.com> trying to say:
>>>>>> "NM" == Nicolas MONNET <nico@monnet.to> writes:
> NM> Offtopic: I'd never get around to understand why some people NM>
> seem to be so proud to announce to the world the content NM> of their
> killfile.
>
> you don't understand much about usenet in general it seems.
Now that's 1) really uncalled for 2) a really lame flame.
Would you please point out what I don't understand about
Usenet?
I do undestand however that you're one hell of a nitpicker.
--
perl -e 'print `echo Just a Lame Perl Luser | gzip -9 | cat | gzip -cd`'
------------------------------
Date: Fri, 29 Sep 2000 09:38:21 -0400
From: Drew Simonis <dsimonis@fiderus.com>
Subject: Re: sending attachments with perl
Message-Id: <39D49B4D.8EE3AA67@fiderus.com>
Hugo Bouckaert wrote:
>
> Hi
>
> I am still trying to send attachments with perl which don't appear in
> the body of the email.
>
Your problem is likely not one of the Perl code. Mail clients
like to show off and play tricks. Many will convert an attached
text file to display inline. I am pretty sure that Netscape Mail
acts this way, and am certain that Lotus Notes will do it too.
My workaround was to declare text files as application/doc, which
kept them as an attachment.
For the .gif files, are you uploading them as a binary? (I didn't
look very long at ytour source, but I didn't notice a binmode
function. If you upload them as ascii instead of binary, that
might also cause problems. Moral of the story, check other
avenues of attack, the problem could be elsewhere....
HTH
------------------------------
Date: Fri, 29 Sep 2000 19:09:07 GMT
From: Bart Lateur <bart.lateur@skynet.be>
Subject: Re: Sorry - TOTAL newbie
Message-Id: <c3q9ts0fea9tf6a7s924cqp2pa5j3kbfv4@4ax.com>
eyedunno wrote:
>for i = 0 to len(mystr$) step 2
>I've tried
>for ( $i = 0; $i <= $#myfile; $i=$i+2 ) {
>....}
>===========================
>but it doesn't work :-(
A Perl string is not an array.
for($i = 0; $i <= length($mystr); $i += 2) {
print substr $mystr, $i, 1;
}
--
Bart.
------------------------------
Date: Fri, 29 Sep 2000 15:18:30 -0400
From: David Kowal <ldk006@email.mot.com>
Subject: substituting for spaces at the beginning of a line
Message-Id: <39D4EB05.C8A123BF@email.mot.com>
I'd like to be able to remove all spaces in a beginning of a line and am using the following code:
$Text{'Change Request'} =~ s/^\s+//g;
Unfortunately, it only removes one space. Any reason why?
Appreciate any help or reference.
--
-
*****************************************
David E. Kowal
Software Tools Engineering/Administration
Motorola Internet and Networking Group
LDK006@email.mot.com (508) 261-5649
*****************************************
------------------------------
Date: Fri, 29 Sep 2000 20:11:52 GMT
From: Jim Mauldin <mauldin@netstorm.net>
Subject: Re: substituting for spaces at the beginning of a line
Message-Id: <39D4F74D.3D5AA6AC@netstorm.net>
David Kowal wrote:
>
> I'd like to be able to remove all spaces in a beginning of a line and am using the following code:
>
> $Text{'Change Request'} =~ s/^\s+//g;
^
First: no need for the /g modifier because the pattern can only match
once, at the beginning of the string.
> Unfortunately, it only removes one space. Any reason why?
It works for me. What's in $Text{'Change Request'}?
-- Jim
------------------------------
Date: Fri, 29 Sep 2000 15:01:35 -0700
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: substituting for spaces at the beginning of a line
Message-Id: <39D5113F.49DC4163@stomp.stomp.tokyo>
David Kowal wrote:
> I'd like to be able to remove all spaces in a beginning of a
> line and am using the following code:
> $Text{'Change Request'} =~ s/^\s+//g;
> Unfortunately, it only removes one space. Any reason why?
> Appreciate any help or reference.
Double check your script to be sure a space or spaces
are not being added after this line of yours, for
whatever reason. I have fallen into this trap and
similar traps many times, having forgotten about
something else my script does, later.
Your regex is just fine. No problem there. You may
remove your 'g' gobbler at the end, not needed.
There are some easy and quick debug methods. First
convert your script to print plaintext or "xmp" if
printing html so you can 'see' spaces better. This
can be done by adding html tags to your print or,
if possible, have your entire print as plaintext.
print "TEST 1: ¦$Text{'Change Request'}¦\n";
$Text{'Change Request'} =~ s/^\s+//g;
print "TEST 2: ¦$Text{'Change Request'}¦\n";
(more processes)
print "TEST 3: ¦$Text{'Change Request'}¦\n";
Get the idea? This will display your data
flow by printing data at selected lines
within your script. You will notice my
addition of " ¦ " which makes spaces jump
right out; they become very noticable.
Another debugger is to substitute your spaces
with a special character which makes spotting
spaces, lots easier on the eyes. A capital X
or capital Z works well for this, to debug.
XXXSomeXwordsXhereXXXXX
is easier to 'see' than,
Some words here <- extra invisible spaces
You will discover, under very exacting circumstances,
a form action input will screwup a regex based on
catching the very first character. Try adding a space
to the beginning of your input variable right off, then
test your regex substitutions. This is quite rare but does
happen for highly selective circumstances. Chances are
good your script doesn't have this bug.
$Text{'Change Request'} = " $Text{'Change Request'}";
$Text{'Change Request'} =~ s/^\s+//g;
Discover if those extra spaces don't vanish suddenly
after you tag on a leading space. Crazy I know, but
this has happened to me.
Trace your data flow through your script with highly
visible prints. You will find the location of your
bug, almost instantly.
Godzilla!
------------------------------
Date: 29 Sep 2000 19:19:00 +0100
From: nobull@mail.com
Subject: Re: temporary file names
Message-Id: <u9r9636oyz.fsf@wcl-l.bham.ac.uk>
Nick Wilson <wilson@world.std.com> writes:
> Does Perl have a built-in mechanism for generating temporary file names
> (something like tmpnam() in C)?
tmpnam() isn't built-in in C. (It's part of the standard POSIX libraries).
IO::File->new_tmpfile isn't built-in in Perl. (It's part of the
standard Perl libraries).
Of course you can also use the POSIX tmpnam() in Perl if you like.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: Fri, 29 Sep 2000 20:54:00 GMT
From: abaxaba <abaxaba@my-deja.com>
Subject: Re: temporary file names
Message-Id: <8r2vh3$h69$1@nnrp1.deja.com>
Why not use $$. Won't this generate a unique fileName?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Fri, 29 Sep 2000 09:42:20 -0400
From: Drew Simonis <dsimonis@fiderus.com>
Subject: Re: Very newbie!
Message-Id: <39D49C3C.6D97F638@fiderus.com>
Rodney Engdahl wrote:
>
> In article <1cKy5.3056$6b2.52052@news6-win.server.ntlworld.com>,
> "vertical.reality" <vertical.reality@ntlworld.com> wrote:
> > I have installed Active Perl onto my machine (win98)
> >
> > Does this mean I can run the script locally to view the results
> > without uploading them and then viewing them ?????
>
> depending on what your perl script does, and assuming that 'locally'
> means 'on the machine just mentioned', yes.
>
> > Probably a silly question!
>
> no.
>
> >
> > Is it something to do with the first line in the script ......?
>
> on my system, I type:
>
> perl my-script-path-and-name
>
> regardless of the path specified on the shebang line.
If you are running it that way, be sure to include the warnings.
# perl -w my-script-path-and-name
------------------------------
Date: Fri, 29 Sep 2000 12:24:49 -0700
From: Jeff Zucker <jeff@vpservices.com>
Subject: Re: Very newbie!
Message-Id: <39D4EC81.31606F44@vpservices.com>
"vertical.reality" wrote:
>
> I have installed Active Perl onto my machine (win98)
>
> Does this mean I can run the script locally to view the results without
> uploading them and then viewing them ????? Probably a silly question!
>
> Is it something to do with the first line in the script ......?
Others have told you how to run a regular Perl script. My ESP tells me
you might be asking about CGI scripts and that you might want to view
them in a browser rather than (or in addition to) on the command line.
If so, the answer is still yes, you can run them locally without
uploading them, but to do so you must first install a web server. That
is free and easy, the details can be found in the ActivePerl
documentation that was automatically installed on your computer when you
installed Perl. Click on Start Menu - Programs - ActivePerl -
Documentation and look for the part on "Web Server Config" in the
ActivePerl FAQ. That section also addresses the question of what does
or doesn't need to go on your first line (the shebang line) for
different web servers.
--
Jeff
------------------------------
Date: Fri, 29 Sep 2000 21:30:20 GMT
From: no@spam.com (Enchanted)
Subject: Re: What could this mean?
Message-Id: <39d5075b.863340948@news.attcanada.net>
I was thinking in a similar fashion about it being some kind of system
stat but I didn't know if it was being generated by Perl or the
system. (Consensus seems it's not by Perl).
The script itself has no system calls or time calls. There is a lot
arithmetic with simple but large numbers and some large divisions.
This doesn't happen with other Perl scripts on the box though. But
since it's not obvious to anyone maybe the shell/OS is doing it
somehow.
Maybe I'll try running it on another box/OS and see what happens...
Enchanted
On Fri, 29 Sep 2000 07:41:30 -0500, Michael Carman <mjcarman@home.com>
wrote:
>Enchanted wrote:
>>
>> At the very end of my perl script, I'm getting this generated to
>> STDERR (runs on FreeBSD)
>>
>> 21.098u 0.195s 0:48.40 43.9% 10+7145k 46+149io 0pf+0w
>>
>> One wild guess I have is that I may have some illegal division
>> somewhere or something but if you look at it, it looks like it means
>> something.
>
>Yes, I'd wager that it does, and it's not a div by zero.
>
>> Anyone have an idea what, or advice on how to investigate further?
>> (and why it appears)
>
>It looks like usage stats for system resources to me. The first chunk
>(up to the 43.9%) is timing, the later stuff looks lime memory usage. Do
>you have a call to the *system* time function anywhere in your script?
>Or is something set up in your FreeBSD install to always report this
>info when running scripts? (i.e. do other Perl scripts do the same
>thing?)
>
>-mjc
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
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: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
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 V9 Issue 4473
**************************************
