[9977] in Perl-Users-Digest
Perl-Users Digest, Issue: 3570 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Aug 28 01:02:57 1998
Date: Thu, 27 Aug 98 22:00:20 -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, 27 Aug 1998 Volume: 8 Number: 3570
Today's topics:
Bit of humor (nobody)
Can IOCTL be used to read the table of contents from a bpeck@my-dejanews.com
Re: Code Style (Was: How to sort this associative array (Kevin Reid)
Re: comp.lang.perl.windows.misc (Mark)
Re: comp.lang.perl.windows.misc <danboo@negia.net>
Re: Exporting Methods (Mark-Jason Dominus)
Re: Help - Perl security problem! (Maurice Aubrey)
Re: Help - Perl security problem! (Mark-Jason Dominus)
Re: Help Request: Perl SQL Support? (William D. Reardon)
how to read Excel files (was Re: OLE Perl Excel) <casfaq@locutus.ofB.ORG>
Re: Misinterpreted => why no true/false keywords? <zenin@bawdycaste.org>
Re: newbie question (Ronald J Kimball)
Re: Perl compiler <p-fein@uchicago.edu>
Re: Perl script compiling <mee@mine.com>
Re: question RE downloading webpages and parsing them. (Martien Verbruggen)
typeglobs and references... (re: Prog Perl, p 117) <b.d.low@unsw.edu.au>
Re: Unreadable Scripts? (Martien Verbruggen)
Re: Unreadable Scripts? (Martien Verbruggen)
Re: Unreadable Scripts? (Ronald J Kimball)
use vars and my, have I got it right? <b.d.low@unsw.edu.au>
Why do these two differ? fremont@ix.netcom.com
Re: Why do these two differ? <nguyend7@msu.edu>
Re: Why do these two differ? <goldfinger69@geocities.com>
Re: Why do these two differ? (Ronald J Kimball)
Re: Y2K Date Support <mee@mine.com>
Re: Y2K Date Support (Craig Berry)
Special: Digest Administrivia (Last modified: 12 Mar 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 28 Aug 1998 04:23:54 GMT
From: ac1@fspc.netsys.itg.telecom.com.au (nobody)
Subject: Bit of humor
Message-Id: <6s5bcq$f87@newsserver.trl.OZ.AU>
Thought you bods might appreciate this bit of humor I found in
one of our code reviews - the link to Perl is tenuous at best,
but the reviewing crowd got a laugh out of it.
# Get the current date/time and pid from the system. Note the sneaky
# trick to decide which century we are in. If you're reading this
# in 2069, my apologies: you think we would have learned from the
# Y2K crisis - now you know better. If you're looking at this code
# to ensure it passes the 32-bit-UNIX 2038 bug, please fix this as
# well; we're far too busy on Y2K at the moment :-).
($Sec,$Min,$Hr,$MDay,$Mon,$Yr,$Junk,$Junk,$Junk) = localtime( time );
$Yr += ($Yr < 70) ? 2000 : 1900;
AC.
------------------------------
Date: Fri, 28 Aug 1998 03:10:49 GMT
From: bpeck@my-dejanews.com
Subject: Can IOCTL be used to read the table of contents from a CD?
Message-Id: <6s573o$1pu$1@nnrp1.dejanews.com>
I am trying to write a program in perl that will read the TOC off of a cd and
do the cddb algorthym to generate the disc id and then look it up via the
database protocol. But I can't get past the part of reading the TOC off the
cd..
Any ideas? Thanks...
Please send suggestsion to my email address...
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
------------------------------
Date: Thu, 27 Aug 1998 23:46:04 -0400
From: kpreid@ibm.net (Kevin Reid)
Subject: Re: Code Style (Was: How to sort this associative array?)
Message-Id: <1dee453.8n20vd1u9yeoqN@slip166-72-108-198.ny.us.ibm.net>
Zenin <zenin@bawdycaste.org> wrote:
> Kevin Reid <kpreid@ibm.net> wrote:
> : Just thought I'd list some of my formatting styles:
> : my $self = bless {
> : param => 'value',
> : p2 => $input,
> : }, $class;
>
> I'd line up the "=>"s, but that's me. :-)
I would too, sometimes (e.g. if they were related values).
> : for ($i = 0; $i < maxval(); $i++) {
> : code;
> : }
> : if (
> : cond1 and
> : cond2 and
> : cond3
> : ) {
> : code;
> : }
>
> Putting the flow control keywords at the end is problematic if
> your conditions aren't very short:
>
> if (
> some condiontion and
> cond2 and
> some other condition that is long and
> something and
> yet another long condition or (
> foo and
> bar and
> dog
> )
> ) {
> code;
> }
>
> I personally find this much easier to read:
>
> if (
> some condiontion
> and cond2
> and some other condition that is long
> and something
> and yet another long condition
> or (
> foo
> and bar
> and dog
> )
> ) {
> code;
> }
Again, I do that sometimes.
> : $win->sethook("hit", sub {
> : my ($self, $window) = @_;
> : code;
> : });
>
> These I tend to pull out, but that's just me:
>
> $win->sethook (
> "hit" => sub {
> my ($self, $window) = @_;
> code;
> },
> );
I would use that structure if it were a hash; but sethook() takes only
two parameters, so I like to state them compactly.
BTW, do you know what that code is part of?
--
Kevin Reid. | Macintosh.
"I'm me." | Think different.
------------------------------
Date: Thu, 27 Aug 1998 21:33:09 -0500
From: elistan@metronet.com (Mark)
Subject: Re: comp.lang.perl.windows.misc
Message-Id: <MPG.104fd2ded27ddaeb989682@news.metronet.com>
In article <6s27vl$efs$1@marina.cinenet.net>, cberry@cinenet.net says...
> Can we please drop the arguments from misued categories, please? Try
> doing s/Win32/black/g and s/\*nix/asian/g on the above, and see how it
> sounds. The OS someone chooses to use is *not* *relevant* to how they
> post, or how they use Perl, except (in both cases) in the technical,
> what-version/tool-is-being-used sense. Saying "all A are B" is generally
> useless; it's either false or a tautology.
For one, I agree with the above.
For two, I'd be very interested in seeing comp.lang.perl.win32. So one
day a couple weeks ago my boss says "Hey Mark, what do you know about
Perl?" I reply, "Uh, it's, like, a scripting language?" "Well, go learn
it. I think it could help us" "Uh, okay." (I'd be interested in the
win32 group not so much to ask/answer questions like "How do I use
hashes?" <grin> or "Why doesn't QueryValue give me back an object
reference?" [Which I still don't know the answer to, but at least I found
on the web a different way to do it.] Rather, I've very interested in
WHAT sort of things people are using Perl for in a win32 environment,
instead of HOW to do stuff.)
Or something.
------------------------------
Date: Thu, 27 Aug 1998 19:57:23 -0400
From: Dan Boorstein <danboo@negia.net>
Subject: Re: comp.lang.perl.windows.misc
Message-Id: <35E5F263.19987795@negia.net>
Greg Bacon wrote:
>
> In article <35E47639.9BF271E6@negia.net>,
> Dan Boorstein <danboo@negia.net> writes:
> : Greg Bacon wrote:
> : > Please provide evidence for the claim that people who post from the
> : > .edu TLD are rude and clueless.
> :
> : hmm, this sounds awfully familiar greg.
> :
> : s/the\n\.edu TLD/win32/
> :
> : i believe you've received this challenge previously and failed to
> : produce any evidence except personal observation. considering the
> : seriousness of the claim i find this unacceptable (as i do bob's claim).
> : why is bob required to do that which you are not?
>
> While I would love to clean your magnificent stables in one day, I
> don't know of a river to redirect through them. Come on, Dan. Every
> article carried by Usenet is required to contain a From: header.
> This is not the case for X-Newsreader:.
so, why on earth are you challenging bob to prove it? what method
should he use that you cannot?
and by the way, i'm in atlanta so the chattahoochee would be your
best bet on finding a nice sized local river.
best of luck, i expect the stables to be sparkling by morning.
--
Dan Boorstein home: danboo@negia.net work: danboo@y-dna.com
"THERE IS AS YET INSUFFICIENT DATA FOR A MEANINGFUL ANSWER."
- Cosmic AC
------------------------------
Date: 27 Aug 1998 21:31:10 -0400
From: mjd@op.net (Mark-Jason Dominus)
Subject: Re: Exporting Methods
Message-Id: <6s518u$49k$1@monet.op.net>
In article <35E62A8F.531D@comenius.ms.mff.cuni.cz>,
Jan Krynicky <JKRY3025@comenius.ms.mff.cuni.cz> wrote:
> Instead of
>
> sub Msql::myquery {
>
>I would use
>
> package Msql;
> sub myquery {
Yes, that's good. But it was only a forty-minute talk, so I had to
leave out the parts that I thought people would figure out by
themselves.
Keeping it down to forty minutes was a big problem. I ended up giving
a completely different talk than the one I originally planned to,
because the original talk would have had to be at least 90 minutes.
Of course, my big dream is to turn it into a 150-minute (or even 300-
minute) version and give it as a tutorial, which wouldn't be hard,
because I have plenty to say. Buthow many people would be willing to
spend $250 to hear me talk about programming technique. If you are
one of these people, please write to the conference people and tell
them so.
>2. Memoizing
>
>There is also another cool way to compute Factorial or Fibonaci.
>Using Lazy.pm ( http://jenda.krynicky.cz/ ):
>
> use Lazy '@fact' => sub {my $n=$_[0]; return 0 if $n<0; $n == 0 ? 1 :
>$fact[$n-1] };
What happened here is very intersting. There are these four closely
related ideas:
A. Streams
B. Lazy evaluation
C. Memoization
D. Tied variables
It is very hard to draw a clear boundary between these things.
Programs written to demonstrate one or two of these invariably cross
over the invisible border into the territory of the others. Every
time I write about two of these, say A and B, someone is sure to come
along and say ``Ah! But what about A with C?'' Or ``Ah, but what
about D by way of B?'' This is not a complaint.
For example, about a year ago, I wrote an article on lazy evaluation
with streams to implement infinite lists in Perl. The structure of
the lists was rather like a conventional linked list, which a bunch of
hashes, each of which had a `Next' key with a reference to another node.
I wanted to emphasize the laziness and the streamness, so I swept the
memoization part under the carpet. But in an end-note, I suggested
using an array to cache the memoized values, for efficiency. Soon
after, I got a letter from an interested reader (sorry, I forgot who
it was) with an implementation of that, a lot like a cross between the
code you just showed and the the code I discussed in the article.
I realized that if one were going to Memoize the streams into an
array, one might just as well just use a tied memoized array to begin
with, as you did. So you have the CD cross here, with a dash of B,
where the article had more of a AB approach with a dash of C, and my
correspondent was somewhere in the middle.
My `Memoize' package, which does pretty much the same thing, takes a
kind of BC approach:
> use Lazy '@fib' => sub {my $n=$_[0]; $n < 2 ? $n : $fib[$n-1] + $fib[$n-2]};
>Memoizing looks a bit more understandable though.
In Memoize world, you already have a `fib' function in your program,
and you think you would like to try to make it faster, so you write this:
use Memoize;
memoize 'fib';
and then nothing else has to change; the only difference is that `fib'
has magically gotten much faster. One can take an approach that looks
more like what you wrote, by doing this:
$memoized_fib = memoize sub { my $n = $_[0]; .... as above .... };
$val = $memoized_fib->(11); # This is fast
But for anonymous functions your array (or hash) interface is probably
nicer, while mine always retains the functional interface. The idea
behindd `Memoize' is that you should be able to activate or deactivate
memoization on any function without changing the rest of your code. I
wanted to encourage a `tool' approach: You have this memoizing tool,
and it's easy to turn it on or off just by flipping a switch. The
Lisp folks do this and they think it's useful. Those Lisp folks are
very smart, and I try to pay attention to them whenever I can.
One possible downside of Memoize: It always uses a hash to cache the
return values; it may therefore perform more poorly than your version
which uses an array. One possible upside: If you want, `Memoize' will
store the cache on disk for the next run.
Other readers may want to investigate these matters at:
# Infinite lists
http://www.plover.com/~mjd/perl/Stream/NOTES.html
# Memoizing
http://www.plover.com/~mjd/perl/Memoize/
http://www.plover.com/~mjd/perl/TPC/Hardware-notes.html#Memoizing
>BTW: MJD, is there any progress with Interpolation.pm ?
Well, some helpful person in CZ sent me a very nice set of patches
which I've been too busy to apply, but I guess you already knew that.
:)
------------------------------
Date: Fri, 28 Aug 1998 02:21:05 GMT
From: maurice@hevanet.com (Maurice Aubrey)
Subject: Re: Help - Perl security problem!
Message-Id: <slrn6uc50j.37a.maurice@we-24-130-48-83.we.mediaone.net>
On Fri, 28 Aug 1998 05:39:08 GMT, Ben Duncan <ben@isolve.net> wrote:
>I've fixed my problem by writing a c-wrapper which calls setuid/setgid
>& then exec's the perl script.
It sounds like you should read more about how to untaint data.
--
Maurice Aubrey <maurice@hevanet.com>
Underlying most arguments against the free market is a lack of belief
in freedom itself.
- Milton Friedman
------------------------------
Date: 28 Aug 1998 00:51:00 -0400
From: mjd@op.net (Mark-Jason Dominus)
Subject: Re: Help - Perl security problem!
Message-Id: <6s5cvk$54k$1@monet.op.net>
In article <35e6422b.14272636@news.netcom.ca>,
Ben Duncan <ben@smartservers.com> wrote:
>I've fixed my problem by writing a c-wrapper which calls setuid/setgid
>& then exec's the perl script.
Oh, good! Now you have the problem without the warning.
------------------------------
Date: Fri, 28 Aug 1998 01:56:05 GMT
From: wdr1@pobox.com (William D. Reardon)
Subject: Re: Help Request: Perl SQL Support?
Message-Id: <EyDMpI.7Dt@midway.uchicago.edu>
In article <35E5D775.B2707CF2@smarttime.net>,
Brian Dunavant <bdunavant@s-c.org> wrote:
>I've searched all over, but couldn't find anything about it in the faqs,
>or anything on the web other than isqlperl which seems to have been
>written years ago for an older version. Any suggestions would be
>appreciated. I'm trying to find the solution before my deadline gets
>too close and I'm forced to do it in C. :)
Check out DBI.pm at http://www.perl.com/CPAN/CPAN.html.
-Bill
--
William Reardon wdr1@pobox.com
Hold fast to dreams, for if dreams die, life is a broken bird that cannot fly.
-Langston Hughes
------------------------------
Date: Thu, 27 Aug 1998 10:49:37 -0400
From: Russell Schulz <casfaq@locutus.ofB.ORG>
Subject: how to read Excel files (was Re: OLE Perl Excel)
Message-Id: <19980827.104937.0z1.rnr.w164w_-_@locutus.ofB.ORG>
brenda_lowe@my-dejanews.com writes:
> Hi, I too need to figure out how to examine Excel workbooks. Does
> anyone have any perl code they'd be willing to sent or post that shows
> how to get the number of worksheets, number of rows, columns, macros
The FAQ list for comp.apps.spreadsheets can be found on the Internet:
<ftp://rtfm.mit.edu/pub/usenet/comp.apps.spreadsheets/faq>
<http://www.faqs.org/faqs/spreadsheets/faq/>
7.2.4 Herbert, a free platform independent MS Excel to HTML convertress
10.6 How can I read Excel files without Excel?
13.7 Excel formats
--
Russell_Schulz@locutus.ofB.ORG Shad 86c
------------------------------
Date: 28 Aug 1998 03:04:49 GMT
From: Byron Brummer <zenin@bawdycaste.org>
Subject: Re: Misinterpreted => why no true/false keywords?
Message-Id: <904273351.65674@thrush.omix.com>
Mark-Jason Dominus <mjd@op.net> wrote:
: I'm on a campaign to wipe out `use constant'.
I like to pick useful battles myself.
: Here's why:
: use constant true => 1;
: loads in five files and 1,094 lines of code (!!!)
$ wc -l constant.pm Carp.pm vars.pm Exporter.pm strict.pm
163 constant.pm
176 Carp.pm
66 vars.pm
467 Exporter.pm
96 strict.pm
968 total
Just short of 1,094, but we're counting POD docs here too. Cut them
out and we're down to about 470, including whitespace, and pretty
sparse code.
Constant.pm is only one 21 line sub. Strict.pm, vars.pm, and
Carp.pm (and therefor Exporter.pm) you're *very* likely to be
pulling in anyway so including them is of little to no extra
expense.
Yes, it would be nice if constant.pm auto-included Carp (and
therefore Exporter), but considering how likely Carp and/or
Exporter is to be called anyway, to subvert it will only bloat
your code *more* because you then have both Exporter's code
PLUS your own import() method...
: and can be replaced with
: *true = sub () { 1 };
: which does exactly the same thing and is shorter to type anyway!
But isn't strict safe, at least not without help:
$ cat foo.pl
use strict;
*true = sub () { 1 };
if (1 == true) { print "ok" }
$ perl -wc foo.pl
Bareword "true" not allowed while "strict subs" in use at foo.pl line 3.
Unquoted string "true" may clash with future reserved word at foo.pl line 3.
foo.pl had compilation errors.
Cute... Sure, you can pull in "use subs;", but then you start blowing
away your "shorter to type" argument, it's harder to read, and your
on your way to "bloating" your code again.
Of course, if you gave up your obsession with obfuscating your code
with unneeded type globs and simple did:
sub true () { 1 };
You would get the same effect in an easier to read manner using
standard code that still passes strict without needing use subs.
Using advanced features only for the sake of using advanced
features is bad engineering. It's like saying, "Look how cool
I am because I know how to use feature X!". Vanity has no
place in engineering.
: So, the question you have to ask yourself: Is irrational glob fear
: worth the expense of 1,094x blowup in code size?
There is no fear of type globs, your 1,094 lines of code
argument is simply a crock, and your advice to subvert constant.pm
is flawed.
: You see, the campaign is really a campaign to educate people about how
: to use typeglobs.
Then pick a different method. Trying to get people to not use
an valid construct such as constant.pm for the sake of education
about globs is backwards thinking at best.
: Since there's only one way to use typeglobs, education doesn't take very
: long.
One way? It seems to me your type glob education needs a refresher
course.
: http://www.plover.com/~mjd/perl/TPC/Hardware-notes.html#Manual_Exporting
This page teaches some *extremely* bad habits and gives no warning
while doing so. Lets walk through a little bit of it:
>From the above page:
> package Foo;
> main::LOG("Your shoelace is bleeding!");
>
> That's a little ugly, and it's unnecessary. What you can do instead is
> import the LOG function into the modules where you want to use it. Doing
> that is a one-liner:
>
> package Foo;
> *LOG = \&main::LOG; # Import
> LOG("Look over there! A dancing cow!");
> # (Calls main::LOG)
And now Foo is highly non-reusable, requiring that the main program
supply the LOG() function instead of getting it from another
module like Foo::Log or such. Lovely...
Of course, if Foo was trying to get LOG() from someplace else, it
would have to use or require that other module, which would
negate your glob anyway as it will likely provide a method to
import it. Not to mention the fact that:
LOG "Look over there! A dancing cow!";
won't pass strict without use subs 'LOG'. Blagh...
> Simple! Convenient!
Non-reusable, Error Prone, and won't pass strict!
> Instead of using Exporter, consider doing this:
>
> package Foo;
>
> # Always export oo':
> sub import {
> # Get name of calling package
> my $caller = caller;
>
> *{$caller . '::foo'} = \&foo;
> }
And now "use Foo ()" still imports foo(), *DESPITE* my *EXPLICITLY*
asking that *NOTHING* be imported. Gee, thanks... :-(
You don't give a single note to the nieve reader that such a problem
exists and why it's a *bad* idea to use code such as the above.
> This bears careful study, because it's so useful and so simple.
No, this "bears careful study" because it's error prone, rude,
and extremely unexpected.
> Here's a great trick:
>snipped code<
> We created an anonymous hash, tied it, and exported the tied hash into the
> calling package. How do we use this?
>
> use Evaluator;
> print "6 * 7 + 5 = $eval{6 * 7 + 5}\n";
> # Prints `6 * 7 + 5 = 47''
You seem to like short code, so why not just do:
print "6 * 7 + 5 = @{[6 * 7 + 5]}\n";
It's even 1 char shorter.
>snip<
> Well, we could have the writer open the file in append mode, lock the file,
> then seek back to the beginning, overwrite the contents, and truncate the
> file?
Better do that with append and read (+>>) or seek(FH, 0, 0) won't
work the way you need it to.
> Blecch.
Or, we could learn to use open(2) flags and sysopen() correctly.
Hell, on many modern systems you can throw away your entire
lock code with a simple O_EXLOCK flag, which even works for DBM
libraries of any type without needing to manually access the
file descriptor.
--
-Zenin (zenin@archive.rhps.org) From The Blue Camel we learn:
BSD: A psychoactive drug, popular in the 80s, probably developed at UC
Berkeley or thereabouts. Similar in many ways to the prescription-only
medication called "System V", but infinitely more useful. (Or, at least,
more fun.) The full chemical name is "Berkeley Standard Distribution".
------------------------------
Date: Thu, 27 Aug 1998 23:59:35 -0400
From: rjk@coos.dartmouth.edu (Ronald J Kimball)
Subject: Re: newbie question
Message-Id: <1deg0qd.16y1tinps9q66N@bay2-134.quincy.ziplink.net>
Norman UNsoliciteds <No.unsoiliciteds@dead.end> wrote:
> In article <obg1eib8rz.fsf@alder.dev.tivoli.com>, "Jim Woodgate"
> <jdw@dev.tivoli.com> wrote:
>
> > I have perl5 running on an NT box, both perl -de 42 and perldoc -f
> > <your favorite command> work perfectly.
>
> great what do they mean? (remember I don't have unix man pages so advice
> like "grep man f(5)" isn't going to explain a lot :)
What do they have to do with unix manpages? perl -de 42 means run the
script '42' in the debugger, as documented in perlrun. perldoc -f
<command> means look up the documentation for a function, as explained
in perldoc's usage function and builtin help.
No unix manpages needed.
--
_ / ' _ / - aka - rjk@coos.dartmouth.edu
( /)//)//)(//)/( Ronald J Kimball chipmunk@m-net.arbornet.org
/ http://www.ziplink.net/~rjk/
"It's funny 'cause it's true ... and vice versa."
------------------------------
Date: Fri, 28 Aug 1998 02:01:39 GMT
From: Peter A Fein <p-fein@uchicago.edu>
Subject: Re: Perl compiler
Message-Id: <opgemu1n9to.fsf@harper.uchicago.edu>
stanley@skyking.OCE.ORST.EDU (John Stanley) writes:
>
> In article <opgr9y2dphv.fsf@harper.uchicago.edu>,
> Peter A Fein <p-fein@uchicago.edu> wrote:
> >stanley@skyking.OCE.ORST.EDU (John Stanley) writes:
> >What you could really use here is ssh.
>
> Sigh. No, what I really can't use here is ssh. If I could use ssh for
> any of the examples I presented, I would be using it already. Unfortunately,
> ssh requires 1) a network connection and 2) a server at the other end,
> neither of which is true in example 2 (tides), and the latter is not
> true for the other two examples.
I thought you were logging in to a server to grab log files. Oh well.
--
Peter A Fein Summering in SF!
Home: 650-571-6476 Work: 650-628-2172
p-fein@uchicago.edu pfein@us.checkpoint.com
Gilette's Razor: The best a man can get.
------------------------------
Date: Thu, 27 Aug 1998 19:36:32 -0700
From: Mee <mee@mine.com>
Subject: Re: Perl script compiling
Message-Id: <35E617B0.4E3E133B@mine.com>
Tom,
If it is any consolation, my post did not refer to you
(or any other Tom), but to the Perl manual.
I hope that you do not equate the two.
Mee
------------------------------
Date: Fri, 28 Aug 1998 02:36:25 GMT
From: mgjv@comdyn.com.au (Martien Verbruggen)
Subject: Re: question RE downloading webpages and parsing them.
Message-Id: <JIoF1.1787$LF.475512@nsw.nnrp.telstra.net>
In article <35E56AD7.6479EA8F@netjob.dk>,
Ernst Christensen <e.christensen@netjob.dk> writes:
> Hi
> If you for some reasons can't install the LWP module, you can use
> http-lib.pl
A few points:
- If you mail, as well as post, please state so in the body of the
message, so that the recipient knows that he/she is receiving a
copy.
- If you answer to a post, _especially_ if you are going to mail,
make sure you send it to the right person. If you need to followup
to an article, but you are really directing your comments to an
earlier poster, then _don't mail_, please. or if you _must_ mail,
make sure you mail to the right person. I never had problems
installing LWP, I even suggested it. I can't even begin to
understand how you could think that I would have trouble installing
it, after my suggestion.
Martien
--
Martien Verbruggen |
Webmaster www.tradingpost.com.au | "In a world without fences,
Commercial Dynamics Pty. Ltd. | who needs Gates?"
NSW, Australia |
------------------------------
Date: Fri, 28 Aug 1998 12:57:54 +1000
From: Benjamin Low <b.d.low@unsw.edu.au>
Subject: typeglobs and references... (re: Prog Perl, p 117)
Message-Id: <35E61CB2.A128ABDB@unsw.edu.au>
Is there any way of determining what a typeglob aliases to, when it is
used as a glob for a reference?
Prog Perl, 2nd ed. p117 has an example of a typeglob used to do "symbol
table aliasing":
(*a, *b) = func(\@c, \@d);
sub func
{
local (*e, *f) = @_;
# stuff done with @e and @f, (\@e, \@f) returned
}
In the example func assumes you're passing it refs to arrays, how can I
tell just what *e and *f "alias" to? (Say I want to different things
depending on whether you pass an array, scalar, etc). I note that I can
say
defined($e) && print "scalar ref";
defined(@e) && print "array ref"; # etc
is this the only/best way? Or is there some way of using the ref
operator to figure it out? ref(*e) doesn't seem to do anything.
--
Benjamin Low, BEng (Elec)
Communications Unit, University of New South Wales, Australia
(02) 9385 1138 b.d.low@unsw.edu.au b.d.low@ieee.org
------------------------------
Date: Fri, 28 Aug 1998 02:41:11 GMT
From: mgjv@comdyn.com.au (Martien Verbruggen)
Subject: Re: Unreadable Scripts?
Message-Id: <bNoF1.1788$LF.475512@nsw.nnrp.telstra.net>
In article <6s2ibf$967$1@wbnws01.ne.highway1.com>,
"Todd B" <NOTHANKStbeaulieu@mediaone.net> writes:
> actually, it could very well be a perl question -- to a beginner. what if
> perl could be compiled?
Then it is still a matter of file permissions. The poster wanted to
know how to stop people from reading his stuff. Not how to get a false
sense of security or obfuscation by having a 'compiled' program.
The discussion about why compilation doesn't provide that has been
here, has been beaten to death. If you want to read about it, read
perlfaq3, and use dejanews for past threads about this.
Martien
--
Martien Verbruggen |
Webmaster www.tradingpost.com.au | "In a world without fences,
Commercial Dynamics Pty. Ltd. | who needs Gates?"
NSW, Australia |
------------------------------
Date: Fri, 28 Aug 1998 02:43:28 GMT
From: mgjv@comdyn.com.au (Martien Verbruggen)
Subject: Re: Unreadable Scripts?
Message-Id: <kPoF1.1790$LF.475512@nsw.nnrp.telstra.net>
In article <6s2k1i$4el$1@camel25.mindspring.com>,
"David" <ceci@bway.net> writes:
> 1. But let's say that the person just chmod's it back to 755, or whatever?
> See that's the problem. There's probably no solution.
Only owner or root can do that. Not just any person.
> 2. What would happen if me and the other person had different logins, but
> both logins had the same home directory and could access the same files?
> Would 711 still make it so only I can read them?
711 means: read, write, execute to owner. execute to group members.
execute to anyone else.
This clearly means that only the owner of the file can read it. No one
else (except priveledged accounts, like root).
This STILL has nothing to do with perl. Please, take it to another
group.
Martien
--
Martien Verbruggen |
Webmaster www.tradingpost.com.au | "In a world without fences,
Commercial Dynamics Pty. Ltd. | who needs Gates?"
NSW, Australia |
------------------------------
Date: Thu, 27 Aug 1998 23:59:37 -0400
From: rjk@coos.dartmouth.edu (Ronald J Kimball)
Subject: Re: Unreadable Scripts?
Message-Id: <1deg1vz.16axshrbs1sxsN@bay2-134.quincy.ziplink.net>
Norman UNsoliciteds <No.unsoiliciteds@dead.end> wrote:
> Probably for the same reason other people are unable to skip postings
> without making some kind of
> ironic/sarcstic/caustic/pointless/uninformative/trivial
> staement
Whatever!
;-)
--
_ / ' _ / - aka - rjk@coos.dartmouth.edu
( /)//)//)(//)/( Ronald J Kimball chipmunk@m-net.arbornet.org
/ http://www.ziplink.net/~rjk/
"It's funny 'cause it's true ... and vice versa."
------------------------------
Date: Fri, 28 Aug 1998 12:10:11 +1000
From: Benjamin Low <b.d.low@unsw.edu.au>
Subject: use vars and my, have I got it right?
Message-Id: <35E61183.E61D0F17@unsw.edu.au>
I'm trying to fully understand the point/use of the use vars pragma and
the my statement. This is what I understand them to be:
use vars predeclares the quoted "strings literals" as global variables,
visible from all modules, etc. It doesn't actually create these
variables (this fits in with my concept of 'use' being a compiler
directive). i.e. it's a compile-time thing (a bit like extern in C?).
my is pretty much the same, except its scope is only to the enclosing
block, etc. and it *does* create the variable/s. i.e. it's a
compile-time declaration and run-time creation thing.
--
Benjamin Low, BEng (Elec)
Communications Unit, University of New South Wales, Australia
(02) 9385 1138 b.d.low@unsw.edu.au b.d.low@ieee.org
------------------------------
Date: Thu, 27 Aug 1998 19:02:21 -0700
From: fremont@ix.netcom.com
Subject: Why do these two differ?
Message-Id: <35E60FAD.2249@ix.netcom.com>
Why do the following scripts differ?
One prints 6 and the other prints 7.
I have perl version 5.004 on Linux.
#!/usr/bin/perl
$length = (0,1,2,3,4,5,6);
print $length ."\n";
#!/usr/bin/perl
@array = (0,1,2,3,4,5,6);
$length = @array;
print $length ."\n";
Ayoub
------------------------------
Date: 28 Aug 1998 02:40:47 GMT
From: Dan Nguyen <nguyend7@msu.edu>
Subject: Re: Why do these two differ?
Message-Id: <6s55bf$qid$1@msunews.cl.msu.edu>
fremont@ix.netcom.com wrote:
: Why do the following scripts differ?
: One prints 6 and the other prints 7.
: I have perl version 5.004 on Linux.
: #!/usr/bin/perl
: $length = (0,1,2,3,4,5,6);
: print $length ."\n";
it prints 6 because it grabs the last scalar value
try $length = scalar (0,1,2,3,4,5,6);
: #!/usr/bin/perl
: @array = (0,1,2,3,4,5,6);
: $length = @array;
: print $length ."\n";
It actually gets the size;
: Ayoub
--
Dan Nguyen | There is only one happiness in
nguyend7@msu.edu | life, to love and be loved.
http://www.cse.msu.edu/~nguyend7 | -George Sand
------------------------------
Date: Thu, 27 Aug 1998 20:44:04 -0600
From: "Steven L. Reid" <goldfinger69@geocities.com>
Subject: Re: Why do these two differ?
Message-Id: <_OoF1.30$k71.281213@news01a.micron.net>
fremont@ix.netcom.com wrote in message
>Why do the following scripts differ?
>One prints 6 and the other prints 7.
>$length = (0,1,2,3,4,5,6);
>print $length ."\n";
Setting a scalar to a list causes the scaler to be set the last element in
the list (in this case 6). If you change the 6 to, say, 'a', it would print
'a'.
>@array = (0,1,2,3,4,5,6);
>$length = @array;
>print $length ."\n";
Here, interpreting a list in a scalar context causes it to return its size
(in this case 7). This is the same as setting:
$length = $#length+1;
Steven
goldfinger69@geocities.com
------------------------------
Date: Thu, 27 Aug 1998 23:59:40 -0400
From: rjk@coos.dartmouth.edu (Ronald J Kimball)
Subject: Re: Why do these two differ?
Message-Id: <1deg1ye.p15xf319usajiN@bay2-134.quincy.ziplink.net>
<fremont@ix.netcom.com> wrote:
> Why do the following scripts differ?
> One prints 6 and the other prints 7.
> I have perl version 5.004 on Linux.
>
> #!/usr/bin/perl
> $length = (0,1,2,3,4,5,6);
> print $length ."\n";
This one demonstrates use of the comma operator in a scalar context -
because you are assigning to a scalar. In a scalar context, comma
evaluates the left-hand expression, discards the result, and then
returns the result of evaluating the right-hand expression. So, in a
scalar context, (0,1,2,3,4,5,6) gives you a value of 6.
> #!/usr/bin/perl
> @array = (0,1,2,3,4,5,6);
> $length = @array;
> print $length ."\n";
This one demonstrates use of the comma operator in a list context -
because you are assigning to an array. In a list context, comma
separates elements of a list. So, in a list context, (0,1,2,3,4,5,6)
gives you that list.
This one also demonstrates use of a named array in a scalar context -
because you are assigning @array to $length. In a scalar context, a
named array returns the number of elements in the array. @array
contains the list (0,1,2,3,4,5,6), which is 7 elements.
For more on contexts in Perl, refer to the perldata documentation.
--
_ / ' _ / - aka - rjk@coos.dartmouth.edu
( /)//)//)(//)/( Ronald J Kimball chipmunk@m-net.arbornet.org
/ http://www.ziplink.net/~rjk/
"It's funny 'cause it's true ... and vice versa."
------------------------------
Date: Thu, 27 Aug 1998 19:31:48 -0700
From: Mee <mee@mine.com>
Subject: Re: Y2K Date Support
Message-Id: <35E61694.402CFDA@mine.com>
Craig,
Let me reiterate:
ANYTHING (including, forgive me the blasphemy, Perl) saying
"the YEAR is 0" when referring to a year which is not "the YEAR 0"
is bound to mess up something sooner or later.
Because:
Such reference is not unambiguosly defined (as in absolute or static)
but is subject to some arbitrary (ie: potentially subject to change)
rules or interpretations, depending on either the context, some other
rules, conventions, habits, etc.
I believe you understand me now, but for the sake of some other snots
who have joined the thread:
The only true and Y2K safe answer is the actual year (eg. 1998).
Anyone disagreeing, warm up the chair and disprove that nuclear energy
is safe as much as Perl is Y2K compliant.
Mee
------------------------------
Date: 28 Aug 1998 03:54:34 GMT
From: cberry@cinenet.net (Craig Berry)
Subject: Re: Y2K Date Support
Message-Id: <6s59lr$1kf$1@marina.cinenet.net>
Mee (mee@mine.com) wrote:
: Let me reiterate:
: ANYTHING (including, forgive me the blasphemy, Perl) saying
: "the YEAR is 0" when referring to a year which is not "the YEAR 0"
: is bound to mess up something sooner or later.
The year 0 in what calendar? Roman? Hebrew? Thelemic? Chinese? In
effect, and for sufficient reasons, localtime (Unix/C/Perl lineage) uses a
special calendar, identical to the common civil calendar in almost all
respects [1] other than that is counts the year 0 as being what the civil
calendar calls 1900.
This calendar is no better or worse, intrinsically, than any other. It's
certainly equally 'valid', in terms of assigning unique year/month/day
values to every day. It's also trivial to covert back and forth between
the two calendars, by adding or subtracting 1900 from the year as needed.
: Because:
: Such reference is not unambiguosly defined (as in absolute or static)
: but is subject to some arbitrary (ie: potentially subject to change)
: rules or interpretations, depending on either the context, some other
: rules, conventions, habits, etc.
Are you aware that the civil calendar is equally constructed, equally
arbitrary? As a result of sloppy math and historical research by Dennis
the Little, our calendar has no year zero, and also commences four to
seven years after the event it claims as its basis. Time has no labels,
no external absolutes against which we can measure its passage. It has
sloppy cycles, none evenly divisible by any of the others, all drifting
slowly in length over the millenia; anything calendar we develop that is
regular and predictable and founded on integers is *by definition* a
product of our minds, not of nature. In other words, all time values
beyond physical observations ("The sun just culminated at altitude 34.08
degrees," or "The moon is rising over the heel stone", or "This cesium
atom has oscillated 30 billion times since we began monitoring it") are
"arbitrary [and] potentially subject to change." "Conventions and habits"
are *all we have!*
: I believe you understand me now, but for the sake of some other snots
Did somebody put 'ad hominem attack powder' in the clpm water supply? The
tone of debate is declining precipitously this week. :(
: who have joined the thread:
: The only true and Y2K safe answer is the actual year (eg. 1998).
I hope I've shown you that your concept of 'actual year' needs further
contemplation.
: Anyone disagreeing, warm up the chair and disprove that nuclear energy
: is safe as much as Perl is Y2K compliant.
Nuclear energy, harnessed properly, is as safe a technology as we've ever
had for power production. Perl's time functions, used properly, are as
y2k-safe a programming tool as exists in the software industry. Either,
misused, can create disasters (though software has a pleasant tendency not
to depopulate thousands of square miles when it fails...usually). So it
seems to me that the contrary to your assertion is true (to the limited
extent I understand what you're driving at with this bit of rhetoric).
[1] The leapyear rule as usually formulated works on 'localtime year' +
1900 (or plus 300, if you extend the Gregorian calendar backward that
far), rather than on raw 'localtime year' values. Another trivial
difference is that localtime month indices start with January as 0, as
opposed to the civil calendar convention of January being 1.
---------------------------------------------------------------------
| Craig Berry - cberry@cinenet.net
--*-- Home Page: http://www.cinenet.net/users/cberry/home.html
| "Ripple in still water, when there is no pebble tossed,
nor wind to blow..."
------------------------------
Date: 12 Jul 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 Mar 98)
Message-Id: <null>
Administrivia:
Special notice: in a few days, the new group comp.lang.perl.moderated
should be formed. I would rather not support two different groups, and I
know of no other plans to create a digested moderated group. This leaves
me with two options: 1) keep on with this group 2) change to the
moderated one.
If you have opinions on this, send them to
perl-users-request@ruby.oce.orst.edu.
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 3570
**************************************
