[8908] in Perl-Users-Digest
Perl-Users Digest, Issue: 2525 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu May 7 06:07:33 1998
Date: Thu, 7 May 98 03:00:33 -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, 7 May 1998 Volume: 8 Number: 2525
Today's topics:
Re: "if" statement help <rootbeer@teleport.com>
Re: "if" statement help (Martien Verbruggen)
Re: Bad free() ignored -- latest Perl not an option <andy@wonderworks.co.uk>
Re: Capturing Command Line Output (Tina Marie Holmboe)
Re: CPAN & Module gripes (was Re: Ever Wonder...?) (Steffen Beyer)
Re: Directory usage in Perl for win32 <davidc@selectst.com>
Re: Ever Wonder Why Not Everyone Uses Modules? <zenin@archive.rhps.org>
Re: Ever Wonder Why Not Everyone Uses Modules? <zenin@archive.rhps.org>
Re: Ever Wonder Why Not Everyone Uses Modules? <zenin@archive.rhps.org>
Re: Ever Wonder Why Not Everyone Uses Modules? <zenin@archive.rhps.org>
Re: Ever Wonder Why Not Everyone Uses Modules? (Steffen Beyer)
Re: GetOpts::Std and use strict (Johan Vromans)
How to export constants in modules without C code <enaiman@ndsisrael.com>
how to pass argument? <ksiero@sgh.waw.pl>
Re: how to pass argument? kzal@pol.pl
Re: How to send email (was Re: Ever Wonder Why Not Ever <zenin@archive.rhps.org>
How to truncate a float value? <marz@tamu.edu>
Re: How to truncate a float value? <Tony.Curtis+usenet@vcpc.univie.ac.at>
Re: Huge array/Win32::NetAdmin::GetUsers <david.richards@alderley.zeneca.com>
Re: IS THIS POSSIBE IN PERL! (Tina Marie Holmboe)
OLE and Perl (Steve)
Re: print($b=1,$b=2) <horst.fickenscher@it.erlm.siemens.de>
Problem with xemacs and perl syntax hilitghtning (Gerd Schering)
Re: recursive file renaming (Shawn )
Re: settime <qdtcall@esb.ericsson.se>
Re: What it perl? (Jobst Schmalenbach)
Digest Administrivia (Last modified: 8 Mar 97) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 07 May 1998 07:01:23 GMT
From: Tom Phoenix <rootbeer@teleport.com>
To: Reginald Johnson <johns_r@cs.odu.edu>
Subject: Re: "if" statement help
Message-Id: <Pine.GSO.3.96.980506235903.6329V-100000@user2.teleport.com>
On Wed, 6 May 1998, Reginald Johnson wrote:
> if(@row[3]=='intel')
If you ask perl to warn you about suspicious things in your code, it will
suggest that you not write that line like that, for more than one reason.
See the -w invocation option in the perlrun manpage. Hope this helps!
--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/
------------------------------
Date: 7 May 1998 07:00:25 GMT
From: mgjv@comdyn.com.au (Martien Verbruggen)
Subject: Re: "if" statement help
Message-Id: <6irm69$j1s$1@comdyn.comdyn.com.au>
In article <Pine.GSO.3.96.980506223258.10502A-100000@wave.cs.odu.edu>,
Reginald Johnson <johns_r@cs.odu.edu> writes:
> if(@row[3]=='intel')
Did you mean $row[3]? And did you mean to use eq?
if ($row[3] eq 'intel')
Martien
--
Martien Verbruggen |
Webmaster www.tradingpost.com.au |
Commercial Dynamics Pty. Ltd. | Curiouser and curiouser, said Alice.
NSW, Australia |
------------------------------
Date: Wed, 6 May 1998 22:54:25 +0100
From: Andy Armstrong <andy@wonderworks.co.uk>
Subject: Re: Bad free() ignored -- latest Perl not an option
Message-Id: <FZli$bARwNU1Ewcf@wndrwrks.demon.co.uk>
In article <6iqkmb$fo5$1@ns1.arlut.utexas.edu>, Stuart McDow
<smcdow@arlut.utexas.edu> writes
>The evidence points to a broken ISP. It should probably be replaced.
Thanks :-) If it was an option I'd have done it already.
--
** Don't CC any follow-ups to me - I *do* read the newsgroups I post to **
Andy Armstrong, Wonderworks, http://www.wonderworks.co.uk
------------------------------
Date: 7 May 1998 09:41:05 GMT
From: tina@scandinaviaonline.se (Tina Marie Holmboe)
Subject: Re: Capturing Command Line Output
Message-Id: <6irvjh$jjs$4@news1.sol.no>
In article <35501A10.73EE@geocities.com>,
Luckys <luckys@geocities.com> writes:
> However, I'm at a lose as how to capture output from a command line
> response.
This rings a bell... and backticks is the reply I get. I see that you've
tried to use qx// - the slightly more meta'ed version of ``. Here is what
I'd use to fetch the output from for instance nslookup:
my($lookup) = join('', `nslookup hostname`) ;
which leaves me with a string - $lookup - containing the STDOUT from the
process nslookup.
Was this what you were looking for ?
(Caveat: I've not taken into account the path to the program here, nor any
error messages in $!, etc, etc, etc. Such things are left as an
exercise for the reader :)
--
Tina Marie Holmboe
Application Developer (Geeks'R'Us) [tina@tech.scandinaviaonline.se]
Scandinavia Online AB Development Dept. (+46) 08 587 81000 (switchboard)
(+46) 08 587 81189 (direct)
------------------------------
Date: 6 May 1998 13:34:13 GMT
From: sb@engelschall.com (Steffen Beyer)
Subject: Re: CPAN & Module gripes (was Re: Ever Wonder...?)
Message-Id: <6iposl$5em$1@en1.engelschall.com>
Chris Nandor <pudge@pobox.com> wrote:
> In article <6ilbgt$t1p@fridge.shore.net>,
Art Cohen <upsetter@shore.net> wrote:
> # Chris Nandor <pudge@pobox.com> wrote:
> # : Since when can clueless newbies be expected to understand useful resources?
> #
> # Maybe because of the volumes of replies on this newsgroup that simply say
> # "There's a module that does that available on CPAN".
> If they are clueless newbies, they wouldn't understand how to use it
> anyway. They need to get baptized by a little fire before they can use it
> anyway. Navigating CPAN is a good way to do it.
This arrogance is infuriating.
We all started as clueless newbies (myself included). Now I'm a Perl module
author, too, a relatively clueful, I think.
Nevertheless I don't think we should make it harder for newbies to access
CPAN, or not improve CPAN when we see deficiencies, by saying, these
deficiencies or difficulties are good to separate the Real Programmers from
the clueless.
Now I see that people who have been complaining about elitarism in c.l.p.misc
have been right, here it is, in its full ugliness.
> # : You say above that clueless newbies should be able to figure it out. Why
> # : on earth should clueless newbies be able to do this? CPAN is made by
> # : programmers for programmers. If you are not a programmer, you won't get
> # : it, and naught a user here will shed a tear.
> #
> # This is idiotic. It is not valid to assume that "newbie != programmer".
> Where did I say it did? I specifically said "clueless newbie", and while
> I did not say it before, I will say it now: a clueless newbie is not a
> programmer.
Well, even a Real Programmer once was a clueless newbie.
We should help clueless newbies to become clueful programmers AS FAST AS
POSSIBLE, instead of throwing sticks into their spokes.
After all, this is what FAQs are written for, for example.
(I don't want to get into the discussion about people not reading the FAQ,
though, since "stubbornly clueless" people are a wholly different matter.)
Maybe we should indeed rethink this material (FAQs and all) when we find
out (as we seem to be doing right now) that this material is insufficient
or too overwhelming.
I personally think that the latter is the case: There is so much information
available that someone who just starts using Perl doesn't know where to start
reading. So we should keep that in mind and adapt all material accordingly,
as good as we can.
So if people complain about insufficient information concerning CPAN module
interdependencies, I think we should take them seriously.
(Because there is obviously more than one who has run into these problems.)
The question, IMO, is: HOW can we improve existing documentation to reduce
this problem?
And NOT: Are the people complaining just assholes or not?
That doesn't help anyone.
Ok. So far, so good.
So what can we do?
People said module authors should better document dependencies. Ok, let's
add this to our "to do" list as point #1.
What else can we do?
Maybe we could develop a CPAN-Mini-FAQ "How do I find, evaluate, select,
download and install modules from CPAN" or something, similar to the mini-FAQ
that came into existence lately.
I think this (posted regularly) could be helpful because answers in this
newsgroup could continue to point "newbies" to CPAN - maybe adding "see the
CPAN FAQ in this newsgroup for instructions if you're unfamiliar with CPAN".
Ok, what else?
Could we improve (if possible: automatic) detection of dependencies even for
people behind extremely restrictive firewalls?
What about changing MakeMaker in such a way so that module authors would just
add a line like
DEPENDENCIES => qw(Data::Dumper Bundle::LWP),
to the "Makefile.PL" of their module (and MakeMaker would possibly handle
the rest automatically - or at least print out a list of required but not
yet installed modules)?
Anyone some more ideas?
Best regards,
--
Steffen Beyer <sb@engelschall.com>
Free Perl and C Software for Download: www.engelschall.com/u/sb/download/
------------------------------
Date: Thu, 07 May 1998 18:19:10 +1000
From: David Coldrick <davidc@selectst.com>
To: Martien Verbruggen <mgjv@comdyn.com.au>
Subject: Re: Directory usage in Perl for win32
Message-Id: <35516E7E.3F39B2F4@selectst.com>
Martien Verbruggen wrote:
> In article <354E72F7.9B719F19@selectst.com>,
> David Coldrick <davidc@selectst.com> writes:
>
> You're reinventing the wheel. File::Find does a better job at this,
> does it platform independently and it comes with perl.
>
Didn't know about File::Find - works a treat. Thanks.
> But OK, if you insist:
>
> > use English;
> >
> > my $pathsep = "\\";
>
> Why not just '/'?
>
Um, because the path separator on Windows NT is '\' - to be honest, I'm
often confused as to when I have to add another backwhack, even with single
quotes, so I err on the side of caution. Sloppy, but I'll probably get over
it.
> > sub lookin {
> > my ($dir, $function_ref) = @ARG;
> >
> > opendir DIR, $dir or die "Can't open $dir: $OS_ERROR\n";
> > my @files = readdir DIR;
> >
> > foreach $f (@files) {
> > next if ($f eq '.' or $f eq '..'); # ignore the DOS weirdness
>
> Weirdness? DOS?
Yeah, tell me about it. What's really cute is that the version I was using
when I wrote this (ActiveState/Ware), found the '.' and '..' to be
directories, and the recursion on them went infinite. I haven't tried the GS
port to see what happens there.
>
>
> You could have done that with a grep on the readdir line, as has been
> suggested often on this newsgroup, and is even suggested in the
> documentation for readdir:
Yep, I could have - but the "next if . . ." looks clearer to me, probably
from lack of grep exercise - YMMV.
> # perldoc -f readdir
>
> And it really doesn't answer the original question, does it?
Blush. Sure nuff. I realised that after I posted it, but thought the code
was clear enough to be easily changed to do what the original poster wanted
:-)
>
>
> Martien
> --
> Martien Verbruggen |
> Webmaster www.tradingpost.com.au | For heaven's sake, don't TRY to be
> Commercial Dynamics Pty. Ltd. | cynical. It's perfectly easy to be
> NSW, Australia | cynical.
Regards,
David
------------------------------
Date: 7 May 1998 08:52:36 GMT
From: Zenin <zenin@archive.rhps.org>
Subject: Re: Ever Wonder Why Not Everyone Uses Modules?
Message-Id: <894531613.87925@thrush.omix.com>
Matthew Cravit <mcravit+usenet@mcravit.vip.best.com> wrote:
: In article <894365105.733593@thrush.omix.com>, Zenin <zenin@archive.rhps.org> wrote:
: > On the other hand, I'd guess that easily 1/5 of the Unix systems
: > I've worked worked with had nothing listing on port 25. Even if
: > you have access to another SNTP server (smell a vary non-portable
: > code change here to point to it? I do!) it might not be up when you
: > try to send your mail (intermittent connections never happen,
:
: Sure...but when you send mail, you're not necessarily connecting to a
: local mail server anyway...if I want to send mail to user@aol.com, I'd
: be just as likely to connect to aol.com's mail server as to my own.
You obviously have no idea how mail systems work.
To be even remotely reliable, an application tring to send mail to
user@aol.com should **NEVER** try to make the connection itself to
aol.com unless your application happens to be an MTA such as
sendmail. Never. It's not your application's job to know how to
route mail, nore in less then many years' time could you write an
application that had even a slight chance of handling mail routing
as correctly and reliably as sendmail. You'd also be reinventing
a *vary* large and complex wheel.
: > So, by using SNTP directly you build code that's *extremely*
: > NON-portable between many, many common Unix servers as well
: > as being vary unstable (no queuing system available), just to
:
: Sure there is...you're just talking to someone else's sendmail daemon (or
: whatever) instead of to your own. Talking the SMTP protocol is very portable
: if you have an SMTP server to talk to. If you don't, you're probably going to
: have a hard time anyway.
That's the point. At the *exact* time you're trying to send this
mail the SMTP server must be up and available. You also have to
*hard code* it's address into your application. And guess what? You
do NOT need to EVER connect to ANY SMTP server to deliver mail. If
you're local host happens to be configured to route mail by other
meens you've just blown away it's ability to help you in any way.
And if you are using SMTP, and it happens to be down or not
available for whatever reason, I ask you again, ARE YOU PREPARED
TO HANDLE THE MAIL QUEUING FOR IT???
: But how's talking directly to sendmail portable if you need to RUN THE PERL
: SCRIPT on machines that aren't UNIX? I have a number of scripts that RUN on
: NT, MacOS and UNIX. Only one of those three has sendmail available in /usr/lib
: or /usr/sbin, and only one (or possibly two) even have sendmail at all.
If you've got broken systems like MacOS, NT et al to deal with then
your code needs an if/else block to detect them and thus use the
much less portable and reliable SMTP or whatever methods to deliver
it.
Why throw all chance of reliability and portability out the window
for Unix systems just to avoid an if/else statement for the lesser
systems? NT and MacOS are expected to be unreliable, Unix is not.
Please don't ruin this correct perception of Unix for the sake of
lesser systems when it takes a whooping 5 minutes of work to avoid
it.
: The advantage, to my mind, of the Net::SMTP module, is that your Perl script
: is portable to machines on which sendmail might be:
: - Non-existant
Name a single flavor of Unix that does not include sendmail.
: - In a non-standard location
Name a single flavor of Unix that doesn't have sendmail in either
/usr/sbin or /usr/lib.
Even if it did, modifying your code to point to the odd location is
no more a problem then you'd have with hard coding an SMTP address
in your application, and you'd still get the full power of
sendmail's reliability over the much weeker SMTP system.
: - Buggy
Calling SMTP directly could *never* be done with less reliability
then calling sendmail.
: - Improperly configured
Just as easy to have a mis-configured SMTP server.
: There's a distinction here that I think you're not making, between the process
: which actually delivers your mail, and the method you use of talking to it.
There's a distinction here that I think you're not making, between
exactly who's job it is to route mail. Hint: It's *not* your
application's job!
: If you open a pipe to sendmail, your script is tied to sendmail, and assumes
: that you have a copy of sendmail on the machine your script is running on.
Yep. And if you're on any working and properly configured Unix system
this is a vary reliable given.
: If you use a module like Net::SMTP, you can talk to any SMTP mail server,
: whether it's on your local machine or not, and whether it's sendmail or not.
True. But this assumes *much* more then a working sendmail. You're
assuming there even IS an SMTP server to talk to. You're assuming
it's up at the time *you* want to talk to it. You're assuming your
connection to it is up at the time *you* want to talk to it. You're
assuming you even need to leave your local machine to deliver the
mail.
If there is no SMTP server? Guess what, you're talking to sendmail
again.
If the SMTP server is down at the time you want to send mail? Guess
what, you'll *have* to talk to sendmail if you want it qued for
later.
If the connection to the SMTP server is down at the time you want
to send mail? Guess what, you'll *have* to talk to sendmail if you
want it qued for later.
Unless you're assuming it's easy to write a mail que daemon to
deliver qued mail?
What if the mail is local? Why talk to an unreliable, remote
SMTP server if the mail is for the local host? Not that it's
any of your business to make this distinction.
: But when you connect to a mail server with Net::SMTP, that server will
: queue the messages for you.
IFF THE SERVER AND NETWORK ARE UP AND RUNNING! If for any reason
this is not the case, your SOL if you use SMTP!
: You're using the phrase "cross-platform" in a different way than some of
: the other posters in this thread, I think. There's a difference between
: "portable to 37 varieties of UNIX", and "portable to platforms besides
: UNIX". I have scripts which I've written for work which (not by my choice)
: HAVE to be able to run on MacOS, WinNT, SunOS 4.1.[1234], and Solaris
: 2.(5|5\.1|6). Opening a pipe to sendmail is NOT an option for those scripts.
Use an if/else switch. Don't throw away all the years of builtin
reliability and redundancy of sendmail to avoid an if/else block
needed by lesser systems.
if ($unix) {
reliable_sendmail ($mail);
} else {
unreliable_smtp ($mail);
}
To not do so is simply being lazy and incompetent. -I say
incompetent because you chose to ignore the facts and implement
code in a globally unreliable method when at most it only needs
to function in such a weak method on two systems which can be
easily handled with an if/else switch. We're talking about 5
minutes of extra work here *at most* to make your mailing system
lightyears more reliable on the platforms that it can be.
Not to mention that a few companies sell versions of sendmail for
NT/95 and probably Mac...
--
-Zenin
zenin@archive.rhps.org
------------------------------
Date: 7 May 1998 09:30:01 GMT
From: Zenin <zenin@archive.rhps.org>
Subject: Re: Ever Wonder Why Not Everyone Uses Modules?
Message-Id: <894533858.685075@thrush.omix.com>
Matthias Neeracher <neeri@iis.ee.ethz.ch> wrote:
: So "simply" opening a pipe to /usr/lib/sendmail is already a problem, because
: sendmail might be in /usr/sbin. Of course, it's not hard to test where it
: is, but the presence of a sendmail binary does not prove that the system is
: set up correctly to deliver mail.
Simply the presence of an SMTP server listing on a machine somewere
does not prove that it's set up correctly.
: You're operating under the mistaken assumption that Net::SMTP simply connects
: to port 25 on localhost.
Anything else needs to hard code the SMTP server's address. -And
no, Net::Config is *not* a reliable meens to know this information.
NT people, raise your hand if you compiled own copy of libnet
instead of using a prebuilt package. Sorry to hear that. Your
Net::Config will likely be completely wrong.
: That's most likely because your knowledge of Net::Config is similar to your
: knowledge of network protocols (or spelling, for that matter).
Raise your hand if you or more likely your sysadmin would
even remotely think about recompiling libnet whenever your
mail/news/pop3/etc server gets moved to another machine. Hmm, not
to many hands went up.
NT people, raise your hand if you compiled own copy of libnet
instead of using a prebuilt package. Sorry to hear that. Your
Net::Config will likely be completely wrong.
Raise your hand if you or more likely your sysadmin wouldn't
think twice about needing to change your MTA config/global
NNTPSERVER env var/etc if your server gets moved to another machine.
Hey, that's just about all of you!
I love the last remark. "If we can't get him on facts, let's bad
mouth his spelling!"... Whatever...
: You are right that there are tradeoffs involved: With Net::SMTP you get to
: pick your mail server of choice,
Same with sendmail. If the local MTA is setup to send all outgoing
mail to a central server, that's where it will go even if has the
ability to do the routing directly. However, you gain the advantage
of the fact that the local MTA/sendmail is much, much more likely to
know what the preferred delivery system is on that particular
system then you, period.
Once again, you guys are completely forgetting the *fact* that it is
*not* your application's job to either know, care, or affect how
mail gets delivered. To try and take over the job of the local
MTA is a losing and useless battle.
: get more immediate feedback about errors that occur,
Nothing more or less then sendmail. Name even one case where
SMTP would give you a response to an error that sendmail would
not.
: but may have to face complex fallback strategies if the network between
: you and your server fails.
Or if the SMTP server isn't running, or if the system you're
deploying your application on doesn't even use an SMTP server at all.
: With sendmail, you are at the mercy of the sendmail
: setup on the local host (sendmail never gets misconfigured, right?), but if
: that setup is correct, you get best efforts delivery.
With SMTP you're at the mercy of it being setup correctly (Mail
servers never get mis-configured, right?).
: Neither method is very reliable for longer term network failures, unless your
: script greps your mailbox for bounce messages.
If this is a common problem, the local MTA can *easily* be
configured to extend the timeout accordingly. Once again, this is
a job for the MTA, not your application.
: > So, by using SNTP directly you build code that's *extremely*
: > NON-portable between many, many common Unix servers
:
: Nonsense.
You're completely ignoring vary, vary simple facts.
: > Of the 30+ NT machines in my company, I don't
: > think there is a single one that is running an SNTP server.
:
: Irrelevant. Net::SMTP doesn't send to localhost.
Anything else is even more unreliable and non-portable.
: The percentage of hosts capable of talking SMTP far exceeds the percentage of
: hosts running a correctly configured sendmail.
Iff the SMTP is running, available, configured correctly, and has
a known address.
: Hmm. Somebody complains about not being able to easily install a module which
: is release quality and available on CPAN. You respond by recommending a
: module in alpha testing not available on CPAN.
Fine, don't install it. Take a look at the code handling needed to
safely talk to sendmail and catch errors correctly and then go
rewrite it into your application without using the module.
--
-Zenin
zenin@archive.rhps.org
------------------------------
Date: 7 May 1998 09:44:29 GMT
From: Zenin <zenin@archive.rhps.org>
Subject: Re: Ever Wonder Why Not Everyone Uses Modules?
Message-Id: <894534725.890631@thrush.omix.com>
Art Cohen <upsetter@shore.net> wrote:
: I'm the original poster to this thread (not the one who said he didn't need LWP) and
: I have no intention of re-writing Perl from scratch (or anything else). However, I
: sure as hell won't spend an hour or two trying to learn how to use some module if I
: can write the code to accomplish the task myself in ten minutes. That was my
: original point.
The point you're forgetting is that while you may well be able to
reinvent said wheel in ten minutes, without even looking at the
(more oftin then not vary well tested code) in the module you're
inviting many bugs that you haven't thought of and that others
have already found and fixed.
Reuse isn't just to be lazy, it's to minimize bugs. If a bug is
found in LWP and fixed, all code that uses it is fixed. If your
rewrite of it's same functionality has the same bug, you will
have to manually fix it in every place you used it.
--
-Zenin
zenin@archive.rhps.org
------------------------------
Date: 7 May 1998 09:50:48 GMT
From: Zenin <zenin@archive.rhps.org>
Subject: Re: Ever Wonder Why Not Everyone Uses Modules?
Message-Id: <894535105.298658@thrush.omix.com>
Art Cohen <upsetter@shore.net> wrote:
: Oh, sure, if everybody used Unix for everything there'd be no problem, but
: one of the advantages of Perl is that it's supposed to be cross-platform.
<slant>
But first you have to consider DOS to be a real platform.
</slant>
:-)
Seriously, one can't really expect a language that is meant to have
the full power of modern operating systems to be fully compatible
with an outdated and unsupported OS with less power and ability
then most any current console gaming machine.
If I was stuck on such systems, I'd be thankful that people are even
trying to make perl run on it in any form.
--
-Zenin
zenin@archive.rhps.org
------------------------------
Date: 6 May 1998 12:47:14 GMT
From: sb@engelschall.com (Steffen Beyer)
Subject: Re: Ever Wonder Why Not Everyone Uses Modules?
Message-Id: <6ipm4i$ts$1@en1.engelschall.com>
Art Cohen <upsetter@shore.net> wrote:
> I'm trying to use Net::SMTP, as most of the gurus on this group recommend
> it over piping commands to sendmail directly.
> Since I don't have root access, I'm trying to install a local copy in the
> directory where I'm writing my perl scripts.
> My first try failed because it didn't install a module called
> "Net::Config". There doesn't appear to be any mention of it in the
> by-modules/Net directory of CPAN, so maybe it's generated by the install
> process, but it's not being installed in my case.
> I delete everything and try to intstall again. I notice an error message
> telling me that I need "Data::Dumper" to be installed. So I ftp back to
> CPAN and download Data::Dumper.
> As I try to install Data::Dumper, I get this message:
> gcc: installation problem, cannot exec `cpp': No such file or directory
> *** Error code 1
> make: Fatal error: Command failed for target `Dumper.o'
> I've now been working on this for an hour and I still can't run a two-line
> test script. If I were actually working on something that needed to be
> finished any time soon, I would have abandoned this approach about a half
> an hour ago and just written the code to communicate with sendmail.
> Is it any wonder why a lot of perl developers don't use pre-written
> modules? Modules are *supposed* to make it easier to accomplish certain
> tasks without getting bogged down in the minutiae of your operating system
> but in this case, it's exactly the opposite. Whereas I could have written
> the "raw" perl code to accomplish the task at hand in about five minutes,
> I've now spent an hour fruitlessly trying to install a module that's
> supposed to make my life easier.
> End of rant.
I think all of us who develop Perl modules should take this critique
seriously.
I learn from this that any module should CLEARLY name at some PROMINENT
place ALL dependencies, such as other modules that are required, or
wether a compiler will be needed or not (and which Perl version is
required, if it makes any difference).
Obviously the mere mention "Prerequisites - what else you may need to have."
in section "2.7 README and other Additional Files." of chapter "2) Guidelines
for Module Creation" in "The Perl 5 Module List"
(http://www.perl.com/CPAN/modules/00modlist.long.html)
is not enough.
Maybe the maintainers of the Perl 5 Module List should change this to a
more explicit incitation to name all dependencies, especially other modules
that will be needed?
I personally think that modules from the CORE of the Perl distribution
do not need to be explicitly mentioned, though.
Anybody any comments or additional ideas?
Best regards,
--
Steffen Beyer <sb@engelschall.com>
Free Perl and C Software for Download: www.engelschall.com/u/sb/download/
------------------------------
Date: 07 May 1998 10:43:28 +0200
From: JVromans@Squirrel.nl (Johan Vromans)
Subject: Re: GetOpts::Std and use strict
Message-Id: <wl3iunitqrz.fsf@plume.nl.compuware.com>
Tony Curtis <Tony.Curtis+usenet@vcpc.univie.ac.at> writes:
> Re: GetOpts::Std and use strict, Michael
> <mikemort@cadence.com> said:
> Michael> Is there a way of using getopts while still being
> Michael> able to have "use strict"?
>
> use strict;
> use Getopt::Long;
>
> my %opt;
> GetOptions("f=s" => \$opt{'file'}, "d=n" => \$opt{'delay'});
This is quite superfluous. This will do:
GetOptions(\%foo, "file=s", "delay=n");
Note that options 'file' and 'delay' may be abbreviated to uniqueness
(in this case: one character) by default.
Usually it is more convenient (and easier) to link to variables:
my $opt_file;
my $opt_delay;
GetOptions("f=s" => \$opt_file, "d=n" => \$op_delay);
-- Johan
------------------------------
Date: 7 May 1998 09:04:50 GMT
From: "Ephrayim \"EJ\" Naiman" <enaiman@ndsisrael.com>
Subject: How to export constants in modules without C code
Message-Id: <01bd7996$c190f5c0$77140a0a@enaimanlt.ilndc.com>
I'm trying to figure out how to make export constants in modules without
having to
generate any C code (and Autoload, etc).
Specifically, I want to have a bunch of error codes in a module that I'm
writing. Any application that calls this module may get back any one of
these error codes. I want the application to be able to say:
use my_module;
$ret_code = my_module::func($foo1, $foo2);
if($ret_code == ERR_NOT_FOUND)
{
blah, blah
}
Any ideas how to get ERR_NOT_FOUND to work? I've looked on the net, at all
the faqs, at EXPORT_TAGS and can't figure it out. I could use the "use
constant" directive, but then how do I get application code that does a
"use my_module" get the constants defined as well?
If anybody could help I'd be most appreciative. Pointers to examples or
documents accepted
Have a good day,
--
Ephrayim "EJ" Naiman
NDS Technologies Israel Limited
enaiman@ndsisrael.com
------------------------------
Date: Thu, 7 May 1998 11:08:26 +0200
From: Krzysztof Sierota <ksiero@sgh.waw.pl>
Subject: how to pass argument?
Message-Id: <Pine.GSO.3.96.980507104842.24653A-100000@akson.sgh.waw.pl>
Hello
Could anyone tell me how to pass an argument to a perl script ?
thank you
------------------------------
Date: Thu, 07 May 1998 11:29:59 +0200
From: kzal@pol.pl
Subject: Re: how to pass argument?
Message-Id: <35517F17.EBC@pol.pl>
Krzysztof Sierota wrote:
>
> Hello
> Could anyone tell me how to pass an argument to a perl script ?
>
> thank you
An array @ARGV keeps all arguments.
example:
$username = $ARGV[0];
or
$username = shift;
if you use shift without arguments it assumes it's @ARGV.
A number of arguments passed is equal:
$args = $#ARGV + 1;
Krzysztof
------------------------------
Date: 7 May 1998 08:06:59 GMT
From: Zenin <zenin@archive.rhps.org>
Subject: Re: How to send email (was Re: Ever Wonder Why Not Everyone Uses Modules?)
Message-Id: <894528876.491531@thrush.omix.com>
Bennett Todd <bet@network.rahul.net> wrote:
: My favourite approach is pretty simple-minded, and portable to absolutely
: anything I'll every care about porting to:-).
>snip<
Portable yes. Reliable or safe, no. Not by a long shot.
: my($mail) = IO::File->new('|sendmail ' . join(' ',@who)) or die;
And if @who contains shell meta chars? There goes your security
without any good reason. And if it fails, your die() doesn't
display even $! so you don't know why it (fork() in this case)
failed.
: $mail->print("From: myself\n");
: $mail->print("To: whoever\n");
Why a To line when you're naming the list on the command line?
: $mail->print(@lines_of_body);
No -oi, so if this contains any ".\n" lines you're in trouble and
opening another security hole (on some sendmails).
: $mail->close;
No test? Even on a piped open like this? Shame, shame...
: or thereabouts. The "-t" option is available on sendmail and widely emulated
: by other MTAs; I'm not personally all that fond of it anyway.
Yes, but there are vary, vary good reasons for it.
Your script also doesn't seem to care what or if sendmail had any
problems with what you sent it. Nore does it care that all of
sendmail's error messages will go to stdout and stderr. -Yes,
sendmail for some stupid reason sends many error messages to stdout
not stderr. Since you're not catching them or caring if or why
sendmail fails, why not route them to /dev/null at the vary least?
Sorry to pick on you so hard, but least someone else try to use
that code in something important and get hosed hard because of it.
--
-Zenin
zenin@archive.rhps.org
------------------------------
Date: Thu, 7 May 1998 02:43:18 -0500
From: Mike Marziani <marz@tamu.edu>
Subject: How to truncate a float value?
Message-Id: <Pine.NXT.3.96.980507023852.5143A-100000@support.tamu.edu>
I thought this sounded like a simple thing to do, but I have read my
reference and done some net searches but found nothing. I do not want to
use the format construct if at all possible.
I want to truncate a float after the first decimal place, like so:
0.123456789 --> 0.1
I was trying to come up with a regular expression to do this, but I am
pretty new to perl and couldnt figure it out. Any hints?
Thanks,
Mike
------------------------------
Date: 07 May 1998 10:23:48 +0200
From: Tony Curtis <Tony.Curtis+usenet@vcpc.univie.ac.at>
Subject: Re: How to truncate a float value?
Message-Id: <7xvhrixze3.fsf@beavis.vcpc.univie.ac.at>
Re: How to truncate a float value?, Mike <marz@tamu.edu>
said:
Mike> I want to truncate a float after the first decimal
Note, if you want this to be a numeric operation, it's not
really `truncate', it's about precision.
Mike> place, like so:
Mike> 0.123456789 --> 0.1
$ perldoc -f sprintf
If you want to treat it as a string instead of a numeric
value, then it might be easiest to split() on the `.' and
then use substr() to get the bits you want on the right.
$ perldoc -f split
$ perldoc -f substr
hth
tony
--
Tony Curtis, Systems Manager, VCPC, | Tel +43 1 310 93 96 - 12; Fax - 13
Liechtensteinstrasse 22, A-1090 Wien, AT | http://www.vcpc.univie.ac.at/
"You see? You see? Your stupid minds! Stupid! Stupid!" ~ Eros, Plan9 fOS.
------------------------------
Date: 7 May 1998 08:30:33 GMT
From: "David Richards" <david.richards@alderley.zeneca.com>
Subject: Re: Huge array/Win32::NetAdmin::GetUsers
Message-Id: <01bd7992$665d0440$55a0479c@UKMCPHISFW051.ukmcph.zeneca.com>
John
Have you tried the GetUsers in NetAdmin from the CORE perl. This works for
me with 11,000 users on an NT3.51 SP4 machine with 32Mb RAM. Monitoring
the job with Performance Monitor shows no adverse affect on memory:'bytes
available'.
David
John Felso <jfelso@NOSPAM.att.com> wrote in article
<6ir3f8$8t9@newsb.netnews.att.com>...
> I have ascertained that it is not a problem with having an 20,000 element
> array. They problem is with Win32:NetAdmin:GetUsers. For some reason it
> gobbles up entirely too much memory to fill an array with measly 20,000
> users (it is an out of memory rather than an OS limit). My code dies with
an
> "Out of memory!" message while still in GetUsers. GetUsers works great
for
> retrieving small arrays of users though. My guess is that GetUsers is
poorly
> coded. I will report this to Activeware I guess.
>
> John Felso
> jfelso@NOSPAM.att.com
>
>
>
>
------------------------------
Date: 7 May 1998 09:22:31 GMT
From: tina@scandinaviaonline.se (Tina Marie Holmboe)
Subject: Re: IS THIS POSSIBE IN PERL!
Message-Id: <6irugn$jjs$3@news1.sol.no>
In article <6iqr7b$fp1$3@comdyn.comdyn.com.au>,
mgjv@comdyn.com.au (Martien Verbruggen) writes:
>> If, on the other hand, you *don't* know on which pages you link
>> appear, and want to check *that* ... well, then the problem is a
>> slightly different beast.
>
> You could use Altavista to find a few :)
Where "few" is an undefined number > 0 ... yes :) Then of course one would
have to store which pages one has checked; be careful about cyclic linking,
and a few other details.
Not a program I'd want to do - depending on the pay, of course, but then
everything does...
--
Tina Marie Holmboe
Application Developer (Geeks'R'Us) [tina@tech.scandinaviaonline.se]
Scandinavia Online AB Development Dept. (+46) 08 587 81000 (switchboard)
(+46) 08 587 81189 (direct)
------------------------------
Date: 5 May 1998 09:57:38 GMT
From: TC100@t-online.de (Steve)
Subject: OLE and Perl
Message-Id: <6imnqi$t0c$1@news00.btx.dtag.de>
I have big Problem with the OLE.pm.
I try to execute a simple program, the example in the OLE Help Site
1 use Win32::OLE;
2 $ex = new Win32::OLE 'Excel.Application' or die "oops\n";
print ("Start OLE");
3 # open an existing workbook
4 $ex->Workbooks->Open( 'test.xls' );
5 # write to a particular cell
6 $ex->Workbooks(1)->Worksheets('Sheet1')->Cells(1,1)
->{Value}="foo";
print ("End OLE)";
7 # save and exit
8 $ex->Save;
9 $ex->Quit;
It do not work. "test.xls" exist. In Cell(1,1) stands nothing. What
happend is that the Perl-Progamm starts Excel but after line 6 Perl is
ignoring the rest.
I could write in line 7 "BLALALLALALLAL", no error-message from Perl.
It print only "Start OLE", not "End OLE". It seems that perl is
hanging up or wait for something. But it execute withaou any
error-message. And Excel is running in the background and after 10
times calling that programm, I have 10 Excel-prozesses.Terrible.
The same is with my own programm. I wrote an ActiveX.DLL as an OLE
automation DLL. But if I try to access the objects in this dll, it do
not work. And no error -messages.
I don't know what to do. What is the my mistake ?
Steve
------------------------------
Date: Thu, 07 May 1998 10:39:46 +0200
From: Horst Fickenscher <horst.fickenscher@it.erlm.siemens.de>
Subject: Re: print($b=1,$b=2)
Message-Id: <35517352.10F0@it.erlm.siemens.de>
Abigail wrote:
> If one really insists on doing the assignment together with the print:
>
> print $b = "directory/basename";
>
> Abigail
> --
> perl -wle\$_=\<\<EOT\;y/\\n/\ /\;print\; -eJust -eanother -ePerl -eHacker -eEOT
This is not the problem, let's try it from another point of view:
A list constructor gathers values, not references to variables.
You can see this with the following code:
$b = 2;
@ar = ($b, "foo");
$b = 3;
print("@ar\n");
Furthermore the value of an asignment is defined to be the value
of it's right side.
But why then does the value of $b = 2 change when it is followed
by $b = 3 ?
@ar = ($b = 2, $b = 3); # This is not the scalar comma operator!!!
print("@ar\n");
And please: Do answer only if you want to talk about perl syntax
and semantics. I don't want to discuss if the above code makes
sense and I know how do rewrite the code so that it works!
--
--Horst--1---------2----no---3---line--4--should-5----be---6--longer-7
------------------------------
Date: 7 May 1998 08:54:12 GMT
From: gerd4000@hermes.zrz.TU-Berlin.DE (Gerd Schering)
Subject: Problem with xemacs and perl syntax hilitghtning
Message-Id: <6irsrk$5jk$1@news.cs.tu-berlin.de>
Hi,
I think many of you use (x)emacs as develloping environment, as do I.
Now I upgraded my old xemacs to the new 20.4.
When editing a "*.pl" file (cperl-mode get's autoloaded), perl words
like "print", "qw", etc. are displayed in PaleGreen, which is hard to
read on my gray background (which I want to keep).
It only happens with perl, not with c nor c++.
I dont know how to change this behaviour. I even dont know where to look
for. I doesn't come from my '.emacs' file and the 'site-star.el' that comes
with the new xemacs distribution is empty.
Could someone give me a hint?
Thank's
Gerd
------------------------------
Date: Thu, 07 May 1998 09:56:03 GMT
From: sweiner@usa.net (Shawn )
Subject: Re: recursive file renaming
Message-Id: <355184c7.948225@news.wwa.com>
On Tue, 21 Apr 1998 05:44:50 GMT, Eric Bohlman <ebohlman@netcom.com>
was forced by space aliens to write:
>Edwin Shin <eshin@mail.law.berkeley.edu> wrote:
>: can anyone offer a quick and easy way to make the following script
>: recursively plow through a directory tree?
>
>: i would like, for instance, to rename all *.shtml files to *.html in a
>: given directory tree.
>
>perldoc File::Find
look under the thread "looking for a little bit of help here" for the
last post by me. Therin I included a script which recursivley went
down a dir tree and processed the dirs. The key to it is you have to
treat the Directory handle as a variable and increment - decrement it
for each dir you enter/leave.
Shawn
shawn@wwa.com
shawns@wwa.com
sweiner@usa.net
slweiner@juno.com
sweiner@yahoo.com
IrunWulf@aol.com
ICQ#1925117 (visit www.mirabilis.com for more info)
------------------------------
Date: 07 May 1998 11:34:27 +0200
From: Calle Dybedahl <qdtcall@esb.ericsson.se>
Subject: Re: settime
Message-Id: <isd8dqctlo.fsf@godzilla.kiere.ericsson.se>
Frank Meng <frankmeng@usa.net> writes:
> I want to compare two times. But how can I set it back as a TIME?
To convert back into seconds since 1970, the easiest way is probably
to use the timelocal() function in the Time::Local module (included
with your Perl distribution).
It may or may not be easier to count the number of seconds in the
approriate month (it'll be 2678400, 2592000 or 2419200) and subtract
them from time() before you feed it to localtime.
--
Calle Dybedahl, UNIX Sysadmin
qdtcall@esavionics.se http://www.lysator.liu.se/~calle/
------------------------------
Date: 7 May 1998 08:09:43 GMT
From: jobst@senna.eng.monash.edu.au (Jobst Schmalenbach)
Subject: Re: What it perl?
Message-Id: <6irq87$2qe$1@towncrier.cc.monash.edu.au>
Lars Chr Hausmann <36haus@but.auc.dk> writes:
>Hello!
>I have to write something about, what Perl is.
>I need some crystal clear info about, what perl is. So if any of you
>would be so kind just to mail. Then I would be grateful!
Perl.
regards
jobst
--
| __, Jobst Schmalenbach, Monash Uni, Melbourne, Australia |
| _ _.--'-n_/ Electrical and Computer Systems Engineering |
| -(_)------(_)= email jobst@senna.eng.monash.edu.au 61-3-99055705 |
| http://senna.eng.monash.edu.au/~jobst 61-41-1611855 |
------------------------------
Date: 8 Mar 97 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 8 Mar 97)
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.
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 2525
**************************************
