[23137] in Perl-Users-Digest
Perl-Users Digest, Issue: 5358 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Aug 14 14:06:58 2003
Date: Thu, 14 Aug 2003 11:05:20 -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 Thu, 14 Aug 2003 Volume: 10 Number: 5358
Today's topics:
"use warnings" or "-w" <arc_of_descent@gmx.net>
Re: "use warnings" or "-w" (Sam Holden)
Re: "use warnings" or "-w" (Tad McClellan)
Re: "use warnings" or "-w" <abigail@abigail.nl>
Re: 'make' implemented in Perl <tzz@lifelogs.com>
Re: 'make' implemented in Perl <emschwar@pobox.com>
Bug in perl? <mdudley@execonn.com>
Re: Bug in perl? <peter@semantico.com>
Re: Bug in perl? <shawn@magma.ca>
Re: Bug in perl? <john.thetenant-s@moving-picture.com>
Re: Bug in perl? (Tad McClellan)
Re: Bug in perl? (Tad McClellan)
Re: Bug in perl? <mdudley@execonn.com>
Re: Bug in perl? <ian@WINDOZEdigiserv.net>
Re: Bug in perl? (Tad McClellan)
Re: finding subdirectories without parsing every file <tore@aursand.no>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 14 Aug 2003 18:37:14 +0530
From: Rohan Romanus Almeida <arc_of_descent@gmx.net>
Subject: "use warnings" or "-w"
Message-Id: <20030814183714.185e1204.arc_of_descent@gmx.net>
Hi,
Wanted a little help regarding "use warnings".
AFAIK, there are the following choices:
1) #!/usr/bin/perl -w
In this mode, the perl interpreter is started with "-w",
as a command line option.
But if the user knows the absolute path of the perl script,
then he can execute,
$ perl /path/to/perlscript
So, does he bypass the "-w" option?
2) #!/usr/bin/perl
use warnings;
I think this is the bestest choice!
I normally begin my perl scripts with the following 2 lines:
#!/usr/bin/perl
use strict; use warnings;
Is this safe?
What do most of you people use?
Thankz.
--
arc_of_descent
------------------------------
Date: 14 Aug 2003 13:30:22 GMT
From: sholden@flexal.cs.usyd.edu.au (Sam Holden)
Subject: Re: "use warnings" or "-w"
Message-Id: <slrnbjn3ne.tnd.sholden@flexal.cs.usyd.edu.au>
On Thu, 14 Aug 2003 18:37:14 +0530,
Rohan Romanus Almeida <arc_of_descent@gmx.net> wrote:
>
> Hi,
>
> Wanted a little help regarding "use warnings".
>
> AFAIK, there are the following choices:
>
> 1) #!/usr/bin/perl -w
>
> In this mode, the perl interpreter is started with "-w",
> as a command line option.
> But if the user knows the absolute path of the perl script,
> then he can execute,
> $ perl /path/to/perlscript
>
> So, does he bypass the "-w" option?
No.
Of course you could have tried it youself and known the answer without
asking...
--
Sam Holden
------------------------------
Date: Thu, 14 Aug 2003 08:51:00 -0500
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: "use warnings" or "-w"
Message-Id: <slrnbjn4u4.7ah.tadmc@magna.augustmail.com>
Rohan Romanus Almeida <arc_of_descent@gmx.net> wrote:
> 1) #!/usr/bin/perl -w
>
> In this mode, the perl interpreter is started with "-w",
> as a command line option.
> But if the user knows the absolute path of the perl script,
> then he can execute,
> $ perl /path/to/perlscript
>
> So, does he bypass the "-w" option?
What happened when you tried it?
> 2) #!/usr/bin/perl
> use warnings;
>
> I think this is the bestest choice!
<aol> Me too! </aol> But not because of how the program is invoked.
It is because lexical warnings are better than global warnings.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 14 Aug 2003 13:53:58 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: "use warnings" or "-w"
Message-Id: <slrnbjn53l.aqf.abigail@alexandra.abigail.nl>
Rohan Romanus Almeida (arc_of_descent@gmx.net) wrote on MMMDCXXXV
September MCMXCIII in <URL:news:20030814183714.185e1204.arc_of_descent@gmx.net>:
<>
<> Hi,
<>
<> Wanted a little help regarding "use warnings".
<>
<> AFAIK, there are the following choices:
<>
<> 1) #!/usr/bin/perl -w
<>
<> In this mode, the perl interpreter is started with "-w",
<> as a command line option.
<> But if the user knows the absolute path of the perl script,
<> then he can execute,
<> $ perl /path/to/perlscript
<>
<> So, does he bypass the "-w" option?
What happened when you tried? I mean, it takes far less lines to
write a Perl program that generates a warning, then to write your
post.
<> 2) #!/usr/bin/perl
<> use warnings;
<>
<> I think this is the bestest choice!
It depends what your goal is. If it needs to run on 5.005, it's
a very poor choice. If you need to turn on warnings for include
modules as well, 'use warnings' isn't go to do that; -w does.
<> I normally begin my perl scripts with the following 2 lines:
<>
<> #!/usr/bin/perl
<> use strict; use warnings;
<>
<> Is this safe?
<> What do most of you people use?
I use a blank line after the she bang line.
--
perl -MLWP::UserAgent -MHTML::TreeBuilder -MHTML::FormatText -wle'print +(
HTML::FormatText -> new -> format (HTML::TreeBuilder -> new -> parse (
LWP::UserAgent -> new -> request (HTTP::Request -> new ("GET",
"http://work.ucsd.edu:5141/cgi-bin/http_webster?isindex=perl")) -> content))
=~ /(.*\))[-\s]+Addition/s) [0]'
------------------------------
Date: Thu, 14 Aug 2003 12:13:14 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: 'make' implemented in Perl
Message-Id: <4nvft0dxph.fsf@lockgroove.bwh.harvard.edu>
On 14 Aug 2003, abigail@abigail.nl wrote:
> Ted Zlatanov (tzz@lifelogs.com) wrote on MMMDCXXXV September
> MCMXCIII in <URL:news:4n1xvozekz.fsf@lockgroove.bwh.harvard.edu>:
> %% I think most modules (99.99%?) use Makefile.PL, which currently
> %% means having to use `make' but, because of what Perl can do
> %% internally, could be replaced. Let's assume for the moment that
> %% `make' is still useful for compiling modules with C code; I'm
> %% talking about pure Perl modules. For those, "perl Makefile.PL;
> %% make; make install" could be simply "perl Makefile.PL install" or
> %% something similar.
>
> No. Then you are not understanding 'make', which tries to do its
> utter best not to create something that is already there.
I doubt that I don't understand `make.' What makes you think that?
>
> %% You and Eric are saying it's no big deal
> %% to install `make.' It's not a big deal for experienced users,
> %% but at the very least it's a hassle for new Perl users on the
> %% Windows platform.
>
> That is not an argument. It would if Perl was the only software that
> makes use of 'make', but the fast majority of software requires
> 'make' to build. The users of a Windows platform would be more
> helped with getting 'make', than with Perl circumventing the use of
> 'make'.
Using software does not have to mean building it. The vast majority
of Windows users, in fact, are quite happy with precompiled
binaries and have never built software. Why not make Perl more
accessible to them? ActiveState Perl already provides PPMs, which
should show you at least that there's a demand for Perl from people
who don't want to bother with building software themselves.
Also, you seem to be equating installing CPAN modules with building
software. In the case of pure-Perl modules, this is usually not true.
> But if you think there's a better way: code speaks more than words.
If I think there's no good alternative, I might write my own make.pl,
but 4 such programs have been pointed out already. I might also write
something that interprets Makefile.PL on the fly and skips the `make'
step if possible, but I want to find out if a) such a thing is
planned/exists already, and b) there's a better way to do it.
The simplest fix is to include make.pl (which is compatible with the
standard Makefile syntax, according to its web page) with the CPAN
module and use it instead of `make.' I don't think it's a necessary
step, since all the information needed is already available from the
Makefile.PL, but it can certainly be used for backwards compatibility.
You can't ask that someone write the code every time they point out
inefficiencies or bad design. Sometimes it's the right thing to do,
but sometimes a little research and conversation will save days of
work.
In case it wasn't clear, I started this thread because I was curious
about make alternatives written in Perl (fully answered, thanks), and
why they are not being used to replace `make' in the CPAN install
process. So far, the arguments for the latter have been "because make
works (and is available everywhere)" and "because it's hard to replace
make."
On CPAN, the CPAN.pm modules is going to be replaced by CPANPLUS:
http://search.cpan.org/author/KANE/CPANPLUS-0.042/lib/CPANPLUS/Backend.pm
(look at the install function to see it still uses `make')
So CPANPLUS.pm appears to continue the CPAN.pm `make' usage.
Thanks
Ted
------------------------------
Date: Thu, 14 Aug 2003 11:52:45 -0600
From: Eric Schwartz <emschwar@pobox.com>
Subject: Re: 'make' implemented in Perl
Message-Id: <eto7k5gjfde.fsf@wormtongue.emschwar>
Ted Zlatanov <tzz@lifelogs.com> writes:
> Using software does not have to mean building it. The vast majority
> of Windows users, in fact, are quite happy with precompiled
> binaries and have never built software. Why not make Perl more
> accessible to them? ActiveState Perl already provides PPMs, which
> should show you at least that there's a demand for Perl from people
> who don't want to bother with building software themselves.
If people want to use Perl modules without compiling them, then they
should use some Perl distribution that doesn't require them to compile
modules. I have never felt the need to compile Perl modules except on
Mac OS X; Debian takes care of that for me (as would any other distro;
that's just the one I happen to use). Windows users have ActiveState
and that other distribution whose name I can never remember with
Apache + Perl. So it seems to me that people who are interested in
using Perl modules instead of compiling them already have plenty of
options.
> Also, you seem to be equating installing CPAN modules with building
> software. In the case of pure-Perl modules, this is usually not true.
It is building software; sometimes the 'build' step is trivial, but
it's important to keep it in place, in case a later revision of a
module requires more action there.
Anyway, as you yourself thoughtfully pointed out, people wanting to
install (most) CPAN modules can just use ppm or apt-get or rpm or
whatever and install them. This works for pure-Perl as well as XS
modules.
> If I think there's no good alternative, I might write my own make.pl,
> but 4 such programs have been pointed out already. I might also write
> something that interprets Makefile.PL on the fly and skips the `make'
> step if possible, but I want to find out if a) such a thing is
> planned/exists already, and b) there's a better way to do it.
I think we've answered those questions so far: a) no. b) we don't
think so, but if you do, you're welcome to prove us wrong. And I'm
quite sincere in that; if you can come up with something that works in
all cases, that's great.
> The simplest fix is to include make.pl (which is compatible with the
> standard Makefile syntax, according to its web page) with the CPAN
> module and use it instead of `make.'
Go to it. Let us know how it goes.
> I don't think it's a necessary
> step, since all the information needed is already available from the
> Makefile.PL, but it can certainly be used for backwards compatibility.
Sounds like a reasonable first step.
> You can't ask that someone write the code every time they point out
> inefficiencies or bad design. Sometimes it's the right thing to do,
> but sometimes a little research and conversation will save days of
> work.
Well, in this case, we've had the conversation, and I think your need
for research is fulfilled, so all that's left is for code to be
written to make CPAN.pm, ExtUtils::MakeMaker, and whatever else I'm
forgetting use this make.pl you've found. As you seem to be the only
person interested in having the code, you're logically the best
person to write it.
> On CPAN, the CPAN.pm modules is going to be replaced by CPANPLUS:
>
> http://search.cpan.org/author/KANE/CPANPLUS-0.042/lib/CPANPLUS/Backend.pm
> (look at the install function to see it still uses `make')
>
> So CPANPLUS.pm appears to continue the CPAN.pm `make' usage.
So submit a patch; if the author like it, no doubt it'll be accepted.
-=Eric
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
-- Blair Houghton.
------------------------------
Date: Thu, 14 Aug 2003 10:02:20 -0400
From: Marshall Dudley <mdudley@execonn.com>
Subject: Bug in perl?
Message-Id: <3F3B966C.D292F7B9@execonn.com>
Perl 5.005_03 built for 386 freeBSD
I am trying to get perl to work on a windows system for the first time,
thus the path delimiters are \ instead of /. For some reason the
following very simple code will not compile:
$path = 'c:\home\mysite\cgi-bin\';
$site = 'mysite';
The problem seems to be the trailing \ on line 1, but that is needed as
part of the path so I can't leave it out.
Any ideas?
Marshall
------------------------------
Date: Thu, 14 Aug 2003 16:38:23 +0100
From: Peter Hickman <peter@semantico.com>
Subject: Re: Bug in perl?
Message-Id: <3f3bacef$0$18265$afc38c87@news.easynet.co.uk>
Marshall Dudley wrote:
> Perl 5.005_03 built for 386 freeBSD
>
> I am trying to get perl to work on a windows system for the first time,
> thus the path delimiters are \ instead of /. For some reason the
> following very simple code will not compile:
>
> $path = 'c:\home\mysite\cgi-bin\';
> $site = 'mysite';
>
> The problem seems to be the trailing \ on line 1, but that is needed as
> part of the path so I can't leave it out.
>
> Any ideas?
>
> Marshall
>
The problem is that a \ is used to escape things in ' quoted strings
$x = 'please dont\'t fail';
the \' escapes the single quote in a ' string
You need to escape the \ so that they do not escape the '
$path = 'c:\\home\\mysite\\cgi-bin\\';
$site = 'mysite';
------------------------------
Date: Thu, 14 Aug 2003 11:39:54 -0400
From: Shawn Corey <shawn@magma.ca>
Subject: Re: Bug in perl?
Message-Id: <OuycnUTTsbiaMKaiXTWJhg@magma.ca>
Marshall Dudley wrote:
> Perl 5.005_03 built for 386 freeBSD
>
> I am trying to get perl to work on a windows system for the first time,
> thus the path delimiters are \ instead of /. For some reason the
> following very simple code will not compile:
>
> $path = 'c:\home\mysite\cgi-bin\';
$path = 'c:\\home\\mysite\\cgi-bin\\';
> $site = 'mysite';
>
> The problem seems to be the trailing \ on line 1, but that is needed as
> part of the path so I can't leave it out.
>
> Any ideas?
>
> Marshall
>
------------------------------
Date: Thu, 14 Aug 2003 16:42:23 +0100
From: John Strauss <john.thetenant-s@moving-picture.com>
Subject: Re: Bug in perl?
Message-Id: <20030814164223.3d05e0b3.john.thetenant-s@moving-picture.com>
On Thu, 14 Aug 2003 10:02:20 -0400
Marshall Dudley <mdudley@execonn.com> wrote:
>
> Perl 5.005_03 built for 386 freeBSD
>
> I am trying to get perl to work on a windows system for the first time,
> thus the path delimiters are \ instead of /. For some reason the
> following very simple code will not compile:
>
> $path = 'c:\home\mysite\cgi-bin\';
> $site = 'mysite';
>
> The problem seems to be the trailing \ on line 1, but that is needed as
> part of the path so I can't leave it out.
>
> Any ideas?
>
> Marshall
>
use "/" path separators, even on windoze.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drop the .thetenant to get me via mail
------------------------------
Date: Thu, 14 Aug 2003 10:51:34 -0500
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: Bug in perl?
Message-Id: <slrnbjnc06.7g4.tadmc@magna.augustmail.com>
Marshall Dudley <mdudley@execonn.com> wrote:
> Perl 5.005_03 built for 386 freeBSD
^^^^^^^
^^^^^^^
> I am trying to get perl to work on a windows system for the first time,
^^^^^^^
^^^^^^^
So which is it?
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Thu, 14 Aug 2003 10:58:04 -0500
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: Bug in perl?
Message-Id: <slrnbjnccc.7g4.tadmc@magna.augustmail.com>
Marshall Dudley <mdudley@execonn.com> wrote:
> I am trying to get perl to work on a windows system for the first time,
> thus the path delimiters are \ instead of /.
You can use sensible slashes in most cases, even on Windows.
How are you going to be using $path?
If it is not destined for the command interpreter, then just
use forward slashes.
> For some reason the
> following very simple code will not compile:
>
> $path = 'c:\home\mysite\cgi-bin\';
The reason is because there is no ending delimiter for your string.
You have escaped the 2nd quote, meaning that the quote is part
of the data rather than part of the code.
> The problem seems to be the trailing \ on line 1, but that is needed as
> part of the path so I can't leave it out.
>
> Any ideas?
my $path = 'c:/home/mysite/cgi-bin/';
or
my $path = 'c:\home\mysite\cgi-bin\\';
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Thu, 14 Aug 2003 11:26:53 -0400
From: Marshall Dudley <mdudley@execonn.com>
Subject: Re: Bug in perl?
Message-Id: <3F3BAA3D.5E5FDF9E@execonn.com>
I am writing and testing on my unix system, then ftping up to my customer's
windows system to test on their system. The /path variable changes depending
on if I am testing on my system or the customer's system.
I will use forward slashes, since I never used perl on a windoz system
before, did not realize I could. Must be a substitution perl makes,
Microsoft would never allow something sensible like that to happen if it
could prevent it.
Marshall
Tad McClellan wrote:
> Marshall Dudley <mdudley@execonn.com> wrote:
>
> > I am trying to get perl to work on a windows system for the first time,
> > thus the path delimiters are \ instead of /.
>
> You can use sensible slashes in most cases, even on Windows.
>
> How are you going to be using $path?
>
> If it is not destined for the command interpreter, then just
> use forward slashes.
>
> > For some reason the
> > following very simple code will not compile:
> >
> > $path = 'c:\home\mysite\cgi-bin\';
>
> The reason is because there is no ending delimiter for your string.
>
> You have escaped the 2nd quote, meaning that the quote is part
> of the data rather than part of the code.
>
> > The problem seems to be the trailing \ on line 1, but that is needed as
> > part of the path so I can't leave it out.
> >
> > Any ideas?
>
> my $path = 'c:/home/mysite/cgi-bin/';
> or
> my $path = 'c:\home\mysite\cgi-bin\\';
>
> --
> Tad McClellan SGML consulting
> tadmc@augustmail.com Perl programming
> Fort Worth, Texas
------------------------------
Date: Thu, 14 Aug 2003 16:45:08 GMT
From: "Ian.H [dS]" <ian@WINDOZEdigiserv.net>
Subject: Re: Bug in perl?
Message-Id: <20030814174510.6d1d91b7.ian@WINDOZEdigiserv.net>
On Thu, 14 Aug 2003 11:26:53 -0400 in
<message-id:3F3BAA3D.5E5FDF9E@execonn.com>
Marshall Dudley <mdudley@execonn.com> wrote:
> I will use forward slashes, since I never used perl on a windoz
> system before, did not realize I could. Must be a substitution perl
> makes, Microsoft would never allow something sensible like that to
> happen if it could prevent it.
It does, although not very well:
cd ../
for example will work on windoze.. but:
cd ../../
will only recognise the first instance of '../' and therefore, only
backup one directory, rather than two.
If anyone has info to the contrary, I'd be interested in hearing it..
but this seemed to be the case for me, on a win2k box anyway.
Regards,
Ian
--
Ian.H [Design & Development]
digiServ Network - Web solutions
www.digiserv.net | irc.digiserv.net | forum.digiserv.net
Programming, Web design, development & hosting.
------------------------------
Date: Thu, 14 Aug 2003 12:01:52 -0500
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: Bug in perl?
Message-Id: <slrnbjng40.7lc.tadmc@magna.augustmail.com>
Marshall Dudley <mdudley@execonn.com> wrote:
> I will use forward slashes, since I never used perl on a windoz system
> before, did not realize I could. Must be a substitution perl makes,
perl is not doing anything to your data.
> Microsoft would never allow something sensible like that to happen if it
> could prevent it.
They have allowed it for many many years.
It is not Windows that insists on silly slashes, it is the
command interpretor ("DOS prompt") that insists, because
it is already using forward slashes for something else (switches).
[snip TOFU, please don't do that anymore]
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Thu, 14 Aug 2003 15:50:07 +0200
From: Tore Aursand <tore@aursand.no>
Subject: Re: finding subdirectories without parsing every file
Message-Id: <pan.2003.08.14.13.50.04.717674@aursand.no>
On Thu, 14 Aug 2003 00:45:26 -0700, Helen wrote:
> Is there any way to get the subdirectories of a directory without
> having to sort through all the files in a directory?
Why is it going slow? Maybe you could share some of your code with us, so
that we're able to actually know what you're talking about?
I tend to use the following code when "filtering out" directories;
#!/usr/bin/perl
#
use strict;
use warnings;
use File::Find;
my $root = '/home/tore';
my @dirs = ();
find sub { push(@dirs, $File::Find::name) if -d }, $root;
I guess there are faster ways to do it (as always), but this solution does
it for me.
--
Tore Aursand <tore@aursand.no>
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 5358
***************************************
