[23958] in Perl-Users-Digest
Perl-Users Digest, Issue: 6159 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Feb 18 21:05:36 2004
Date: Wed, 18 Feb 2004 18:05:10 -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: 6159
Today's topics:
Beginner question on @INC <root@nowhere.com>
Re: Beginner question on @INC <usenet@morrow.me.uk>
Re: Beginner question on @INC <root@nowhere.com>
Re: Beginner question on @INC <emschwar@pobox.com>
Re: I wish buy Perl book <wherrera@lynxview.com>
Re: Launch popup for file load from perl script <matthew.garrish@sympatico.ca>
Re: magic vars and $! (Anno Siegel)
Re: Matching quoted strings <invalid-email@rochester.rr.com>
Re: Matching quoted strings <pobugfix@peterlink.ru>
Re: Matching quoted strings <usenet@morrow.me.uk>
Re: more stripping <emschwar@pobox.com>
Re: more stripping <noreply@gunnar.cc>
Re: more stripping <noreply@gunnar.cc>
Re: more stripping <emschwar@pobox.com>
Re: more stripping <noreply@gunnar.cc>
Re: more stripping <emschwar@pobox.com>
moving a file to a different name <spedwards@qwest.net>
Re: moving a file to a different name <usenet@c0s.org>
Re: moving a file to a different name <usenet@morrow.me.uk>
Re: moving a file to a different name <trammell+usenet@hypersloth.invalid>
newbie: inheritance <pobugfix@peterlink.ru>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 18 Feb 2004 18:16:28 -0600
From: "Geedunk" <root@nowhere.com>
Subject: Beginner question on @INC
Message-Id: <pan.2004.02.19.00.16.28.750022@nowhere.com>
I loaded a new PC with RH-9 and since I am learning Perl (and Linux), I
went ahead and downloaded the newest version of Perl, checked to make sure
that it worked, then installed TK800.025 which also installed with no
errors other than the few percent that I always get on 'make test'.
Any simple programs to try a PerlTK script get the following message...
Can't locate (any module or TK itself) in @INC (@INC contains:
/usr/local/lib/perl5/5.8.0/i686 -linux /usr/local/lib/perl5/5.8.0
(snip) and so forth.
Now, this is a very obvious message saying that it is looking in the wrong
place, i.e. for the non-existant 5.8.0 rather than the new 5.8.1. I need
to change @INC to point to the right place. Normally I would just hack at
it till I figured out how to do it, but my perl books all say "Avoid
unnecessary additions to the @INC variable which may slow access time..."
and so forth.
The more I read and google about @INC the confusededer I get:-)
Apparently @INC is not in some file somewhere that I can examine or change
at leisure. In fact, I still don't know WHERE it is although I think I
see how to change it. Since I don't know much about it I don't want to
make any changes till I understand it some more.
Can someone give me the noobie tutorial on this obviously important
variable?
Thanks
Geedunk
------------------------------
Date: Thu, 19 Feb 2004 01:39:23 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: Beginner question on @INC
Message-Id: <c1144b$obs$1@wisteria.csv.warwick.ac.uk>
"Geedunk" <root@nowhere.com> wrote:
> I loaded a new PC with RH-9 and since I am learning Perl (and Linux), I
> went ahead and downloaded the newest version of Perl, checked to make sure
> that it worked, then installed TK800.025 which also installed with no
> errors other than the few percent that I always get on 'make test'.
>
> Any simple programs to try a PerlTK script get the following message...
>
> Can't locate (any module or TK itself) in @INC (@INC contains:
> /usr/local/lib/perl5/5.8.0/i686 -linux /usr/local/lib/perl5/5.8.0
> (snip) and so forth.
What *excatly* did it say?
Have you installed Tk.pm? (perl -MCPAN -e'install Tk')
Are you invoking the correct version of perl?
> Now, this is a very obvious message saying that it is looking in the wrong
> place, i.e. for the non-existant 5.8.0 rather than the new 5.8.1.
Did you install 5.8.1? You know the latest is 5.8.3?
> I need to change @INC to point to the right place. Normally I would just
> hack at it till I figured out how to do it, but my perl books all 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.
> Apparently @INC is not in some file somewhere that I can examine or change
> at leisure. In fact, I still don't know WHERE it is although I think I
> see how to change it. Since I don't know much about it I don't want to
> make any changes till I understand it some more.
No, you want it to be right... the default @INC is compiled into your
perl binary. You change it by answering the appropriate question when
you compile perl.
Ben
--
The cosmos, at best, is like a rubbish heap scattered at random.
- Heraclitus
ben@morrow.me.uk
------------------------------
Date: Wed, 18 Feb 2004 18:43:32 -0600
From: "Geedunk" <root@nowhere.com>
Subject: Re: Beginner question on @INC
Message-Id: <pan.2004.02.19.00.43.30.527376@nowhere.com>
>> Can't locate (any module or TK itself) in @INC (@INC contains:
>> /usr/local/lib/perl5/5.8.0/i686 -linux /usr/local/lib/perl5/5.8.0
>> (snip) and so forth.
>
> What *excatly* did it say?
> Have you installed Tk.pm? (perl -MCPAN -e'install Tk') Are you invoking
> the correct version of perl?
I will have copy the exact message and post it. (My internet connection
and learning PC are in different places). When I run "perl -v" I get...
"This is perl, v5.8.1 built for i686-linux..." And a pure perl program
runs fine.
> Did you install 5.8.1? You know the latest is 5.8.3?
No, I didn't know. But I have 5.8.1 already downloaded and since I am
barely qualified to be a newbie, I figure that it will be quite a while
before I can tell the difference.
>> 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 say that and at this point in my
learning curve I am certainly not qualified to say that a Perl book author
is wrong.
>> want to make any changes till I understand it some more.
>
> No, you want it to be right... the default @INC is compiled into your
> perl binary. You change it by answering the appropriate question when
> you compile perl.
>
>
Ah ha. So you are saying that I didn't answer something right when I
installed the new(er) version of Perl. Ok, I can believe that, but I
still see references to changing the @INC variable on the fly - don't I?
Thanks for the help
Geedunk
------------------------------
Date: Wed, 18 Feb 2004 18:51:09 -0700
From: Eric Schwartz <emschwar@pobox.com>
Subject: Re: Beginner question on @INC
Message-Id: <etollmzet0y.fsf@fc.hp.com>
"Geedunk" <root@nowhere.com> writes:
> Any simple programs to try a PerlTK script get the following message...
>
> Can't locate (any module or TK itself) in @INC (@INC contains:
> /usr/local/lib/perl5/5.8.0/i686 -linux /usr/local/lib/perl5/5.8.0
> (snip) and so forth.
>
> Now, this is a very obvious message saying that it is looking in the wrong
> place, i.e. for the non-existant 5.8.0 rather than the new 5.8.1.
So perhaps you need to take a look at which perl you're running. I
will bet a dozen albino rhinoceri that you're running 5.8.0 instead of
the 5.8.1 you just compiled (though if you're trying to run the latest
perl, I wonder why you're not running 5.8.3).
> I need to change @INC to point to the right place.
In this case, no, you need to use the right perl.
> Normally I would just hack at it till I figured out how to do it,
> but my perl books all say "Avoid unnecessary additions to the @INC
> variable which may slow access time..." and so forth.
You should avoid all unnecessary code, but there's nothing wrong with
modifying @INC if that's the right solution for your situation.
> The more I read and google about @INC the confusededer I get:-)
Perhaps you should read the standard documentation, instead of
googling god-knows-which websites? 'perldoc perlvar' tells you about
all built-in Perl variables, including @INC.
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.
> Apparently @INC is not in some file somewhere that I can examine or change
> at leisure.
Yes, that's what the standard documentation says. In fact, it's set
in your perl binary at compile time. I'm fairly sure the installation
docs tell you this, but I could be wrong; I haven't needed to compile
my own perl in quite a long time. So, given that it's set at compile
time, and that your @INC includes 5.8.0, it's pretty obvious that
you're running a 5.8.0 perl binary.
> In fact, I still don't know WHERE it is although I think I
> see how to change it.
Please read the docs first; your first instinct is likely to be wrong
here.
> Since I don't know much about it I don't want to make any changes
> till I understand it some more.
This is Very Good(tm).
> Can someone give me the noobie tutorial on this obviously important
> variable?
No need, you can read the grown-up version on your own hard drive.
-=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: Wed, 18 Feb 2004 17:20:41 -0700
From: Bill <wherrera@lynxview.com>
Subject: Re: I wish buy Perl book
Message-Id: <jtidnURkY_LJnKndRVn-sA@adelphia.com>
PHP2 wrote:
> I wish buy Perl book tomorrow by Amazon.. I am new in Perl development..
>
> Pls. send to me advices..
>
>
(not my listing but)
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3587893769&category=1107
------------------------------
Date: Wed, 18 Feb 2004 19:32:39 -0500
From: "Matt Garrish" <matthew.garrish@sympatico.ca>
Subject: Re: Launch popup for file load from perl script
Message-Id: <GuTYb.7063$Cd6.578614@news20.bellglobal.com>
"Ben Morrow" <usenet@morrow.me.uk> wrote in message
news:c10pdn$ijt$2@wisteria.csv.warwick.ac.uk...
> --
> I've seen things you people wouldn't believe: attack ships on fire off the
> shoulder of Orion; I've watched C-beams glitter in the darkness near the
> Tannhauser Gate. All these moments will be lost, in time, like tears in
rain.
> Time to die. |-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-|
ben@morrow.me.uk
>
Not quite verbatim...
Matt
------------------------------
Date: 19 Feb 2004 01:57:30 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: magic vars and $!
Message-Id: <c1156a$oij$1@mamenchi.zrz.TU-Berlin.DE>
Peter Michael <dog@dog.dog> wrote in comp.lang.perl.misc:
> Hi Anno,
>
>
> "Anno Siegel" <anno4000@lublin.zrz.tu-berlin.de> wrote in message
> news:c0vd7r$jkg$1@mamenchi.zrz.TU-Berlin.DE...
>
> [snip]
>
> > I'd check if the assignment was successful.
> >
> > do {
> > use integer;
> > $> = $_;
> > $> == $_ or die "Can't change uid ($>) to $_: $!";
> > } for scalar getpwnam 'nobody';
>
> thank you very much for the advice.
>
> > The integer pragma is useful because getpwnam may return negative userid's
> > as large positives, so the comparison is safer that way.
>
> Negative uids? Do you mean "getpwnam may return large positive uids
> as negative"? Can you please tell me what the exact reason for this
> (C data type mismatch?) is?
Well, signed vs. unsigned binary. I've seen userid's specified as negative
integers.
Why the mismatch? I'm not sure, and I can't say I care very much. It
happens all the time with user- (and group-) id's. Nobody seems to be
sure whether they're signed or not, though I'm sure POSIX has put its
foot down about that. Treat them as native integers and you're fine.
Anno
------------------------------
Date: Thu, 19 Feb 2004 00:55:54 GMT
From: Bob Walton <invalid-email@rochester.rr.com>
Subject: Re: Matching quoted strings
Message-Id: <403408E0.7030309@rochester.rr.com>
Ben Morrow wrote:
> see@sig.invalid wrote:
>
>>TonyShirt wrote:
>>
>>
>>>After an exaustive search on google groups I decided to post. I have
>>>a line:
>>>
>>>"FileVersion", "1, 2, 4, 17\0"
>>>
>>>I want to match
>>>FileVersion
>>>1, 2, 4, 17\0
>>>
>>>I tried $_ =~ /"(.*?)"/; but it only matches FileVersion. How do I
>>>
>>$-----------------------^
>>Try inserting a $ as the last character of the regexp. That will force
>>it to match a pair of quotes that terminates at the end of the string.
>>But while you're at it, you'd probably better also replace .*? with
>>something like [^"]* so that you don't match any "'s other than the ones
>>you intend.
>>
>
> 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 .*? .
>
> Ben
>
>
--
Bob Walton
Email: http://bwalton.com/cgi-bin/emailbob.pl
------------------------------
Date: Thu, 19 Feb 2004 04:22:04 +0300
From: "Andrew V. Tkachenko" <pobugfix@peterlink.ru>
Subject: Re: Matching quoted strings
Message-Id: <c1133l$kke$2@news.rol.ru>
Hmm. May be I've missed something, but how about:
/"([^"]+)"/g
TonyShirt wrote:
> After an exaustive search on google groups I decided to post. I have
> a line:
>
> "FileVersion", "1, 2, 4, 17\0"
>
> I want to match
> FileVersion
> 1, 2, 4, 17\0
>
> I tried $_ =~ /"(.*?)"/; but it only matches FileVersion. How do I
> go on a match the other quoted string?
------------------------------
Date: Thu, 19 Feb 2004 01:42:54 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: Matching quoted strings
Message-Id: <c114au$obs$2@wisteria.csv.warwick.ac.uk>
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.
Ben
--
I've seen things you people wouldn't believe: attack ships on fire off the
shoulder of Orion; I've watched C-beams glitter in the darkness near the
Tannhauser Gate. All these moments will be lost, in time, like tears in rain.
Time to die. |-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-| ben@morrow.me.uk
------------------------------
Date: Wed, 18 Feb 2004 16:27:15 -0700
From: Eric Schwartz <emschwar@pobox.com>
Subject: Re: more stripping
Message-Id: <etobrnwezos.fsf@fc.hp.com>
Gunnar Hjalmarsson <noreply@gunnar.cc> writes:
> They are. But once again a thread in this group has degenerated into
> giving the impression that you are automatically protected from such
> problems if you use CGI.pm, which AFAIK is not true. Such issues
> reasonably need to be addressed irrespective of the method for parsing
> CGI data.
CGI.pm handles clients POSTing more data than you're expecting (server
limits restrict GETs similarly), so that's one thing you're up on by
using it.
And yes, validating data has to happen anyway. But why make your
situation worse by inviting other bugs that have already been fixed in
the standard solution?
-=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, 19 Feb 2004 00:20:47 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: more stripping
Message-Id: <c10sq7$1d8rlj$1@ID-184292.news.uni-berlin.de>
Sherm Pendley wrote:
> My biggest beef with CGI.pm is that it isn't focused. It takes a
> "shotgun" approach of providing everything that might be useful in
> the most common case of input from and output to HTML forms. Thus,
> it includes a boatload of HTML form-generation methods that have
> *nothing* to do with the Common Gateway Interface.
>
> As I understand it, those methods are autoloaded, so there's hardly
> any penalty for them at run-time.
Well, whatever is causing it, the penalty for using CGI.pm for parsing
a simple querystring is striking:
http://groups.google.se/groups?selm=bp9hb9%241kv1vv%241%40ID-184292.news.uni-berlin.de
That benchmark showed that CGI.pm causes 0.2 seconds additional time.
You may argue that it *typically* doesn't matter for plain CGI
scripts, but there may be cases when it does.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Thu, 19 Feb 2004 00:33:00 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: more stripping
Message-Id: <c10th5$1cbn2n$1@ID-184292.news.uni-berlin.de>
Eric Schwartz wrote:
> Gunnar Hjalmarsson <noreply@gunnar.cc> writes:
>> They are. But once again a thread in this group has degenerated
>> into giving the impression that you are automatically protected
>> from such problems if you use CGI.pm, which AFAIK is not true.
>> Such issues reasonably need to be addressed irrespective of the
>> method for parsing CGI data.
>
> CGI.pm handles clients POSTing more data than you're expecting
> (server limits restrict GETs similarly), so that's one thing you're
> up on by using it.
Only if you tell it to do so by enabling one or two special variables.
And you must enable them in the right spot in your program, or else
they have no effect... In other words, also that problem needs to be
addressed by the programmer irrespective of whether you use CGI.pm or
not. Please do not contribute to giving some other impression!
> But why make your situation worse by inviting other bugs that have
> already been fixed in the standard solution?
I'm not advocating the use of buggy code. Actually, I'm using CGI.pm
in a few cases because I find it convenient. In particularly one case
I'm not using it for efficiency reasons (se my reply to Sherm's post
in this thread).
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Wed, 18 Feb 2004 17:12:09 -0700
From: Eric Schwartz <emschwar@pobox.com>
Subject: Re: more stripping
Message-Id: <eto1xosexly.fsf@fc.hp.com>
Gunnar Hjalmarsson <noreply@gunnar.cc> writes:
> Eric Schwartz wrote:
>> CGI.pm handles clients POSTing more data than you're expecting
>> (server limits restrict GETs similarly), so that's one thing you're
>> up on by using it.
>
> Only if you tell it to do so by enabling one or two special variables.
Meaning that people who don't need the overhead don't have it, and
people who do can use it. I fail to see the problem. And it's only
one special variable, and it's clearly documented. I suppose you can
point to clear documentation telling hand-rollers how to do the same
safely?
> And you must enable them in the right spot in your program, or else
> they have no effect... In other words, also that problem needs to be
> addressed by the programmer irrespective of whether you use CGI.pm or
> not.
Addressed, yes-- no-one disputes that. The question is how to address
it. Doing everything yourself means that you have to understand the
CGI spec, decide that $ENV{CONTENT_LENGTH} is what you want, figure
out what units it's specified in, and so on. Using CGI.pm means you
read the docs, see $CGI::POST_MAX, set it, and you're done. I know
which approach I'd rather take.
> Please do not contribute to giving some other impression!
I didn't, and please stop trying to imply I did.
>> But why make your situation worse by inviting other bugs that have
>> already been fixed in the standard solution?
>
> I'm not advocating the use of buggy code.
I have yet to see handrolled CGI code posted here that did not contain
at least one bug fixed in CGI.pm. So by advocating rolling your own,
you are advocating buggy code.
> Actually, I'm using CGI.pm in a few cases because I find it
> convenient. In particularly one case I'm not using it for efficiency
> reasons (se my reply to Sherm's post in this thread).
That's fine, too. Just don't expect anyone to care if you have
troubles with it.
-=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, 19 Feb 2004 02:15:57 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: more stripping
Message-Id: <c113if$1carjq$1@ID-184292.news.uni-berlin.de>
Eric Schwartz wrote:
> Gunnar Hjalmarsson writes:
>> Eric Schwartz wrote:
>>> CGI.pm handles clients POSTing more data than you're expecting
>>> (server limits restrict GETs similarly), so that's one thing
>>> you're up on by using it.
>>
>> Only if you tell it to do so by enabling one or two special
>> variables.
>
> Meaning that people who don't need the overhead don't have it, and
> people who do can use it. I fail to see the problem.
In my comment, to which you initially responded, I emphasized that by
using CGI.pm you are not *automatically* protected from problems of
the kind Jamie mentioned. The problem here is that you for some reason
lost the context, and by doing so I still think that you - hopefully
unintentionally - contributed to giving the wrong impression about
what it is you actually gain by using CGI.pm.
> I suppose you can point to clear documentation telling hand-rollers
> how to do the same safely?
No. Did I claim that I can? Don't think so.
>> And you must enable them in the right spot in your program, or
>> else they have no effect... In other words, also that problem
>> needs to be addressed by the programmer irrespective of whether
>> you use CGI.pm or not.
>
> Addressed, yes-- no-one disputes that. The question is how to
> address it. Doing everything yourself means that you have to
> understand the CGI spec, decide that $ENV{CONTENT_LENGTH} is what
> you want, figure out what units it's specified in, and so on.
> Using CGI.pm means you read the docs, see $CGI::POST_MAX, set it,
> and you're done.
Sure, doing it by help of CGI.pm is more convenient. In the same way
as making use of other Perl modules is typically more convenient than
reinventing various wheels. To me, CGI.pm is a toolkit with quite a
few things for dealing with CGI and forms. Tools that you are free to
use or refrain from using depending on the task and your personal
preferences as regards programming style.
>> Actually, I'm using CGI.pm in a few cases because I find it
>> convenient. In particularly one case I'm not using it for
>> efficiency reasons (se my reply to Sherm's post in this thread).
>
> That's fine, too. Just don't expect anyone to care if you have
> troubles with it.
Why on earth do you sound as if you were personally insulted by my
choice in that case? Sorry, but I find that comment utterly childish.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Wed, 18 Feb 2004 18:40:40 -0700
From: Eric Schwartz <emschwar@pobox.com>
Subject: Re: more stripping
Message-Id: <etoptcbetif.fsf@fc.hp.com>
Gunnar Hjalmarsson <noreply@gunnar.cc> writes:
> Eric Schwartz wrote:
>> I suppose you can point to clear documentation telling hand-rollers
>> how to do the same safely?
>
> No. Did I claim that I can? Don't think so.
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.
> Sure, doing it by help of CGI.pm is more convenient. In the same way
> as making use of other Perl modules is typically more convenient than
> reinventing various wheels. To me, CGI.pm is a toolkit with quite a
> few things for dealing with CGI and forms. Tools that you are free to
> use or refrain from using depending on the task and your personal
> preferences as regards programming style.
I prefer to minimize the number of places where I have the opportunity
to write buggy code. Certainly, that qualifies as 'personal style',
but it's pretty widely shared among professional programmers.
No-one's saying you have to use CGI.pm, and I'm certainly not; I'm
just pointing out that every single piece of hand-rolled CGI parsing
code I've seen posted here has had at least one obvious bug that is
fixed in CGI.pm, and that I personally don't care to spend the time
reading the CGI spec to find the more subtle ones. Perhaps someone
here does care to, but I think you'll find such people very few and
far between.
>>> Actually, I'm using CGI.pm in a few cases because I find it
>>> convenient. In particularly one case I'm not using it for
>>> efficiency reasons (se my reply to Sherm's post in this thread).
>> That's fine, too. Just don't expect anyone to care if you have
>> troubles with it.
>
> Why on earth do you sound as if you were personally insulted by my
> choice in that case?
Perhaps because you chose to read it that way? That wasn't the case.
I honestly don't care if you use CGI::Gunnar or even cgi-lib.pl in
your code.
> Sorry, but I find that comment utterly childish.
That doesn't appear to be a particularly sincere apology, so I'll
discount it for now.
-=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: Wed, 18 Feb 2004 16:22:20 -0700
From: "Shawn" <spedwards@qwest.net>
Subject: moving a file to a different name
Message-Id: <SsSYb.84$LH3.38303@news.uswest.net>
Hi,
I'm trying to move a file to different directory, filename (with a date
stamp within the name).
The file starts out as: report.txt
and I want to move it so it comes out as: gl_user_rept_021804.txt
So, I have been trying different versions of this command:
system("mv /var/shawn/report.txt /var/fred/gl_sys_rept_$date.txt");
I set date = `date +m+d+y`
And I can get it close but not quite what I want:
-rw-rw-r-- 1 gp22 pnpsup 5 Feb 18 10:06 gl_user_rept.021804
-rw-rw-r-- 1 gp22 pnpsup 5 Feb 18 10:37 gl_user_rept..txt
Any suggestions would be greatly appreciated.
Thanks
------------------------------
Date: 18 Feb 2004 15:30:52 -0800
From: gabe anzelini <usenet@c0s.org>
Subject: Re: moving a file to a different name
Message-Id: <86ptccothv.fsf@tyler.c0s.org>
"Shawn" <spedwards@qwest.net> writes:
> Hi,
>
> I'm trying to move a file to different directory, filename (with a date
> stamp within the name).
>
> The file starts out as: report.txt
> and I want to move it so it comes out as: gl_user_rept_021804.txt
>
> So, I have been trying different versions of this command:
> system("mv /var/shawn/report.txt /var/fred/gl_sys_rept_$date.txt");
>
> I set date = `date +m+d+y`
>
> And I can get it close but not quite what I want:
>
> -rw-rw-r-- 1 gp22 pnpsup 5 Feb 18 10:06 gl_user_rept.021804
> -rw-rw-r-- 1 gp22 pnpsup 5 Feb 18 10:37 gl_user_rept..txt
>
> Any suggestions would be greatly appreciated.
>
> Thanks
to get the date see:
http://www.perldoc.com/perl5.8.0/pod/func/localtime.html
------------------------------
Date: Wed, 18 Feb 2004 23:38:11 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: moving a file to a different name
Message-Id: <c10t13$kot$2@wisteria.csv.warwick.ac.uk>
"Shawn" <spedwards@qwest.net> wrote:
> I'm trying to move a file to different directory, filename (with a date
> stamp within the name).
>
> The file starts out as: report.txt
> and I want to move it so it comes out as: gl_user_rept_021804.txt
#!/usr/bin/perl
use strict;
use warnings;
use File::Copy qw/mv/;
use POSIX qw/strftime/;
my $from = '/var/shawn/report.txt';
my $to = strftime '/var/fred/gl_sys_rept_%m%d%y.txt', localtime;
mv $from, $to or die "can't mv file: $!";
BTW, I'd recommend using YYYYMMDD unless you've a good reason not to:
it has a four-digit year, it's unambiguous in terms of m/d/y vs d/m/y
and (most importantly) it sorts in chronological order.
Ben
--
I've seen things you people wouldn't believe: attack ships on fire off the
shoulder of Orion; I've watched C-beams glitter in the darkness near the
Tannhauser Gate. All these moments will be lost, in time, like tears in rain.
Time to die. |-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-| ben@morrow.me.uk
------------------------------
Date: Wed, 18 Feb 2004 23:38:56 +0000 (UTC)
From: "John J. Trammell" <trammell+usenet@hypersloth.invalid>
Subject: Re: moving a file to a different name
Message-Id: <slrnc37tsg.m66.trammell+usenet@hypersloth.el-swifto.com.invalid>
On Wed, 18 Feb 2004 16:22:20 -0700, Shawn <spedwards@qwest.net> wrote:
> I'm trying to move a file to different directory, filename (with a date
> stamp within the name).
>
> The file starts out as: report.txt
> and I want to move it so it comes out as: gl_user_rept_021804.txt
>
> So, I have been trying different versions of this command:
> system("mv /var/shawn/report.txt /var/fred/gl_sys_rept_$date.txt");
>
> I set date = `date +m+d+y`
>
> And I can get it close but not quite what I want:
>
> -rw-rw-r-- 1 gp22 pnpsup 5 Feb 18 10:06 gl_user_rept.021804
> -rw-rw-r-- 1 gp22 pnpsup 5 Feb 18 10:37 gl_user_rept..txt
>
> Any suggestions would be greatly appreciated.
>
In no particular order:
* perldoc File::Copy -- much cleaner than system()
* use a date format that makes sense, like YYYYMMDD
* only hit the shell when you need to; use POSIX::strftime
or similar to create date strings.
Some untested code:
use POSIX 'strftime';
my $date = strftime "%Y%m%d", localtime;
use File::Copy 'move';
move("/var/shawn/report.txt","/var/fred/gl_sys_rept_$date.txt");
------------------------------
Date: Thu, 19 Feb 2004 04:16:10 +0300
From: "Andrew V. Tkachenko" <pobugfix@peterlink.ru>
Subject: newbie: inheritance
Message-Id: <c112oj$kjs$2@news.rol.ru>
Hello.
I'm a bit confused with the following problem:
Lets pretend that I have three modules:
###############
package myDaemon;
sub new {
my $proto = shift;
my $class = ref($proto) || $proto;
my $self = ref($proto) ? $proto : {};
bless ($self, $class);
}
sub request {
my $self = shift;
my $data;
# some useful things like prepare $data content etc.
$self->_send_request($data);
}
sub _send_request {}
1;
#####################
package myDaemon::INET;
use strict;
use IO::Socket::INET;
our @ISA = qw/myDaemon/;
sub new {
my $proto = shift;
my $class = ref($proto) || $proto;
# some configuration steps for INET socket
my $self = bless $proto->SUPER::new(@_), $class;
}
sub _send_request {
my ($self, $data) = @_;
# send $data via INET socket
}
1;
######################
package myDaemon::UNIX;
use strict;
use IO::Socket::UNIX;
our @ISA = qw/myDaemon/;
sub new {
my $proto = shift;
my $class = ref($proto) || $proto;
# some configuration steps for UNIX socket
my $self = bless $proto->SUPER::new(@_), $class;
}
sub _send_request {
my ($self, $data) = @_;
# send $data via UNIX socket
}
1;
######################
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:
##########################
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 ?
Seems like I'm absolutely wrong with OO Perl but can't imagine
how to solve this problem :(
Any advice will be greatly appreciated.
Andrew.
------------------------------
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 6159
***************************************
