[18815] in Perl-Users-Digest
Perl-Users Digest, Issue: 983 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri May 25 00:10:49 2001
Date: Thu, 24 May 2001 21:10:13 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <990763813-v10-i983@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Thu, 24 May 2001 Volume: 10 Number: 983
Today's topics:
Re: Options for handling a configuration file (Eric Bohlman)
Re: parsing perl again (Craig Berry)
Re: parsing perl again (Damian Conway)
Re: perl tattoo <todd@designsouth.net>
Re: Problem with scalar variables (Scott DiNitto)
Re: Question on the "use strict" pragma (Eric Bohlman)
Re: Question on the "use strict" pragma <ahamm.NO$PAM@sanderson.NO$PAM.net.au>
Re: realpath(), abs_path() (Martien Verbruggen)
Re: Redirecting STDERR to sendmail (Martien Verbruggen)
Re: SET-UP (free) (Bob Moose)
Re: sounder <todd@designsouth.net>
Re: Who's Going to the Perl Conference in San Diego thi (Scott DiNitto)
Re: wwwboard.pl - Taint and Use Strict <AgitatorsBand@yahoo.com>
Re: XML::Simple more than one root tag?? (Martien Verbruggen)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 25 May 2001 01:24:29 GMT
From: ebohlman@omsdev.com (Eric Bohlman)
Subject: Re: Options for handling a configuration file
Message-Id: <9ekc8d$ln4$4@bob.news.rcn.net>
Tintin <somewhere@in.paradise.net> wrote:
> I'm looking at various options for handling a configuration file and would
> like some opinions.
> My config file looks something like:
> $base='/home/fred/html';
> $logdir="$base/logs";
> $reportdir="$base/logs";
> etc
> I have a CGI script to edit the configuration file. At the moment, I'm just
> doing something like:
> require "config.pl";
> print $query->textfield(-name=>'logdir',
> -default=>$logdir);
> The problem is that all of the variables that use $base will be expanded, so
> to update the base location, requires updating *every* variable.
> I was thinking that it would be better to ensure the variables don't expand,
> ie:
> $logdir will be displayed at $base/logs rather than /home/fred/html/logs
> At this stage, I'm not keen to change the format of the configuration file,
> but if that is my only option, then I'll do it.
Don't require the file; open it as a plain text file and parse it (you
don't have to do a full Perl parse if all the lines are of the form
$variable="quoted string with possible interpolations"; just split on the
equal sign (being sure to use the three-argument form of split in order to
avoid problems with equal signs in the quoted strings) and use substr() or
the like to get the parameter names).
However, I'd be *very* wary of using a CGI script to edit a file
consisting of executable Perl code. It's dangerous for the same reason
that placing the perl interpreter itself in your CGI directory is
dangerous; it allows anyone who can run the script to get your system to
run whatever Perl code they want. Taint checking won't help here.
------------------------------
Date: Fri, 25 May 2001 01:27:50 -0000
From: cberry@cinenet.net (Craig Berry)
Subject: Re: parsing perl again
Message-Id: <tgrd8mf5cf39bd@corp.supernews.com>
Randal L. Schwartz (merlyn@stonehenge.com) wrote:
: Will the new version of RecDescent implement Perl6, Solve the Halting
: Problem, or be self-aware?
It will be self-aware only if it halts when presented with itself as
input. :)
--
| Craig Berry - http://www.cinenet.net/~cberry/
--*-- "God becomes as we are that we may be as he is."
| - William Blake
------------------------------
Date: 25 May 2001 02:33:16 GMT
From: damian@cs.monash.edu.au (Damian Conway)
Subject: Re: parsing perl again
Message-Id: <9ekg9c$out$1@towncrier.cc.monash.edu.au>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "Damian" == Damian Conway <damian@cs.monash.edu.au> writes:
>>> P.S. I take it this implies your belief that RecDescent is capable of
>>> performing the monsterous task?
>Damian> Not as it stands. But a new version of RecDescent is also on
>Damian> the ToDo list!
>Will the new version of RecDescent implement Perl6, Solve the Halting
>Problem, or be self-aware?
It will, of course, be a superposition all of three. Unfortunately, the
Uncertainty Principle will mean that when you use the module you'll only
get one of those capacities (at random) at any one time.
Damian
------------------------------
Date: Fri, 25 May 2001 02:31:46 GMT
From: "Todd Smith" <todd@designsouth.net>
Subject: Re: perl tattoo
Message-Id: <mujP6.69139$I5.14620641@news1.rdc1.tn.home.com>
"Steven M. O'Neill" <steveo@panix.com> wrote in message
news:9ejb4p$sdb$3@news.panix.com...
> Todd Smith <todd@designsouth.net> wrote:
> >
> >"John Hall" <jhall@ifxonline.com> wrote in message
> >news:0xSO6.27782$vf6.2760109@news1.rdc1.sdca.home.com...
> >> If I got the 7 line perl DECSS code tattoo'ed on my chest, if I went to
> >the
> >> beach, would I be arrested by the feds?
> >>
> >
> >What if you do, then later there's a shorter way to do it using Perl6?
>
> Will 6 be available in jail?
> --
You could probably get the book, but you'd have to remove the first tattoo
first.
------------------------------
Date: Fri, 25 May 2001 03:11:43 GMT
From: usenet@infracore.dyndns.org (Scott DiNitto)
Subject: Re: Problem with scalar variables
Message-Id: <3b0dc7c6.256369326@news-server.san.rr.com>
>> Can anyone help me please?
>
>Yes, I will help you by refusing to tell you the correct syntax to
>achive what you ask :-)
Wow your quite the asshole huh?
He won't tell you, so I will (besides I don't think he has the time to
take away from his realdoll from realdoll.com)
If I understand you correctly, eval will work:
$variable = 3;
eval ("\@array$variable \= \("contents\"\);");
make sure that you terminate all special characters so they are not
evaluated by accident.
SD
------------------------------
Date: 25 May 2001 01:15:09 GMT
From: ebohlman@omsdev.com (Eric Bohlman)
Subject: Re: Question on the "use strict" pragma
Message-Id: <9ekbmt$ln4$3@bob.news.rcn.net>
In comp.lang.perl.misc Leo <leapius@hotmail.com> wrote:
> I have a few questions regarding the "use strict" pragma:
> 1. Does adding use strict to my program slow it's execution down in any way?
Nope. Its effects occur only at compile time, and the time taken for the
extra checks is negible compared to the I/O time the compiler spends
reading in your program.
> If so would it be a good idea to use strict when developing a program and
> then remove it when the code is final (so my code is syntatically correct),
> or would that be pointless?
It's been compared to putting on your seat belt in the garage and taking
it off when you get onto the road.
> 2. I am confused about how strict evaluates my code. I have a program which
> "requires" a lot of other cgi scripts in it's execution. Each of these
> scripts is a collection of sub-routines associated with a particular
> function. The main program is where all these scripts are called. I have the
> line "use strict" in this main program file and it evaluates the variables
> and so forth for the contents of that file.
> When I run my program, and it loads in the other cgi scripts (sub routines)
> during it's operation, the use strict pragma does not seem to extend into
> these other files. E.g. I have a load of sub-routines in a sepearte file
> which break all the use strict rules and yet it compiles and runs ok without
> any errors. Does the use strict pragma _only_ evaluate the code in the
> particular file it is called? How can it evaluate all my code in the other
> files?
It's file scoped.
> 3. Why does this give me errors:
> Main program file
> ====================================
> #!/usr/bin/perl
> use strict;
> require "settings.cgi";
> require "$sourcedir/subs.cgi";
> ====================================
> settings.cgi
> ====================================
> our $sourcedir = "./source";
> ====================================
> Shouldn't $sourcedir be declared as a global variable in the program when it
> is "required"?
It should be, but *you're* the one who has to declare it. "our" is file
scoped as well.
------------------------------
Date: Fri, 25 May 2001 12:16:55 +1000
From: "Andrew Hamm" <ahamm.NO$PAM@sanderson.NO$PAM.net.au>
Subject: Re: Question on the "use strict" pragma
Message-Id: <3b0dc0bc@news.iprimus.com.au>
Andrew Hamm wrote in message <3b0dadee$1@news.iprimus.com.au>...
>Try using "use module" instead, and check
>out the export and import options - they can be used to inject variables
and
>subs into the calling module.
>
Actually, I could be wrong about injecting variables - in the sense that it
becomes known to the compiler as well under use strict. Can't say I've
noticed.
But it's also well worth studying the
use vars qw($a $b $c);
pragma
--
"Dis act ain't about lafter - it's about comedy" - Andrew Dice Clay
------------------------------
Date: Fri, 25 May 2001 11:46:28 +1000
From: mgjv@tradingpost.com.au (Martien Verbruggen)
Subject: Re: realpath(), abs_path()
Message-Id: <slrn9grebk.v5e.mgjv@martien.heliotrope.home>
On Thu, 24 May 2001 11:44:22 -0700,
/dev/null <postmaster@god.edu> wrote:
> On 24 May 2001, at 17:55:46 +0100, nobull@mail.com wrote:
>
> What I want to use it for is to determine whether or not two
> different paths refer to the same file or directory. One option is
> to compare the filesystem and inode of each candidate. Another is to
That is, in fact, the only way you can do it on Unix (and much faster
than any of the other ways that try to resolve the 'real path name'.
If you use a pathname, then the only thing you can conclude is that if
the "canonicalised"[1] pathnames are identical, the files are identical.
The converse is not true, however. Two different paths can point to the same
file. And the only thing that will tell you they are identical is
inspection of the inode and device. Since you have to inspect the inode
and device anyway, you might as well start with that, and not bother
trying to get a 'real' path.
As mentioned before by someone else, there is hardly ever any real
reason to know the absolute canonicalised path.
If you're still not convinced: In shell scripts people often chdir to
the directory that contains the file (or to the directory itself if it
is one), and use /bin/pwd or an equivalent (not a builtin pwd). Of
course, Cwd::abs_path probably could be used as well.
inode + device is easy to get to, and what you seem to need anyway.
If you are thinking of storing the 'canonicalised' path for future
reference, I'd strongly advice against it. On any systems I maintain
that could break easily in the future. Some file systems on machines I
maintain move around regularly, depending on disk availability, changed
requirements, relocation to different NFS servers, and other reasons.
The canonical symlink that points to the relevant part of the file
system always is the same and available. That's the whole point of
having a symlink like that. Any software that uses canonicalised paths
(and I've had to work with a few commercial products like that) break as
soon as the file systems gets mounted at a different spot.
Martien
[1] by resolving relativity and symlinks.
--
Martien Verbruggen |
Interactive Media Division | Never hire a poor lawyer. Never buy
Commercial Dynamics Pty. Ltd. | from a rich salesperson.
NSW, Australia |
------------------------------
Date: Fri, 25 May 2001 12:07:29 +1000
From: mgjv@tradingpost.com.au (Martien Verbruggen)
Subject: Re: Redirecting STDERR to sendmail
Message-Id: <slrn9grfj1.v5e.mgjv@martien.heliotrope.home>
On Wed, 23 May 2001 07:35:18 +0200,
Philip Newton <pne-news-20010523@newton.digitalspace.net> wrote:
> On 22 May 2001 18:41:24 +0100, nobull@mail.com wrote:
>
>> You probably should unbuffer STDERR too.
>
> Why? It's usually unbuffered by default.
^^^^^^^
_If_ it is, indeed, only usually unbuffered, and not guaranteed to be
unbuffered, then you should probably unbuffer STDERR too, if you _need_
a guarantee that it is unbuffered.
The STDERR which is open by default on startup, is built on top of the C
stdio stderr, so you can pretty much assume that it will be unbuffered
(on any system that follows the ISO C spec).
\begin{facetious}
None of the above stops a program (possibly even Perl itself) from
changing the buffering of standard error after program startup, and I
can't find any guarantee in the Perl documentation that that actually
doesn't happen, and never will happen. Common sense dictates that it
won't change, and that it follows the C spec, but who knows.
I don't know whether there are any systems that Perl runs on that don't
by default have an unbuffered stderr, and whether Perl makes them
unbuffered if they aren't. The documentation is silent AFAICT.
And, of course, you have no guarantee that STDERR is actually still
connected to the same output device that Perl started up with, and in
that case you probably do want to unbuffer it. There's even code in the
select documentation that shows this.
\end{facetious}
Martien
--
Martien Verbruggen |
Interactive Media Division | Hi, Dave here, what's the root
Commercial Dynamics Pty. Ltd. | password?
NSW, Australia |
------------------------------
Date: 24 May 2001 19:27:31 -0700
From: yogibearxx@bobmoose.com (Bob Moose)
Subject: Re: SET-UP (free)
Message-Id: <4ec914b1.0105241827.5c96f927@posting.google.com>
Uri Guttman <uri@sysarch.com> wrote in message news:<x7itis6dyd.fsf@home.sysarch.com>...
> >>>>> "BM" == Bob Moose <yogibearxx@bobmoose.com> writes:
>
> BM> Uri Guttman <uri@sysarch.com> wrote in message news:<x7elti6nuv.fsf@home.sysarch.com>...
> BM> Well, I'll ask again. Can somebody?
> >>
> >> i will (for my definition of free which may not be yours. :)
>
> BM> And what's your defenition of free?
>
> not yours.
>
> uri
WHAT IS IT
------------------------------
Date: Fri, 25 May 2001 02:28:55 GMT
From: "Todd Smith" <todd@designsouth.net>
Subject: Re: sounder
Message-Id: <HrjP6.69109$I5.14617383@news1.rdc1.tn.home.com>
"Thorbjørn Ravn Andersen" <thunderbear@bigfoot.com> wrote in message
news:3B0D9B81.96A0CB58@bigfoot.com...
> Todd Smith wrote:
>
> > > > Well, since Perl is the only cgi language I know, I'd like to see
the
> > Perl
> > > > implementation of the complete solution.
> > >
> > > Hack the "user sign up" script to send you an email.
> > >
> >
> > Emails are boring! I want noise!
>
> Hack your emailprogram to treat "user sign up" mail specially.
>
> How were you expecting to get your browser to say the noise you want?
>
> --
I don't know! That's why I asked.
------------------------------
Date: Fri, 25 May 2001 03:18:55 GMT
From: usenet@infracore.dyndns.org (Scott DiNitto)
Subject: Re: Who's Going to the Perl Conference in San Diego this year?
Message-Id: <3b0ece47.258034684@news-server.san.rr.com>
Where is it, I just moved here.
SD
On Wed, 23 May 2001 22:07:26 GMT, "Dave" <djm@spamfree.mcoe.k12.ca.us>
wrote:
>hmm?
>
>http://conferences.oreilly.com/perl/
>
>
>I'm going and perhaps might wanna hook up with some of you guys, provided
>you arnt mental...
>
>
>
------------------------------
Date: Fri, 25 May 2001 03:01:38 GMT
From: Scratchie <AgitatorsBand@yahoo.com>
Subject: Re: wwwboard.pl - Taint and Use Strict
Message-Id: <mWjP6.239$aG6.21037@news.shore.net>
Uri Guttman <uri@sysarch.com> wrote:
: someone posted he got that POS to be -w and -T clean. but he hasn't
: posted it yet. and i bet it will still be a piece of shit.
Gee, thanks for the vote of confidence. I'm sure lots of your code that
I've never seen before sucks ass too.
--Art
------------------------------
Date: Fri, 25 May 2001 11:54:31 +1000
From: mgjv@tradingpost.com.au (Martien Verbruggen)
Subject: Re: XML::Simple more than one root tag??
Message-Id: <slrn9greqn.v5e.mgjv@martien.heliotrope.home>
On 23 May 2001 04:29:15 -0700,
Sascha <tgyeti@web.de> wrote:
> Thorbjørn Ravn Andersen <thunderbear@bigfoot.com> wrote in message news:<3B0A587B.80883567@bigfoot.com>...
>> Sascha wrote:
[post shortened]
>> > If the image have a syntax like ...
>> > <?xml version="1.0" encoding="ISO-8859-1" standalone="yes" ?>
>> >
>> > <mail>
>> > </mail>
>> > <ebene>
>> > </ebene>
>> >
>> > ... then i receive a error. This is the error:
>>
>> Naturally. This is not a valid XML file.
>
> OK, but why I not get the root (<mail> or <ebene>) not back into the hash????
Because XML documents can only have one root node. That is what the
error is about. Since your document isn't even valid, what would you
expect the parser to do?
Before you start work with XML, you should learn a bit about it. Wander
off to www.w3c.org, and start reading.
If you need to have both the above nodes in one XML document, wrap it in
a container node:
<dummy>
<mail>...</mail>
<ebene>...</ebene>
</dummy>
and then work with the children of that container.
Oh, and in the future, if you have a question about Perl, post here. If
you have a question about XML, which this clearly is, please find a more
appropriate group.
Martien
--
Martien Verbruggen |
Interactive Media Division |
Commercial Dynamics Pty. Ltd. | Curiouser and curiouser, said Alice.
NSW, Australia |
------------------------------
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 983
**************************************
