[31617] in Perl-Users-Digest
Perl-Users Digest, Issue: 2876 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Mar 15 18:09:32 2010
Date: Mon, 15 Mar 2010 15:09:11 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 15 Mar 2010 Volume: 11 Number: 2876
Today's topics:
Re: Best Perl compiler, IDE for Win XP, 32bit <FW3006@sbcglobal.net>
Re: Best Perl compiler, IDE for Win XP, 32bit <jurgenex@hotmail.com>
Caching robots.txt in LWP::RobotUA <pwaring@gmail.com>
Re: Caching robots.txt in LWP::RobotUA <pwaring@gmail.com>
check for file in $PATH <ron.eggler@gmail.com>
Re: check for file in $PATH <devnull4711@web.de>
Re: check for file in $PATH <jurgenex@hotmail.com>
Re: check for file in $PATH <ron.eggler@gmail.com>
Re: check for file in $PATH <jurgenex@hotmail.com>
Re: check for file in $PATH <paul@hovnanian.com>
Re: check for file in $PATH <ben@morrow.me.uk>
Re: Fast way to fill memory <jurgenex@hotmail.com>
Re: Fast way to fill memory <bugbear@trim_papermule.co.uk_trim>
Re: Help on String to array ! <hjp-usenet2@hjp.at>
Re: Help on String to array ! <ben@morrow.me.uk>
Re: Still looking for a function-type MySQL interface <uri@StemSystems.com>
Re: to RG - Lisp lunacy and Perl psychosis <hjp-usenet2@hjp.at>
Re: to RG - Lisp lunacy and Perl psychosis <hjp-usenet2@hjp.at>
Re: Well, that's the most obscure Perl bug I've ever se <hjp-usenet2@hjp.at>
Re: Well, that's the most obscure Perl bug I've ever se <hjp-usenet2@hjp.at>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 15 Mar 2010 09:38:50 -0700 (PDT)
From: 2007 <FW3006@sbcglobal.net>
Subject: Re: Best Perl compiler, IDE for Win XP, 32bit
Message-Id: <71df8974-0c72-4ca2-a498-99b5380c9771@s25g2000prd.googlegroups.com>
On Mar 15, 1:36=A0am, Bart Lateur <bart.lat...@telenet.be> wrote:
> 2007 wrote:
> >I am looking for Perl compiler and possibly an IDE.
>
> Perl doesn't have a compiler, so that gives me a clue on your expertise
> level...
I know its an interpreter - as I searched online with keywords, it
auto-types in with words such as "compiler" - so I assumed compiler is
a preferred word. Two people above had not expressed an issue with it.
------------------------------
Date: Mon, 15 Mar 2010 10:31:17 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Best Perl compiler, IDE for Win XP, 32bit
Message-Id: <jersp55gompg6efp0hfnns1squ3aem19lk@4ax.com>
2007 <FW3006@sbcglobal.net> wrote:
>On Mar 15, 1:36 am, Bart Lateur <bart.lat...@telenet.be> wrote:
>> 2007 wrote:
>> >I am looking for Perl compiler and possibly an IDE.
>>
>> Perl doesn't have a compiler, so that gives me a clue on your expertise
>> level...
>
>I know its an interpreter - as I searched online with keywords, it
>auto-types in with words such as "compiler" - so I assumed compiler is
>a preferred word.
As much as pickup is the preferred word over coupe. Both get you from
point a to point b and consist mostly of similar parts, but when going
shopping for one you better know which one you want.
> Two people above had not expressed an issue with it.
As far as I could see neither was addressing the compiler part of your
question in the first place.
jue
------------------------------
Date: Mon, 15 Mar 2010 13:15:08 -0700 (PDT)
From: "pwaring@gmail.com" <pwaring@gmail.com>
Subject: Caching robots.txt in LWP::RobotUA
Message-Id: <bb669429-466d-4699-b0f8-7584988b6159@30g2000yqi.googlegroups.com>
I'm using LWP::RobotUA to download a series of pages with the
following code:
#!/usr/bin/perl -w
use strict;
use LWP::RobotUA;
my %options = ('agent' => 'crawler', 'show_progress' => 1, 'delay' =>
10/60, 'from' => 'example@example.org');
my $ua = LWP::RobotUA->new(%options);
my @all_urls = (array of liniks populated from elsewhere);
foreach my $url (@all_urls)
{
$filename = "$url.html";
$ua->mirror($url, $filename);
}
}
The problem is that LWP::RobotUA seems to make a GET request for the
robots.txt file each time I call the mirror() method, even though all
of the URLs are on the same domain. I'd expect the module to cache the
file, either in memory or on disk, because it's highly unlikely to
change between requests, but it doesn't seem to do so.
Do I need to write my own cache module, or tack on an existing one
from CPAN? I was hoping that calling mirror() would Just Work.
Thanks in advance!
------------------------------
Date: Mon, 15 Mar 2010 13:18:18 -0700 (PDT)
From: "pwaring@gmail.com" <pwaring@gmail.com>
Subject: Re: Caching robots.txt in LWP::RobotUA
Message-Id: <5861d6c8-0472-45ee-a0d0-4b6ee05dfc97@v20g2000yqv.googlegroups.com>
On 15 Mar, 20:15, "pwar...@gmail.com" <pwar...@gmail.com> wrote:
> foreach my $url (@all_urls)
> {
> =A0 =A0 $filename =3D "$url.html";
> =A0 =A0 $ua->mirror($url, $filename);
> =A0 }
>
> }
That second bracket shouldn't be there - I forgot to omit it when
snipping the code down to just show the relevant parts.
------------------------------
Date: Mon, 15 Mar 2010 10:24:37 -0700 (PDT)
From: cerr <ron.eggler@gmail.com>
Subject: check for file in $PATH
Message-Id: <f77b5412-a08d-4765-abd0-be6b9f3cc6d0@o16g2000prh.googlegroups.com>
Hi There,
My perl script depends on a binary that may be in $PATH and i would
like to check for that file. How can I verify if the file is present
in $PATH without hard coding a full path?
Thanks,
Ron
------------------------------
Date: Mon, 15 Mar 2010 18:42:36 +0100
From: Frank Seitz <devnull4711@web.de>
Subject: Re: check for file in $PATH
Message-Id: <8079scF8fbU1@mid.individual.net>
cerr wrote:
>
> My perl script depends on a binary that may be in $PATH and i would
> like to check for that file. How can I verify if the file is present
> in $PATH without hard coding a full path?
http://search.cpan.org/~tjenness/File-SearchPath/SearchPath.pm
Frank
--
Dipl.-Inform. Frank Seitz
Anwendungen für Ihr Internet und Intranet
Tel: +49 (0)4103/180301; Fax: -02; Industriestr. 31, D-22880 Wedel
Blog: http://www.fseitz.de/blog
XING-Profil: http://www.xing.com/profile/Frank_Seitz2
------------------------------
Date: Mon, 15 Mar 2010 10:46:26 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: check for file in $PATH
Message-Id: <hdssp5t2sc8j7g6ig5u96h2dh0cs44samd@4ax.com>
cerr <ron.eggler@gmail.com> wrote:
>My perl script depends on a binary that may be in $PATH and i would
>like to check for that file. How can I verify if the file is present
>in $PATH without hard coding a full path?
I suppose you could generalize FindBin to search for arbitrary files,
not just the perl binary.
Or simply use the external "which" utility.
Or just call it, maybe with innocent arguments, and analyse the return
value for the error code.
jue
------------------------------
Date: Mon, 15 Mar 2010 11:45:38 -0700 (PDT)
From: cerr <ron.eggler@gmail.com>
Subject: Re: check for file in $PATH
Message-Id: <8a9b3a00-cb72-4a14-b3e9-f5721ec00456@n39g2000prj.googlegroups.com>
On Mar 15, 10:42=A0am, Frank Seitz <devnull4...@web.de> wrote:
> cerr wrote:
>
> > My perl script depends on a binary that may be in $PATH and i would
> > like to check for that file. How can I verify if the file is present
> > in $PATH without hard coding a full path?
>
> http://search.cpan.org/~tjenness/File-SearchPath/SearchPath.pm
Great! this is doing the job, thanks!
--
Ron
------------------------------
Date: Mon, 15 Mar 2010 11:54:43 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: check for file in $PATH
Message-Id: <1j0tp59oq6e3a3i1hf5073qgcj2p820v5c@4ax.com>
Frank Seitz <devnull4711@web.de> wrote:
>cerr wrote:
>> My perl script depends on a binary that may be in $PATH and i would
>> like to check for that file. How can I verify if the file is present
>> in $PATH without hard coding a full path?
>
>http://search.cpan.org/~tjenness/File-SearchPath/SearchPath.pm
Much better than my idea ;-)
jue
------------------------------
Date: Mon, 15 Mar 2010 12:00:12 -0700
From: "Paul Hovnanian P.E." <paul@hovnanian.com>
Subject: Re: check for file in $PATH
Message-Id: <_bCdncNhid_6HgPWnZ2dnUVZ_g6dnZ2d@posted.isomediainc>
cerr wrote:
> Hi There,
>
> My perl script depends on a binary that may be in $PATH and i would
> like to check for that file. How can I verify if the file is present
> in $PATH without hard coding a full path?
>
> Thanks,
> Ron
No need to hardcode $PATH in your app. Just get it from %ENV as $ENV{PATH}.
So
sub fnd {
my ($f) = @_;
foreach my $p (split /:/, $ENV{PATH}) {
return "$p/$f" if( -x "$p/$f" );
}
return undef;
}
will return the full executable path for $f, or undef. You might want to
clean this up a bit.
--
Paul Hovnanian paul@hovnanian.com
----------------------------------------------------------------------
Have gnu, will travel.
------------------------------
Date: Mon, 15 Mar 2010 21:46:17 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: check for file in $PATH
Message-Id: <9em277-ou61.ln1@osiris.mauzo.dyndns.org>
Quoth "Paul Hovnanian P.E." <paul@hovnanian.com>:
> cerr wrote:
>
> > My perl script depends on a binary that may be in $PATH and i would
> > like to check for that file. How can I verify if the file is present
> > in $PATH without hard coding a full path?
>
> No need to hardcode $PATH in your app. Just get it from %ENV as $ENV{PATH}.
>
> So
>
> sub fnd {
> my ($f) = @_;
> foreach my $p (split /:/, $ENV{PATH}) {
Use File::Spec->path here, or some wrapper. Not all platforms use a
:-separated PATH, and not all platforms call the pertinant env var 'PATH'.
> return "$p/$f" if( -x "$p/$f" );
Ditto: File::Spec->catfile, or a wrapper like Path::Class (highly
recommended).
Ben
------------------------------
Date: Mon, 15 Mar 2010 07:14:27 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Fast way to fill memory
Message-Id: <f0gsp5lpduu31kehr03esodtg45cbem90f@4ax.com>
Oliver 'ojo' Bedford <newsojo@web.de> wrote:
>For testing purposes I would like to fill chunks of memory (say 20M) with
>arbitrary data (say bytes with values 1,2,...255,1,...).
>
>What would be the fastest method?
The easiest method would probably be to define a string with say 256
bytes and then use the x operator to repeat it.
I would guess it would also be quite fast because it uses perl interna
only and doesn't involve a user-level loop.
jue
------------------------------
Date: Mon, 15 Mar 2010 16:00:42 +0000
From: bugbear <bugbear@trim_papermule.co.uk_trim>
Subject: Re: Fast way to fill memory
Message-Id: <MYSdnQKg_JU3xAPWnZ2dnUVZ8opi4p2d@brightview.co.uk>
Jürgen Exner wrote:
> Oliver 'ojo' Bedford <newsojo@web.de> wrote:
>> For testing purposes I would like to fill chunks of memory (say 20M) with
>> arbitrary data (say bytes with values 1,2,...255,1,...).
>>
>> What would be the fastest method?
>
> The easiest method would probably be to define a string with say 256
> bytes and then use the x operator to repeat it.
> I would guess it would also be quite fast because it uses perl interna
> only and doesn't involve a user-level loop.
If speed is really important (it often isn't) you may be able
to repeatedly "double up" by copying the head of the 20Meg space to itself.
BugBear
------------------------------
Date: Mon, 15 Mar 2010 22:34:36 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Help on String to array !
Message-Id: <slrnhpt9vc.is.hjp-usenet2@hrunkner.hjp.at>
On 2010-03-12 02:47, Uri Guttman <uri@StemSystems.com> wrote:
>>>>>> "PJH" == Peter J Holzer <hjp-usenet2@hjp.at> writes:
> PJH> On 2010-03-11 18:30, Uri Guttman <uri@StemSystems.com> wrote:
> >>>>>>> "JWK" == John W Krahn <someone@example.com> writes:
> >> anyhow, this whole thing is moot. the OP never said he had a 25GB file
> >> on a 2gb system.
>
> PJH> Right. He never said that. So where did you get that information?
>
> PJH> He said he had a 4 MB file and 45 GB of free space (the latter is rather
> PJH> irrelevant, of course).
>
> i misread the 45Gb free disk as the file size. he still never mentioned
> the file size. as i showed, the unpack is fastest with the data in
> ram. i still would want to know his setup (file size included) to see
> why his substr would be fastest. it has to be some very odd thing he is
> doing and not telling us.
The odd thing he is doing seems to be "using perl on Windows". Sln has
repeatedly pointed out that growing strings or arrays on Windows is
extremely slow (yes, sln sometimes makes strange claims, but be not only
provided benchmark results but also a link to a perlmonks thread - so he
isn't the only one who noticed this). I don't have access to a Windows
machine where I could test this myself, though.
hp
------------------------------
Date: Mon, 15 Mar 2010 21:56:34 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Help on String to array !
Message-Id: <i1n277-ou61.ln1@osiris.mauzo.dyndns.org>
Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
>
> The odd thing he is doing seems to be "using perl on Windows". Sln has
> repeatedly pointed out that growing strings or arrays on Windows is
> extremely slow (yes, sln sometimes makes strange claims, but be not only
> provided benchmark results but also a link to a perlmonks thread - so he
> isn't the only one who noticed this). I don't have access to a Windows
> machine where I could test this myself, though.
Win32's malloc is well known to be appalling, but you can't build perl
with perl's malloc if you want USE_IMPLICIT_SYS. Since IMP_SYS is required
for fork emulation, most perls on Win32 are built with Win32's malloc,
and are thus much slower than they might be :(.
Ben
------------------------------
Date: Mon, 15 Mar 2010 16:21:09 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Still looking for a function-type MySQL interface
Message-Id: <87pr35xrnu.fsf@quad.sysarch.com>
>>>>> "LE" == Lars Eighner <usenet@larseighner.com> writes:
LE> I'm still looking for a function-type database interface. CPAN
LE> returns more than 1100 hits for mysql, but if there is a function
LE> interface, I haven't found it.
i still say learning OO perl is easy enough and you should learn
it. saying pointy ops are hard is a barbie excuse. but if you MUST have
a procedural API (functional is the wrong term), check out Sub::Exporter
on cpan. it can create a procedural API from an OO one and manage a
singleton object for you. you still need to do some work (if you can
handle it) to create your own api. this a fool's errand you are on
anyhow but i had to mention this module.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Mon, 15 Mar 2010 20:44:20 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: to RG - Lisp lunacy and Perl psychosis
Message-Id: <slrnhpt3gl.is.hjp-usenet2@hrunkner.hjp.at>
On 2010-03-12 02:14, John Bokma <john@castleamber.com> wrote:
> "Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
>> On 2010-03-10 20:54, John Bokma <john@castleamber.com> wrote:
>>> I do agree, however, that it would've been nice if C had references like
>>> Perl, and (harder to get to) pointers as they are now.
>>
>> Actually, C pointers are quite ok in theory (for example, you can't make
>> a pointer into an array point outside of the array (except "just after"
>> it).
>
> How does C prevent this? Or I don't understand what a pointer into an
> array is.
>
You removed the next sentence where I wrote that it doesn't. It just
says "that's forbidden", but leaves to compiler complete freedom how to
deal (or not deal) with the situation. Most compilers (for the sake of
efficiency and compatibility with existing ABIs) assume that the
programmer never makes a mistake and produce code which will happily
scribble over neighbour variables. A very few however will produce code
which catches the error and raises an exception.
hp
------------------------------
Date: Mon, 15 Mar 2010 22:27:13 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: to RG - Lisp lunacy and Perl psychosis
Message-Id: <slrnhpt9hi.is.hjp-usenet2@hrunkner.hjp.at>
On 2010-03-12 05:04, Ron Garret <rNOSPAMon@flownet.com> wrote:
> In article <slrnhpisqf.i4n.hjp-usenet2@hrunkner.hjp.at>,
> "Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
>
>> In any case I very much doubt that it is much easier to find the bug in
>> a lisp program which "suddenly started failing silently and
>> intermittently" than in a Perl program which does the same.
>
> I assure you, you are quite mistaken. I have a first-hand data point on
> that as well:
>
> http://ti.arc.nasa.gov/m/pub/archive/2000-0176.pdf
Interesting paper.
But I don't think it proves your point.
1) Perl isn't mentioned at all, so you cannot draw any conclusions about
Perl from the paper (neither negative nor positive).
2) The verification tool mentioned doesn't work on Lisp input, but uses
a specialized modelling language called PROMELA. The authors state:
The modeling effort, i.e. obtaining a PROMELA model from the LISP
program, took about 12 man weeks during 6 calendar weeks, while the
verification effort took about one week. The modeling effort
consisted conceptually of an abstraction activity combined with a
translation activity. Abstraction was needed to cut down the program
to one with a reasonably small finite state space, making model
checking tractable. Translation, from LISP to PROMELA, was needed to
obtain a PROMELA model that the SPIN model checker could analyze.
[...]
The translation phase was non-trivial and time consuming due to the
relative expressive power of LISP when compared with PROMELA.
Spending 12 man-weeks hand-translating Lisp to PROMELA doesn't
exactly sound like it's easy - in fact the authors explicitely called
the task "non-trivial".
3) Then the authors built an automated translation tool, but again it
doesn't translate Lisp to PROMELA, it translates (a subset of) Java
to PROMELA. So, again, they had to hand-translate Lisp to Java, which
could then be automatically processed. At least translating Lisp to
Java was very quick (two hours!) but that may be because
Some of us spotted the potential error situation because it
resembled the similar error we had found using SPIN in 1997[...]
and the subsequent
focus on the particular code fragment
The error is a text-book example of a race-condition, btw. It is
discussed in almost identical form in any systems programming class,
and they could have spotted it because of that and not just because
the encountered it before.
4) The RAX team found the error within 24 hours, the JPF team within
48 hours (but they also had identified the code fragment as
suspicious within 12 hours).
In conclusion, there is nothing in the paper which suggests that Lisp in
particularly easy to model. If anything, they seem to suggest that Java
is easy to model, although I suspect that "shrinking down" real world
Java programs to a manageable complexity is still non-trivial, even with
the help of their abstraction tool.
That two independent teams each found the race condition within less
than two days is impressive. That may be a hint that Lisp makes it
relatively easy to spot that kind of error. But without more knowledge
about the specific case and a direct comparison to other programming
languages it isn't conclusive.
hp
------------------------------
Date: Mon, 15 Mar 2010 20:21:15 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Well, that's the most obscure Perl bug I've ever seen
Message-Id: <slrnhpt25b.is.hjp-usenet2@hrunkner.hjp.at>
On 2010-03-12 00:01, Ben Morrow <ben@morrow.me.uk> wrote:
>
> Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
>> On 2010-03-11 19:14, Ben Morrow <ben@morrow.me.uk> wrote:
>> >
>> > There's no such thing in Perl. Evaluating a ref in numeric context
>> > numifies it. It's the same as
>> >
>> > float a;
>> > int b = 3;
>> > a = b;
>> >
>> > in C, which is actually an implicit function call
>>
>> There is no implicit function call here. Did you mean an implicit cast?
>
> I phrased that badly: there is no C function call. But there is an
> operation more complicated than simple assignment, such as might result
> from the inlining of a function that does the conversion.
The operation has about the same order of complexity as other C
operators. You wouldn't say that "+" is actually an implicit function call,
would you? Even though for some data types on some architectures an
addition is actually implemented as a function (maybe not even inlined).
> I was avoiding the term 'cast' because it means two different things in
> C. Sometimes it means an actual conversion from one representation to
> another, sometimes it means simply reinterpreting the existing bits as a
> different type (casts between pointers to compatible structures, for
> instance).
Conceptionally it is always a conversion. However, some conversions
happen to be noops. For example, the conversion int -> unsigned int is
arithmetically defined in the standard: For a nonnegative int i,
(unsigned)i is i, for a negative int i, (unsigned)i is i + UINT_MAX + 1.
If you happen to use two's complement representation (all modern
architectures, AFAIK) of signed ints, that's a noop, if you use
sign-magnitude or one's complement, you need to fiddle some bits.
Similarly for pointers: Theoretically pointers to different types could
be different at the bit level, but I don't know any modern architecture
where they are - so casts between pointers are always a noop in
practice (I also remember the quote "all struct pointers smell the
same", but I'm not sure whether that means they have to be the same at
the bit level - it's been too long since I participated in comp.std.c).
>> > (though Perl caches the result, which C doesn't).
>>
>> Well, the result is stored in a. So it is "cached" in some sense.
>> And the compiler is of course free to cache the value of any expression
>> somewhere in a temporary variable if it thinks it can reuse it. So in some
>> code like:
>>
>> x = a + b * c + d;
>> y = a + b * c;
>>
>> a C compiler probably will "cache" the result of "a + b * c", while the
>> perl compiler won't.
>
> That's true, of course. OTOH, if you have
>
> void bar(int x)
> {
> float f = x;
> }
>
> void foo()
> {
> int a = 1;
> float b = a;
> bar(a);
> }
>
> it won't, unless it can inline bar to assist the optimization, whereas
> perl would.
True. OTOH, if the C compiler can inline function calls, it will
probably also optimize away foo() completely ;-).
hp
------------------------------
Date: Mon, 15 Mar 2010 20:36:32 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Well, that's the most obscure Perl bug I've ever seen
Message-Id: <slrnhpt320.is.hjp-usenet2@hrunkner.hjp.at>
On 2010-03-12 16:46, Kyle T. Jones <KBfoMe@realdomain.net> wrote:
> Peter J. Holzer wrote:
>> On 2010-03-11 23:17, Kyle T. Jones <KBfoMe@realdomain.net> wrote:
>>> I guess instead of a snark, I could have offered this (it's ugly,
>>> there's undoubtedly an easier way to do it, I invite criticism, but I'm
>>> 95% it'll work just fine):
>>>
>> [script snipped]
>>
>> I seem to be missing the part of the script which fixes all the errors
>> and warnings ...
>
> So add in a section that splits the script into subs and main then
> parses each for the first instance of declared variables, and append my
> to the front of each. That's likely to be a huge percentage of the
> errors you'll hit adding in use strict to scripts authored by folks that
> don't use, well, use strict.
>
> You know what though - I did think he had said he had "thousands of
> scripts" - but what he said was "several scripts of a thousand lines of
> code". So, that changes things.
>
> Tell you what, though - you go and create something that "fixes all the
> errors and warnings" for any perl script (or any language for that
> matter). You'll be rich, @#$%^.
Well, that was sort of my point. Just mechanically adding a line "use
strict;" is easy, but that almost certainly isn't what keeps the OP from
doing it. Wading through the plethora of warnings and errors and
deciding how to fix them is the real work and that cannot be easily
automated. Automatically generating my() or our() declarations isn't
quite trivial due to the irregular syntax of Perl but should be possible
- but I think the danger of covering up or creating bugs is greater than
the benefit.
I'd do it like this:
When you need to change anything in a script the very first time, you
have to spend some time anyway to read and understand it. So this is the
perfect time to add "use warnings; use strict" an fix all the resulting
errors and warnings as you go. (This is also an advantage of "use
warnings" over "-w" - it affects only the source file, not any used
modules, so you can add it one file at a time)
hp
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 2876
***************************************
