[23960] in Perl-Users-Digest
Perl-Users Digest, Issue: 6161 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Feb 19 00:05:44 2004
Date: Wed, 18 Feb 2004 21:05:08 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 18 Feb 2004 Volume: 10 Number: 6161
Today's topics:
Re: Beginner question on @INC <tadmc@augustmail.com>
Re: Beginner question on @INC <tadmc@augustmail.com>
Re: Beginner question on @INC <spamtrap@dot-app.org>
Re: Beginner question on @INC <root@nowhere.com>
Re: Beginner question on @INC <root@nowhere.com>
Caching DBI 'prepare' statements for re-use with an Apa <dcspam@ntlworld.com>
Re: Caching DBI 'prepare' statements for re-use with an <spamtrap@dot-app.org>
Re: Caching DBI 'prepare' statements for re-use with an <usenet@morrow.me.uk>
Re: Caching DBI 'prepare' statements for re-use with an <spamtrap@dot-app.org>
Re: can s/// return a new value, rather than modifying (Bill Keese)
Re: Case-insensitive match for File::Find <jurgenex@hotmail.com>
Re: CGi parameters lost <turajbNOSPAM@hoflink.com>
Re: CGi parameters lost <philconners90210@yahoo.com>
compressing data files/directories <nospam@spamfree.dud>
Re: compressing data files/directories <usenet@morrow.me.uk>
Re: Getopt::Long and <> problem <invalid-email@rochester.rr.com>
how can a daemon output to console (Jason Chan)
Re: Matching quoted strings <invalid-email@rochester.rr.com>
Re: more stripping <noreply@gunnar.cc>
Re: more stripping <jurgenex@hotmail.com>
Re: newbie: inheritance (Anno Siegel)
Re: newbie: inheritance <pobugfix@peterlink.ru>
Replacing all "special characters" with code (Mike)
Re: Replacing all "special characters" with code <usenet@morrow.me.uk>
Re: testing for directories/files fails <tadmc@augustmail.com>
Re: understanding perl "get ($url) " function (KK)
Re: understanding perl "get ($url) " function <uri@stemsystems.com>
Re: Why is Perl losing ground? <spamtrap@dot-app.org>
your partner <bobsmith@[don't-even-think-about-it]jippii.fi>
Re: your partner <rmarkoff@msn.com>
Re: your partner <bobsmith@[don't-even-think-about-it]jippii.fi>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 18 Feb 2004 21:21:21 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Beginner question on @INC
Message-Id: <slrnc38ath.1fq.tadmc@magna.augustmail.com>
Geedunk <root@nowhere.com> wrote:
^^^^
^^^^
> I am learning Perl (and Linux),
Don't do things as the superuser unless those things *require*
that you be the superuser.
Posting/reading Usenet does not require that you be the superuser.
And when you _are_ being the superuser, be afraid, you can
do serious damage. Do what you gotta do, and switch back to
a regular user account as soon as possible.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Wed, 18 Feb 2004 21:26:14 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Beginner question on @INC
Message-Id: <slrnc38b6m.1fq.tadmc@magna.augustmail.com>
Geedunk <root@nowhere.com> wrote:
[missing attribution(s) should be here]
>>> say "Avoid unnecessary additions to the @INC variable which may slow
>>> access time..." and so forth.
>>
>> Wha...? This is pretty much nonsense: any loss is trivial.
>
> Well, all I can say is that my books
What books do you have?
There are a lot of bad ones. More bad ones than good ones.
Tell us what you've got, and we'll tell you what you've got. :-)
> say that
^^^^
Got a title and page number?
> and at this point in my
> learning curve I am certainly not qualified to say that a Perl book author
> is wrong.
Many (most?) Perl book authors are wrong.
There are plenty of good Perl books, but there are more
not-so-good Perl books...
>>> want to make any changes till I understand it some more.
Tell us where you saw it, so that we can see it, and we'll tell
you what we think of it.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Wed, 18 Feb 2004 22:59:39 -0500
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: Beginner question on @INC
Message-Id: <oLadnVkouYY2qandRVn-vw@adelphia.com>
Tad McClellan wrote:
> Geedunk <root@nowhere.com> wrote:
> Posting/reading Usenet does not require that you be the superuser.
Careful with that axe, Eugene... Configuring your news reader with a return
address of "root@nowhere.com" doesn't require that you be the superuser,
either. ;-)
sherm--
------------------------------
Date: Wed, 18 Feb 2004 20:55:22 -0600
From: "Geedunk" <root@nowhere.com>
Subject: Re: Beginner question on @INC
Message-Id: <pan.2004.02.19.02.55.20.922865@nowhere.com>
> It's really not considered polite here to post a question that's
> answered in the standard documentation, so I'd recommend becoming
> familiar with the included Perl documentation. Start with 'perldoc
> perl', and work your way out from there. Pay particular attention to
> 'perldoc -f' and 'perldoc -q', as 80% of the problems you will have can
> be answered by consulting those two oracles, but you'll want to at least
> have a cursory knowledge of what information is covered where.
Thank you for your help, and I almost never ask a question unless I am
obviously stuck since I have long since found that the knowledge learned
the hard way stays the longest.
And, I admit that I had completely forgotten about the Perldoc stuff
delivered with the system and was depending on googling for stuff that I
couldn't find in my books.
However, I (respectfully) think that you are falling into the usual
thought routine of someone familiar with the ground. While delivered
documentation is invaluable to someone who is fairly familiar with what he
is trying to do, some of the man pages and docs might as well be written
in South Martian for all the good they do a beginner.
I suspect that if you yourself pick a topic that you know absolutely
nothing about and try to get bootstrapped from the written-for-techie man
pages, you will also wonder what the heck the writer was drinking when
he/she wrote the stuff. You may have a different opinion.
Anyway, I have found that if I remove 5.8.0 completely and then install
5.8.1 it works. (I can't install 5.8.3 till I get to a system that is
faster than my 26k dialup). If I install 5.8.1 over the top of 5.8.0 I
get the @INC problem. So, I can fix the problem - I just don't quite
understand it yet.
Thank you
Geedunk
------------------------------
Date: Wed, 18 Feb 2004 21:00:36 -0600
From: "Geedunk" <root@nowhere.com>
Subject: Re: Beginner question on @INC
Message-Id: <pan.2004.02.19.03.00.34.841595@nowhere.com>
> Don't do things as the superuser unless those things *require*
> that you be the superuser.
>
> Posting/reading Usenet does not require that you be the superuser.
>
> And when you _are_ being the superuser, be afraid, you can
> do serious damage. Do what you gotta do, and switch back to
> a regular user account as soon as possible.
I don't understand what you are talking about. I am on as a standard
user, not as root. (I'm not quite that newbie:-) Besides, how would you
know how I am logged in - is my setup THAT transparent to everybody???!!!
Geedunk
------------------------------
Date: Thu, 19 Feb 2004 02:19:38 -0000
From: "Dave Cardwell" <dcspam@ntlworld.com>
Subject: Caching DBI 'prepare' statements for re-use with an Apache server
Message-Id: <K2VYb.3412$AQ4.1049243@newsfep2-win.server.ntli.net>
Hello.
Is there any way to cache the statement handles returned by prepare or
perhaps prepare_cached across scripts when using the DBI module?
Specifically I'd like to re-use a few of my queries with placeholders across
multiple calls to CGI scripts. I've looked at the documentation for
Apache::DBI and it didn't mention the caching of prepares, so I guess that
doesn't do it.
I'd rather not have to hard-code my common prepare statements anywhere
if possible.
Regards,
--
Dave Cardwell
http://dave.blubbernet.com
------------------------------
Date: Wed, 18 Feb 2004 22:49:36 -0500
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: Caching DBI 'prepare' statements for re-use with an Apache server
Message-Id: <oLadnV4ouYbPr6ndRVn-vw@adelphia.com>
Dave Cardwell wrote:
> Is there any way to cache the statement handles returned by prepare or
> perhaps prepare_cached across scripts when using the DBI module?
Sure. Just declare a package-scoped variable to hold it using either 'use
vars' or 'our' - 'our' is preferred, unless you're working on a very old
Perl where it isn't supported.
Then simply assign it with:
$sth ||= prepare(...);
That's a shortcut for:
$sth = ($sth || prepare(...) );
Perl is lazy (in a good way) with regard to logical ORs; it bails out upon
finding the first true clause. So, if $sth is already defined it doesn't
call prepare().
You can use this technique in many other ways, too. I've found it *very*
useful when working with XSLT objects, as parsing the style sheet and
creating the transformer object is relatively expensive.
sherm--
------------------------------
Date: Thu, 19 Feb 2004 04:18:26 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: Caching DBI 'prepare' statements for re-use with an Apache server
Message-Id: <c11dei$sna$3@wisteria.csv.warwick.ac.uk>
Sherm Pendley <spamtrap@dot-app.org> wrote:
> Dave Cardwell wrote:
>
> > Is there any way to cache the statement handles returned by prepare or
> > perhaps prepare_cached across scripts when using the DBI module?
^^^^^^^^^^^^^^
> Sure. Just declare a package-scoped variable to hold it using either 'use
> vars' or 'our' - 'our' is preferred, unless you're working on a very old
> Perl where it isn't supported.
You missed the important bit.
Ben
--
It will be seen that the Erwhonians are a meek and long-suffering people,
easily led by the nose, and quick to offer up common sense at the shrine of
logic, when a philosopher convinces them that their institutions are not based
on the strictest morality. [Samuel Butler, paraphrased] ben@morrow.me.uk
------------------------------
Date: Wed, 18 Feb 2004 23:59:17 -0500
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: Caching DBI 'prepare' statements for re-use with an Apache server
Message-Id: <aL-dndSrhfM636ndRVn-ug@adelphia.com>
Ben Morrow wrote:
> You missed the important bit.
Ouch. Yep, I did.
The technique is still valid - although the details are different. To share
the variable across multiple scripts, you need to refer to it by its fully
qualified name, including the package its in.
Something like:
$MyCachePackage::sth ||= prepare(...);
The OP mentioned Apache::DBI, but he also mentioned CGI, so I suppose I
should also point out that I'm assuming a mod_perl environment.
sherm--
------------------------------
Date: 18 Feb 2004 18:05:35 -0800
From: wkeese@yahoo.com (Bill Keese)
Subject: Re: can s/// return a new value, rather than modifying it's input argument?
Message-Id: <96e8d2d9.0402181805.4984ee8b@posting.google.com>
Thanks to everyone that replied! Yes, I wanted s/// to work like a
function. The replace() or more general apply() functions seem to do
the trick.
Why did I want this?
1) it's inelegant to make a temporary variable just to call a
function.
(my $temp = $letter) =~ s/Mister/Mr./;
myFunction($temp); # or "print $temp;"
2) The syntax
(my $temp = $letter) =~ s/Mister/Mr./;
might be difficult for non-perl users to understand. Of course, the
advantage is that it is idiomatic perl.
Bill
------------------------------
Date: Thu, 19 Feb 2004 03:15:18 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: Case-insensitive match for File::Find
Message-Id: <aTVYb.23582$5W3.1019@nwrddc02.gnilink.net>
Prabh wrote:
> Just wanted to check if theres a 'case-insensitive' option while
> searching for an element using File::Find. I'm going through the
> module docs and cant see any mention to case-sensitivity.
Well, the docs state that
" The wanted() function does whatever verifications you want."
So just write your wanted() function in such a way that it returns 1 iff the
current file name matches the searched-for file name in whatever way you
define "match".
Show us the code for your wanted() function.
Then we may be able to figure out why your code isn't working the way you
expect it to work.
jue
------------------------------
Date: Thu, 19 Feb 2004 04:40:55 GMT
From: "James" <turajbNOSPAM@hoflink.com>
Subject: Re: CGi parameters lost
Message-Id: <r7XYb.9690$kj.6028724@news4.srv.hcvlny.cv.net>
"Phil Connors" <philconners90210@yahoo.com> wrote in message
news:40330258.5060908@yahoo.com...
> James wrote:
> > "Damu Zhang" <damu@wharton.upenn.edu> wrote in message
> > news:c0tjl7$6u1m$1@netnews.upenn.edu...
> >
> >>We are having a CGI issue, our clients send parameters via form POST,
but
> >>sporadically the values turn be to empty, and it happened all of sunden
> >>since early last week. Anyone has the same issue?
> >>
> >
> >
> > Yeah, see it all the time where I work... Bet you are using IE & you
have
> > installed that latest IE cumulative security upgrade patch [Released
early
> > Feb '04]. We have found that a side effect of this patch is sporadic
posts
> > where no data is made. In some case it appears the connection times out
by
> > the browser immediately after clicking the button. Don't seem to know a
way
> > around it; but know how to suppress it effect in some windows systems.
> > Netscape browsers is unaffected, just IE users after they installed that
new
> > patch...
>
> Even though this post got toasted a bit earlier, I'm glad you responded as
you did. I have
> a client who about once every two months has an order with incomplete
information.
> In a way that it could not be the customer who is messing it up. If this
is not the
> answer, it's a very good clue.
>
> Thanks for the post.
>
> cheers
>
With additional research time today by our staff today has located an
offical Microsoft patch which fixes this IE issue. It apears it was
released on 02/07/04. After extensive testing of the patch, we have foudnt
his patch doe sinfact work to fix the issue.
Here is what we are sending out to our known clients which have this
problem.
---------------------------------------------------------------------
As currently known, the new IE patch [Cumulative Security Update for
Internet Explorer (KB832894)] which released in early Feb '04 may cause
faults in some user's IE browsers when working with our SSL secure servers.
The identified issue causes errors when Internet Explorer attempts to renew
a connection to a server. Typically seen when doing a POST to a CGI script,
but it does not send any data to our SSL secured servers. You should apply
the below patch if you receive errors connecting to our servers after you
have applied the Q832894 security update to Internet Explorer or if you are
seeing unusual behavior in our secured administration areas.
The patch can be downloaded from:
http://www.microsoft.com/downloads/details.aspx?FamilyId=254EB128-5053-48A7-8526-BD38215C74B2&displaylang=en
In addition, for maximum compatibility with our system, we recommend that
you set the following in IE before applying the above patch to resolve
most common IE browser issues.
Microsoft's patches for Internet Explorer may have altered the browser's
security settings. You should do the following to reset them:
- open IE,
- click Tools
- click Internet Options.
In the 'Security' tab, reset the levels for each zone to the program's
default. This is done by clicking a zone icon & then clicking the 'Default
Level' button. Repeat for each zone icon.
The zone levels should look like this when you are done:
Internet - medium
Local intranet - medium-low
Trusted sites - low
Restricted sites - high
In the 'Privacy' tab, reset level to the program's default. This is done by
clicking the 'Default' button. This should set the slider to medium.
In the 'Advanced' tab, at the bottom of that window, all check boxes should
be checked under
Security section, except for "Do not save encrypted pages to disk", "Empty
Temporary Internet Files folder when browser is closed", and optionally
"Warn if changing between secure and not secure mode".
Be sure to click "Apply" and then "OK".
Reboot the computer so the full changes can take effect.
---------------------------------------------------------------------
This should fix your issue in full. It has for all of our customers thus
far & with our windows desktops at work.
--
James
turajbNOSPAM@hoflink.com
(Remove NOSPAM When Emailing)
------------------------------
Date: Thu, 19 Feb 2004 04:55:13 GMT
From: Phil Conners <philconners90210@yahoo.com>
Subject: Re: CGi parameters lost
Message-Id: <RkXYb.27539$Up2.22195@newssvr25.news.prodigy.com>
James wrote:
> "Phil Conners" <philconners90210@yahoo.com> wrote in message
> news:40330258.5060908@yahoo.com...
> With additional research time today by our staff today has located an
> offical Microsoft patch which fixes this IE issue. It apears it was
> released on 02/07/04. After extensive testing of the patch, we have foudnt
> his patch doe sinfact work to fix the issue.
> This should fix your issue in full. It has for all of our customers thus
> far & with our windows desktops at work.
Thanks for the update!
I just got another call today from this client complaining that part of the data to a
transaction was missing. I plan on talking with him about an email to all clients.
Thanks again!
- Way OT, Way helpful. You put the misc in comp.lang.perl.MISC!
------------------------------
Date: Thu, 19 Feb 2004 03:43:56 GMT
From: Sean O'Dwyer <nospam@spamfree.dud>
Subject: compressing data files/directories
Message-Id: <nospam-42345C.22503618022004@nyctyp02-ge0.rdc-nyc.rr.com>
I use file::copy to make backup copies of files (text, flat files). What
is the recommended module for compressing files or a directory full of
files and nested directories?
Thanks,
Sean
------------------------------
Date: Thu, 19 Feb 2004 04:17:31 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: compressing data files/directories
Message-Id: <c11dcr$sna$2@wisteria.csv.warwick.ac.uk>
Sean O'Dwyer <nospam@spamfree.dud> wrote:
> I use file::copy to make backup copies of files (text, flat files). What
> is the recommended module for compressing files or a directory full of
> files and nested directories?
Compress::Zlib, Archive::Tar, maybe Archive::Zip.
Ben
--
And if you wanna make sense / Whatcha looking at me for? (Fiona Apple)
* ben@morrow.me.uk *
------------------------------
Date: Thu, 19 Feb 2004 02:23:26 GMT
From: Bob Walton <invalid-email@rochester.rr.com>
Subject: Re: Getopt::Long and <> problem
Message-Id: <40341D54.50104@rochester.rr.com>
Daniel Berger wrote:
> Hi all,
>
> Perl 5.8.3
> Solaris 9
>
> I'm trying to use the <> operator in Getopt::Long to call a sub when
> an unknown option occurs. However, it doesn't seem to work. I read
I think you misinterpreted the Getopt::Long docs. They say:
"A special option 'name' <> can be used to designate a subroutine to
handle non-option arguments."
-------^^^^^^^^^^^^^^^^^^^^
Something like --foo looks like an option argument. Something like foo
does not look like an option argument. Try your code with:
perl getopttest.pl foo
and see what you get.
...
--
Bob Walton
Email: http://bwalton.com/cgi-bin/emailbob.pl
------------------------------
Date: 18 Feb 2004 20:24:45 -0800
From: jason@sted.minidns.net (Jason Chan)
Subject: how can a daemon output to console
Message-Id: <5eee3998.0402182024.1f32a463@posting.google.com>
Dear all,
I am using the Proc::Daemon module to make my script run in the
background. When there is a critical error, I want to output a error
message to the user so that he can *see* it. I tried the following but
doesn't work:
print STDERR "FATAL Error message";
Any idea?
TIA,
Michael Fung
------------------------------
Date: Thu, 19 Feb 2004 02:46:12 GMT
From: Bob Walton <invalid-email@rochester.rr.com>
Subject: Re: Matching quoted strings
Message-Id: <403422A8.5040000@rochester.rr.com>
Ben Morrow wrote:
> see@sig.invalid wrote:
>
>>Ben Morrow wrote:
>>
>>>That is the point of the *? minimal matching: not to match any "s other
>>>than those intended.
>>>
>>Yes, but /"(.*?)$"/ will match the entirity of the OP's string,
>>regardless of the lack of greediness of the .*? .
>>
>
> Err... probably not why you think it does, though. This interpolates $",
> normally blank.
Oh, sorry: /"(.*?)"$/ is what I meant. *That* one will match the
entirety of the OP's string.
>
> Ben
>
>
--
Bob Walton
Email: http://bwalton.com/cgi-bin/emailbob.pl
------------------------------
Date: Thu, 19 Feb 2004 03:21:55 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: more stripping
Message-Id: <c117ea$1c2ig3$1@ID-184292.news.uni-berlin.de>
Eric Schwartz wrote:
> So you're encouraging people to try something that they're very
> likely to get wrong, and that you don't know of any clear
> documentation telling them how to do right. Um, okay.
I'm not encouraging anybody to do anything if they don't know what
they're doing. I agree that CGI.pm is the natural first choice for
parsing CGI data, and when newbies post their first attempts to CGI
scripts, I too advocate that they use CGI.pm.
Again, I posted in this thread because security aspects were mentioned
in such a way that you falsely could get the impression that using
CGI.pm automatically takes care of them. If those comments hadn't been
posted, I would have kept my mouth shut this time. ;-)
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Thu, 19 Feb 2004 03:18:46 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: more stripping
Message-Id: <qWVYb.23601$5W3.22668@nwrddc02.gnilink.net>
Michael Hill wrote:
>>> Can anyone talk to what security holes may be there?
>>
>> Google may be very educational (hint: this topic has been discussed
>> a few times before).
>
> I'm not asking for a comprehensive listing of security holes using
> cgi, but rather inherent security holes because I am using *hand
> rolled* cgi instead of the cgi module.
Why the heck are you stealth-CC'ing me? I replied to your email directly.
Now, Usenet ettiquette dictates that you post a summary of the replies you
got via email. I am waiting for this summary.
jue
------------------------------
Date: 19 Feb 2004 02:24:00 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: newbie: inheritance
Message-Id: <c116o0$p9h$1@mamenchi.zrz.TU-Berlin.DE>
Andrew V. Tkachenko <pobugfix@peterlink.ru> wrote in comp.lang.perl.misc:
> Hello.
> I'm a bit confused with the following problem:
>
> Lets pretend that I have three modules:
[lots of code snipped]
Please reduce your problem to a small example. You presented much more
code than most people will want to read in a usenet posting.
> Now I need to add more functionality to myDaemon package: I
> need to track all requests and store them in some way
> I think about overload myDaemon 'request' method:
You mean "override". "Overload" is something else.
> ##########################
> package myLogDaemon;
>
> use strict;
> use myDaemon;
> our @ISA = qw/myDaemon/;
>
> sub request {
> my $self = shift;
> # dogin some logging
> return $self->SUPER::request(@_);
> }
> ###########################
>
> But. How can I call myDaemon::Socket::INET->new in a way wich will let
> me use overloaded 'request' method ?
You call the "new" method through inheritance from your subclass. When you
create an object as
my $dem = MyLogDemon->new( ...);
it calls, through inheritance, myDaemon::Socket::INET::new, which creates
a MyLogDemon object (not a myDaemon::Socket::INET object). It (the
created object) will use all of the inherited methods, except for the
overridden "request".
That is why a good "new" method painstakingly keeps track of the
calling package, instead of blindly blessing into its own. Your
own "new" method(s) (which I snipped) do that.
> Seems like I'm absolutely wrong with OO Perl but can't imagine
> how to solve this problem :(
Not "absolutely wrong", but you seem to be missing a link about inheritance.
Anno
------------------------------
Date: Thu, 19 Feb 2004 05:43:10 +0300
From: "Andrew V. Tkachenko" <pobugfix@peterlink.ru>
Subject: Re: newbie: inheritance
Message-Id: <c117ro$m5l$1@news.rol.ru>
Thanks for your reply, Anno.
I'm still confused with this thing.
Anno Siegel wrote:
> Andrew V. Tkachenko <pobugfix@peterlink.ru> wrote in comp.lang.perl.misc:
>
>>Hello.
>>I'm a bit confused with the following problem:
>>
>>Lets pretend that I have three modules:
>
>
> [lots of code snipped]
>
> Please reduce your problem to a small example. You presented much more
> code than most people will want to read in a usenet posting.
Ok, in a short terms:
1. I have base class myDaemon;
myDaemon
wich has dumb method 'send_request':
sub myDaemon::send_request {}
and non-empty 'request' method:
sub myDaemon::request {}
2. I have two classes wich inherit myDaemon class:
myDaemon::Socket::INET
myDaemon::Socket::UNIX;
each class define its own 'send_request' method
sub myDaemon::Socket::INET::send_request {}
sub myDaemon::Socket::UNIX::send_request {}
3. I can get an instance of myDaemon using either calling
myDaemon::Socket::INET->new
or
myDaemon::Socket::UNIX->new
4. I have another class: myLogDaemon wich inherits from myDaemon and
overrides its 'request' method
>
>
> You call the "new" method through inheritance from your subclass. When you
> create an object as
>
> my $dem = MyLogDemon->new( ...);
>
> it calls, through inheritance, myDaemon::Socket::INET::new, which creates
> a MyLogDemon object (not a myDaemon::Socket::INET object). It (the
> created object) will use all of the inherited methods, except for the
> overridden "request".
But MyLogDemon->new will return object of myDaemon class. It knows
nothing about myDaemon::Socket::INET and myDaemon::Socket::UNIX classes.
Q: I can't imagine how I can get an instance of myLogDaemon calling
::INET->new or ::UNIX->new constructors, because
Thanks for advance,
Andrew.
------------------------------
Date: 18 Feb 2004 19:32:06 -0800
From: csdude@hotmail.com (Mike)
Subject: Replacing all "special characters" with code
Message-Id: <46cdc619.0402181932.3eeed84e@posting.google.com>
I'm currently changing all of my "special characters," like &, ",
whitespace, etc to their HTML counterparts manually (& "
$nbsp;). The problem is, there could be several that I'm forgetting.
Is there a faster way to transfer all of these characters at once?
On a similar note, any thoughts on a good replacement for a single
quote? I'm using ´, but it's not quite the same.
TIA,
Mike
------------------------------
Date: Thu, 19 Feb 2004 04:16:34 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: Replacing all "special characters" with code
Message-Id: <c11db2$sna$1@wisteria.csv.warwick.ac.uk>
csdude@hotmail.com (Mike) wrote:
> I'm currently changing all of my "special characters," like &, ",
> whitespace, etc to their HTML counterparts manually (& "
> $nbsp;). The problem is, there could be several that I'm forgetting.
>
> Is there a faster way to transfer all of these characters at once?
I usually use
s/&/&/g;
s/"/"/g;
s/</</;
s/>/>/;
s/([^[:ascii:]])/sprintf '&#x%04X;' ord $1/ge;
> On a similar note, any thoughts on a good replacement for a single
> quote? I'm using ´, but it's not quite the same.
Err, no, they're completely different. The correct replacement is
', but replacement is not necessary and IIRC some versions of IE
don't correctly recognize it.
Ben
--
And if you wanna make sense / Whatcha looking at me for? (Fiona Apple)
* ben@morrow.me.uk *
------------------------------
Date: Wed, 18 Feb 2004 21:43:21 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: testing for directories/files fails
Message-Id: <slrnc38c6p.1fq.tadmc@magna.augustmail.com>
gnari <gnari@simnet.is> wrote:
> "Ravi Parimi" <parimi@none.nowhere.com> wrote in message
> news:Pine.GSO.4.58.0402181630380.20663@shelltoe.ece.arizona.edu...
>> > foreach my $ls (readdir DH) {
>> > next if -d $ls;
hint0: read the documentation for the function that you are using:
perldoc -f readdir
If you're planning to filetest...
> hint: what is the current directory?
> hint2: FAQ
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 18 Feb 2004 19:23:49 -0800
From: kewlkarun@yahoo.com (KK)
Subject: Re: understanding perl "get ($url) " function
Message-Id: <c8fd5039.0402181923.a38cf5b@posting.google.com>
Hello everyone, needless to say I'm greatly indebted to everyone who
have given their valuable suggestions here. I DID IT FINALLY ! I used
LWP::UserAgent for the purpose of saving & resending the cookie. I'm
so glad that many hours of labour work is cut down to just an hour
duration of simulation work. perl programming rocks!
Gleixner! dude! :)! please! I did not say CPAN does not have
modules/documentation for "cookies" - I meant a different
thing...nevermind.
>>From: J. Gleixner (glex_nospam@qwest.invalid)
>>You actually looked on CPAN for "cookies" and didn't find
anything???
>>How odd.. :-)
I did not have to try mechanize. Useragent did the job for me.
>>>what about www::mechanize? have you tried that?
Uri Guttman <uri@stemsystems.com> wrote in message news:<x73c98t7y9.fsf@mail.sysarch.com>...
> >>>>> "K" == KK <kewlkarun@yahoo.com> writes:
>
> K> Thank you one & all, for the ideas. In my previous missive, as I
> K> mentioned, the problem I'm facing is the 'login concurrency'. I could
> K> conclude that the site is keeping track of my navigation through
> K> cookies. One of the replies, suggested to save/resend the cookie
> K> through get($url) function. Apparently CPAN/other documentation of
> K> get($url) I've referred, does not contain any such feature. Now my
> K> question boils down to implentation of save/resend of cookies with
> K> modules get($url) & getstore($url,$filename) (my program uses both).
> K> I'm a newbie to perl programming and would like to request for a
> K> little detailed explaination. Thank you fellow-perls.
>
> it is in LWP::UserAgent. get and getstore are only in LWP::Simple and as
> that name implies, it doesn't support fancier stuff like using cookies.
>
> and if you want to make your life much easier, use WWW::Mechanize which
> will do the cookies, fetching, and parsing all for you in one nice clean
> api. it is designed to do what you are attempting.
>
> uri
------------------------------
Date: Thu, 19 Feb 2004 04:48:35 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: understanding perl "get ($url) " function
Message-Id: <x7r7wrr7x8.fsf@mail.sysarch.com>
>>>>> "K" == KK <kewlkarun@yahoo.com> writes:
<don't top post. read the group guidelines which are posted regularly>
K> I did not have to try mechanize. Useragent did the job for me.
it will still save you much coding. but what do i care about saving you
work?
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Wed, 18 Feb 2004 22:22:47 -0500
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: Why is Perl losing ground?
Message-Id: <eY-dnQ8E15CUsandRVn-jw@adelphia.com>
Uri Guttman wrote:
> it is not subjective. no one uses it and no one recommends it
> (regardless of the slowdown bug). it is there for show and not use.
Pointing out the availability of an option is not the same as recommending
it. In fact, I don't use English in my own code.
The post I originally replied to was criticizing Perl for its terseness, and
implied that the short forms were the only ones available. That's simply
not true - the longer forms are an available and supported option.
It's important to distinguish what's acceptable to the community vs. what's
allowed by the language. The fact that the Perl *community* has mostly
chosen to use a very terse style is a matter of fashion; it has nothing to
do with what is allowed by the Perl *language*. (I realize I'm using the
term "language" rather loosely here, in that English.pm is part of the core
distribution, but not part of the core language...)
Having said that, I do agree that it's worth keeping community standards in
mind if you're writing code that will be shared with the community - "when
in Rome, do as the Romans do" and all that. And obviously, if your employer
has an established set of guidelines, you'll need to follow them.
On the other hand, what consenting adults do in the privacy of their own
code is another matter entirely. If they want to shout their variable
names, Perl will let them do that. It will even indulge their fetish to the
extent of shouting back at them, if that's what they want.
sherm--
------------------------------
Date: Thu, 19 Feb 2004 00:41:10 +0200
From: "Bob Smith" <bobsmith@[don't-even-think-about-it]jippii.fi>
Subject: your partner
Message-Id: <BoVYb.552$5X7.85@reader1.news.jippii.net>
http://www.geocities.com/bob_smith852000/webinteractive/index.html
------------------------------
Date: Thu, 19 Feb 2004 03:02:10 GMT
From: "Robert M." <rmarkoff@msn.com>
Subject: Re: your partner
Message-Id: <rmarkoff-C1FBCF.21021018022004@news4.west.earthlink.net>
In article <BoVYb.552$5X7.85@reader1.news.jippii.net>,
"Bob Smith" <bobsmith@[don't-even-think-about-it]jippii.fi> wrote:
> http://www.geocities.com/etc
"We prefer not to publish pricing" it says.
Then whats the point of a web site?
------------------------------
Date: Thu, 19 Feb 2004 01:17:36 +0200
From: "Bob Smith" <bobsmith@[don't-even-think-about-it]jippii.fi>
Subject: Re: your partner
Message-Id: <LWVYb.553$oj7.369@reader1.news.jippii.net>
"Robert M." <rmarkoff@msn.com> wrote in message
news:rmarkoff-C1FBCF.21021018022004@news4.west.earthlink.net...
> In article <BoVYb.552$5X7.85@reader1.news.jippii.net>,
> "Bob Smith" <bobsmith@[don't-even-think-about-it]jippii.fi> wrote:
>
> > http://www.geocities.com/etc
>
> "We prefer not to publish pricing" it says.
>
> Then whats the point of a web site?
the point is to get the customer to talk, to create a unique approach for
that customer, to his or her needs,
publishing prices limits us, each company is unique, each company needs a
unique approach on the net to be successful, else it just drowns in the
masses. that's the point
------------------------------
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.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
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 6161
***************************************
