[25182] in Perl-Users-Digest
Perl-Users Digest, Issue: 7431 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Nov 20 14:05:51 2004
Date: Sat, 20 Nov 2004 11: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 Sat, 20 Nov 2004 Volume: 10 Number: 7431
Today's topics:
Re: Command-line HTML Post-method (medline in lynx) <tadmc@augustmail.com>
Re: Complex datastructure documentation? <tadmc@augustmail.com>
Re: Easier web programming language: PERL or PHP? <flavell@ph.gla.ac.uk>
Re: Easier web programming language: PERL or PHP? <flavell@ph.gla.ac.uk>
FAQ 3.21: How can I hide the source for my Perl program <comdog@panix.com>
Re: First Perl Program (J. Romano)
Re: how *.cgi file can get the parameters from client? <tadmc@augustmail.com>
Re: how *.cgi file can get the parameters from client? <amead@comcast.net>
Re: Ignore spaces in string match <matthew.garrish@sympatico.ca>
Re: Ignore spaces in string match <thelma@alpha2.csd.uwm.edu>
Re: Ignore spaces in string match <thelma@alpha2.csd.uwm.edu>
Re: Ignore spaces in string match <tadmc@augustmail.com>
Re: keep the reference pointer of an object <amead@comcast.net>
Re: OT irregardless (was Re: Problem with Hashes) <matthew.garrish@sympatico.ca>
Re: OT irregardless (was Re: Problem with Hashes) <flavell@ph.gla.ac.uk>
Re: OT irregardless (was Re: Problem with Hashes) <sbryce@scottbryce.com>
Re: OT irregardless (was Re: Problem with Hashes) <tadmc@augustmail.com>
PLEASE HELP! Perl script does not work! (Gandu)
Re: PLEASE HELP! Perl script does not work! <1usa@llenroc.ude.invalid>
Re: PLEASE HELP! Perl script does not work! <and11@rol.ru>
Re: PLEASE HELP! Perl script does not work! <tadmc@augustmail.com>
Re: the antichomp (J. Romano)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 20 Nov 2004 10:59:19 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Command-line HTML Post-method (medline in lynx)
Message-Id: <slrncputv7.bgo.tadmc@magna.augustmail.com>
[ Followups set ]
vjp2.at@at.BioStrategist.dot.dot.com <vjp2.at@at.BioStrategist.dot.dot.com> wrote:
> I am trying to write a unix proc that will pass my search terms to
> a search engine that uses post-method. I don't really understand how
> post works. Below is my attempt (I manually wrapped the one line proc
> into sep lines for display purposes):
>
> medline () { SRCH=`echo $* | sed -e 's/ /+/g'`; lynx -post_data
> -accept_all_cookies 'http://www.ncbi.nlm.nih.gov/htbin-post
> /Entrez/query_old?form=4&title=no&term='$SRCH'&submit=Search
> &field=All+++++++++++++++++++Fields&mode=Automatic&relpubdate
> =No+Limit&dispmax=100+&Dopt=d';}
What is your Perl question?
What is your HTML question?
What is your browser question?
What is your Unix question?
I see only an implied question of "how does POST work?", which is
independant of programming language, markup language, client
software and operating system.
ie. it is off-topic in each of the newsgroups you posted to.
> Much obliged in advance for any help.
You should perhaps work on better partitioning your problem as
you seem to be casting about in several wrong arenas.
I'm not sure where "how does the web work" questions should
be posted, maybe comp.infosystems.www.misc I guess?
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Sat, 20 Nov 2004 12:36:55 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Complex datastructure documentation?
Message-Id: <slrncpv3m7.bor.tadmc@magna.augustmail.com>
John Bokma <postmaster@castleamber.com> wrote:
> where do you want to have your bad code?
I don't want bad code at all, so I guess I want *my* bad code in
the bit bucket.
I would replace bad code with good code.
> learn that a sentence
> often starts with a capital, or in Perl:
>
> ucfirst ($Uri_sentence);
Heh! Now you've said something that I can actually agree with! :-)
> OO will make your rewritten code more readable, since the OP is going to
> use that complex datastructure in several places in his code.
Using procedural rewritten code will make it more readable too.
The OOness or proceduralness of the original bad code or the rewritten
good code is irrelevant to changing it from bad code to good code.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Sat, 20 Nov 2004 16:57:40 +0000
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: Easier web programming language: PERL or PHP?
Message-Id: <Pine.LNX.4.61.0411201649360.8280@ppepc56.ph.gla.ac.uk>
On Fri, 19 Nov 2004, Tad McClellan wrote:
> [ newsgroups trimmed, I don't do the alt.* wasteland, only this
> wasteland ]
giggle
> > ASP is much more complicated?
>
> Proprietary stuff sucks big ones.
No dispute on that. But I would suggest that you missed an important
issue here. ASP isn't a programming language (not even a web
programming language, whatever that might be exactly). It's more in
the nature of an interface specification. The programming language to
which it interfaces might often be VB, but it doesn't have to be.
So, in terms of its nature, ASP should be compared with CGI, or
with the Apache API, not with a programming language.
Perhaps one could mention http://www.apache-asp.org/ - without
however, particularly recommending it to someone who's not yet
in a position to make an informed choice.
------------------------------
Date: Sat, 20 Nov 2004 17:02:45 +0000
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: Easier web programming language: PERL or PHP?
Message-Id: <Pine.LNX.4.61.0411201702080.8280@ppepc56.ph.gla.ac.uk>
On Fri, 19 Nov 2004, Alan Mead wrote:
> Perl would be the best choice here because it was designed with postage
> and packaging in mind. (That's what the 'P' in Perl stands for).
Whose leg are you pulling?
------------------------------
Date: Sat, 20 Nov 2004 17:03:02 +0000 (UTC)
From: PerlFAQ Server <comdog@panix.com>
Subject: FAQ 3.21: How can I hide the source for my Perl program?
Message-Id: <cnntc6$b0h$1@reader1.panix.com>
This message is one of several periodic postings to comp.lang.perl.misc
intended to make it easier for perl programmers to find answers to
common questions. The core of this message represents an excerpt
from the documentation provided with Perl.
--------------------------------------------------------------------
3.21: How can I hide the source for my Perl program?
Delete it. :-) Seriously, there are a number of (mostly unsatisfactory)
solutions with varying levels of ``security''.
First of all, however, you *can't* take away read permission, because
the source code has to be readable in order to be compiled and
interpreted. (That doesn't mean that a CGI script's source is readable
by people on the web, though--only by people with access to the
filesystem.) So you have to leave the permissions at the socially
friendly 0755 level.
Some people regard this as a security problem. If your program does
insecure things and relies on people not knowing how to exploit those
insecurities, it is not secure. It is often possible for someone to
determine the insecure things and exploit them without viewing the
source. Security through obscurity, the name for hiding your bugs
instead of fixing them, is little security indeed.
You can try using encryption via source filters (Starting from Perl 5.8
the Filter::Simple and Filter::Util::Call modules are included in the
standard distribution), but any decent programmer will be able to
decrypt it. You can try using the byte code compiler and interpreter
described below, but the curious might still be able to de-compile it.
You can try using the native-code compiler described below, but crackers
might be able to disassemble it. These pose varying degrees of
difficulty to people wanting to get at your code, but none can
definitively conceal it (true of every language, not just Perl).
It is very easy to recover the source of Perl programs. You simply feed
the program to the perl interpreter and use the modules in the B::
hierarchy. The B::Deparse module should be able to defeat most attempts
to hide source. Again, this is not unique to Perl.
If you're concerned about people profiting from your code, then the
bottom line is that nothing but a restrictive license will give you
legal security. License your software and pepper it with threatening
statements like ``This is unpublished proprietary software of XYZ Corp.
Your access to it does not give you permission to use it blah blah
blah.'' We are not lawyers, of course, so you should see a lawyer if you
want to be sure your license's wording will stand up in court.
--------------------------------------------------------------------
Documents such as this have been called "Answers to Frequently
Asked Questions" or FAQ for short. They represent an important
part of the Usenet tradition. They serve to reduce the volume of
redundant traffic on a news group by providing quality answers to
questions that keep coming up.
If you are some how irritated by seeing these postings you are free
to ignore them or add the sender to your killfile. If you find
errors or other problems with these postings please send corrections
or comments to the posting email address or to the maintainers as
directed in the perlfaq manual page.
Note that the FAQ text posted by this server may have been modified
from that distributed in the stable Perl release. It may have been
edited to reflect the additions, changes and corrections provided
by respondents, reviewers, and critics to previous postings of
these FAQ. Complete text of these FAQ are available on request.
The perlfaq manual page contains the following copyright notice.
AUTHOR AND COPYRIGHT
Copyright (c) 1997-2002 Tom Christiansen and Nathan
Torkington, and other contributors as noted. All rights
reserved.
This posting is provided in the hope that it will be useful but
does not represent a commitment or contract of any kind on the part
of the contributers, authors or their agents.
------------------------------
Date: 20 Nov 2004 09:03:09 -0800
From: jl_post@hotmail.com (J. Romano)
Subject: Re: First Perl Program
Message-Id: <b893f5d4.0411200903.31dd6a10@posting.google.com>
parkerdg@gmail.com (DGP) wrote in message news:<8752e64b.0411161304.440a50ec@posting.google.com>...
>
> I decided Perl was the best tool for the job. After reading a begginer
> Perl book, I was able to complete the program below within a few
> hours. I think this speaks to Perl's ease of use, power, and
> flexibility.
>
> It seems to work pretty well, but I wanted to get input to see if it
> could be improved.
Wow! Great program for your first! I wouldn't be able to tell it
was your first program just by looking at it. I especially liked the
way you used "warnings" and "strict". Most beginning Perl programmers
don't use them, and in my experience, many advanced Perl programmers
don't either, which is a shame. "warnigs" and "strict" catch so many
errors that it's sad to see so many programmers who are too lazy to
put them in.
I do want to make three suggestions, however:
The first one is of your line:
@parts = split (",",$line);
The documentation for "split" ("perldoc -f split") says that the
split() function takes a /PATTERN/ (and not a string) for its first
argument. That means that your line would be better written as:
@parts = split(/,/, $line);
Most of the time Perl knows what you mean when you supply a string
instead of a pattern (and in your case it won't make a difference).
However, it's not good to assume that Perl will always know what you
mean. For example, the following two lines are NOT equivalent, even
though they look like they should be:
@tokens = split(" ", "dog horse cat bird");
@tokens = split(/ /, "dog horse cat bird");
My second suggestion to you is to declare the @parts array inside
the:
if ($line =~ /^116/) {
...
}
loop instead of near the top of your program. And the $line variable
should be declared in the foreach declaration. That is, the foreach
declaration should look like:
foreach my $line (<INF>) {
The reason for these changes in declaration is that their position
will now let the code maintainer know that @tokens and $line have no
use outside of the blocks they are declared in. But if they are
declared at the top of the program, then that means they could
possibly be used anywhere in the file.
This is a readability issue, however. If you think that the code
is more readable with the variables declared at the top of the script,
then by all means leave them there. But I'm just letting you know
that if you change them to be declared only inside the blocks (or more
appropriately, the scope) that they are used in, it will be easier for
others to deduce the purpose of what those variables are for.
My last suggestion is one that I learned after years of coding
experience. When you wrote:
# Find lines defining points (Type=116)
if ($line =~ /^116/) {
@parts = split (",",$line);
...
}
it was very good that you included that comment to find type 116
lines. However, I recomment adding a comment line or two showing an
example of what type of line you have found as the first line of the
"if" block. In other words, I recommend making your "if" block look
like this:
# Find lines defining points (Type=116)
if ($line =~ /^116/) {
# Now $line should look something like this:
# 116,blue,$19.95,45.5N,63.0W
@parts = split (",",$line);
...
}
That way, if a maintainer of your code (or you, in a few months) has
to read your code (and not have any input available), it will be
obvious to you/him/her what the input should look like and what the
entries in @parts should look like.
You can also adopt a similar strategy towards the output. Instead of
just:
# Write out point x,y,z location.
print OUTF "@parts[1..3]\n";
You can also add a comment line that shows an example of what could be
printed out, like this:
# Write out point x,y,z location.
# Example output: blue $19.95 45.5N
print OUTF "@parts[1..3]\n";
It helps if the example output line would correspond to the example
input line given above.
An example of the output isn't as important as an example of input,
since a person knowledgeable in Perl should be able to figure it out
relatively easily. But it still helps, espcially if processing the
input is large and complicated.
Of course, adding these comments won't affect the correctness of
your code, but giving an example of the input you are expecting (and
an example of the output you are writing out) is a great help to
anyone who has to read your code (even if it is you), in case the
input format should ever change or someone needs to review your code
to see how something is done (which can definitely happen if your code
works well and is quite useful).
There have been times in the past when I've looked back at my own
code that I wrote a year before and been angry at myself for not
including a sample line of the input I was processing. Conversely,
there have been times when I was happy at myself for including a
sample line or two that helped me understand what exactly the split()
function was operating on.
Overall, I recommend changing your split() function so that it
takes a /PATTERN/ (regular expression) as the first parameter, and
that you include a comment containing an example of a line of input to
process.
Great code, though! (I wish more long-time coders wrote Perl code
like you do!)
-- Jean-Luc
------------------------------
Date: Sat, 20 Nov 2004 12:15:59 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: how *.cgi file can get the parameters from client?
Message-Id: <slrncpv2eu.bgo.tadmc@magna.augustmail.com>
Alont <end@dream.life> wrote:
> ʱ:Sat, 20 Nov 2004 06:25:24 -0500
> Sherm Pendley <spamtrap@dot-app.org>÷:--
>>
>>Are you serious? You read through the module docs, and somehow you
>>managed to miss both the example at the top, and the section titled
>>"FETCHING THE VALUE OR VALUES OF A SINGLE NAMED PARAMETER"?
>>
>>sherm--
>
> I'm sorry, I search the CGI folder, but lost CGI.html..........
So rather than go get it, you decided to just ask hundreds of
people around the world to read it to you?
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Sat, 20 Nov 2004 12:56:30 -0600
From: Alan Mead <amead@comcast.net>
Subject: Re: how *.cgi file can get the parameters from client?
Message-Id: <pan.2004.11.20.18.56.30.778929@comcast.net>
On Sat, 20 Nov 2004 19:08:57 +0800, Alont wrote:
> how I can get the parameter from client through in Perl script?
> I can't find it in CGI:: module,
So sorry for your loss. I hope the damage was limited to CGI.html.
You are in luck, however. Go to the Google search engine and type in
"cgi.pm documentation" and click "Search". The first two hits are
wonderful sites that will amaze and delight you.
-Alan
------------------------------
Date: Sat, 20 Nov 2004 10:59:24 -0500
From: "Matt Garrish" <matthew.garrish@sympatico.ca>
Subject: Re: Ignore spaces in string match
Message-Id: <sRJnd.36833$rc.2330152@news20.bellglobal.com>
"bengee" <postmaster@localhost.localdomain> wrote in message
news:419f5c91$0$33604$ed2619ec@ptn-nntp-reader02.plus.net...
> Thelma Lubkin wrote:
>> I am trying to compare two strings that must match except for their
>> spacing.
>
> Remove spaces from both strings... if they match then they match!
>
If you looked at the example, you'd have noticed that the OP already figured
that part out. To the OP, elegance is a matter of taste, but if you're just
looking for speed you could use tr instead of the regexes:
(my $copy1 = $h1) =~ tr/ //d;
(my $copy2 = $h2) =~ tr/ //d;
if ($copy1 eq $copy2) {
}
Without modifying the original variables, I don't expect you find anything
nicer.
As a side note, the code you posted doesn't work. For one, you're only
removing a single space from one of the strings.You're also using the /x
modifier in the first instance where you should be using /g and in the
second where it makes no sense at all. Please see the perlre doc page for
more information on regex modifiers and what they do.
Matt
------------------------------
Date: 20 Nov 2004 17:02:17 GMT
From: Thelma Lubkin <thelma@alpha2.csd.uwm.edu>
Subject: Re: Ignore spaces in string match
Message-Id: <cnntap$37g$1@uwm.edu>
Matt Garrish <matthew.garrish@sympatico.ca> wrote:
: If you looked at the example, you'd have noticed that the OP already figured
: that part out. To the OP, elegance is a matter of taste, but if you're just
: looking for speed you could use tr instead of the regexes:
: (my $copy1 = $h1) =~ tr/ //d;
: (my $copy2 = $h2) =~ tr/ //d;
: if ($copy1 eq $copy2) {
: }
Thanks for the tip: I am going to need many repeats.
: As a side note, the code you posted doesn't work. For one, you're only
: removing a single space from one of the strings.You're also using the /x
: modifier in the first instance where you should be using /g and in the
: second where it makes no sense at all. Please see the perlre doc page for
: more information on regex modifiers and what they do.
That first instance was certainly a careless glitch on my
part.
But if the second /x makes no sense, why does this code work
as I want it to? I've read that /x is recommended for making
complex regular expressions more readable, but it seems to
work also for this use ??
--thelma, trying to learn, not argue
#!/usr/bin/perl -w
#use strict;
my $h1 = 'here i am';
my $h2 = 'herei am';
($hh2 = $h2) =~ s/\s//g;
if($hh2 =~ /^$h1$/x)
{ print "I'm ok for: $h1\n"; }
else
{ print "I'm in a mess for $h1\n"; }
$h3 = 'where am I?';
if($hh2 =~ /^$h3$/x)
{ print "I'm ok for: $h3\n"; }
else
{ print "I'm in a mess for: $h3\n"; }
: Matt
------------------------------
Date: 20 Nov 2004 17:11:21 GMT
From: Thelma Lubkin <thelma@alpha2.csd.uwm.edu>
Subject: Re: Ignore spaces in string match
Message-Id: <cnntrp$pdm$1@uwm.edu>
Thelma Lubkin <thelma@alpha2.csd.uwm.edu> wrote:
: Matt Garrish <matthew.garrish@sympatico.ca> wrote:
: : As a side note, the code you posted doesn't work. For one, you're only
: : removing a single space from one of the strings.You're also using the /x
: : modifier in the first instance where you should be using /g and in the
: : second where it makes no sense at all. Please see the perlre doc page for
: : more information on regex modifiers and what they do.
: That first instance was certainly a careless glitch on my
: part.
: But if the second /x makes no sense, why does this code work
: as I want it to? I've read that /x is recommended for making
: complex regular expressions more readable, but it seems to
: work also for this use ??
: --thelma, trying to learn, not argue
########## Sorry: I can't seem to do anything right this morning.
: #!/usr/bin/perl -w
: #use strict;
^ remove
: my $h1 = 'here i am';
: my $h2 = 'herei am';
my $hh2;
^ add
: ($hh2 = $h2) =~ s/\s//g;
: if($hh2 =~ /^$h1$/x)
: { print "I'm ok for: $h1\n"; }
: else
: { print "I'm in a mess for $h1\n"; }
: my $h3 = 'where am I?';
: ^ add
if($hh2 =~ /^$h3$/x)
: { print "I'm ok for: $h3\n"; }
: else
: { print "I'm in a mess for: $h3\n"; }
: : Matt
------------------------------
Date: Sat, 20 Nov 2004 10:45:43 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Ignore spaces in string match
Message-Id: <slrncput5n.bgo.tadmc@magna.augustmail.com>
Thelma Lubkin <thelma@alpha2.csd.uwm.edu> wrote:
> I am trying to compare two strings that must match except for their
> spacing.
>
> If I write:
>
> $h1 = 'here i am';
> $h2 = 'herei am';
>
> can I do a less clumsy comparison than
>
> ($hh2 = $h2) =~ s/\s//x;
( the s///x option is a no-op there, you must have meant s///g instead?)
( that ignores characters other than the space character. Is that
what you intended? if not then: s/ //g, or better: tr/ //d.
)
I don't think so, normalizing the data before the comparison seems
the best approach to me. You would of course need a similarly
de-spaced copy of $h1 too though.
> if($hh2 =~ /^$h1$/x) ...
Do you intend for $h1 to contain regex metacharacters that *are* meta?
If not, then what you have there is an equality test disguised as a
pattern match and implemented in an "expensive" way.
if ( $hh2 eq $hh1 ) # more clear AND faster!
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Sat, 20 Nov 2004 12:49:42 -0600
From: Alan Mead <amead@comcast.net>
Subject: Re: keep the reference pointer of an object
Message-Id: <pan.2004.11.20.18.49.40.938296@comcast.net>
On Sat, 20 Nov 2004 22:02:24 +0800, sam wrote:
> How can I login Cyrus once and keep its returned reference for another
> .cgi file used?
> [...]
> For example, if I have already invoked $imap = &imap_connect() in the
> index.cgi file, another cgi file (set_quota.cgi) no need to call the
> method imap_connect() again, instead, it will somehow use the reference
> of imap created in the index.cgi file and just call $imap->setquota().
I don't have an answer but here's some information: Perl objects are
actually references (so that's not so different from C). The objects are
destroyed automatically when the reference goes out of scope.
So, I guess you need to create a scope that is shared between your
programs. I simple way to do that would be to have a single
program/module. In that case, you make a connection st the top of the
file outside of any closures and the reference can be shared by all the
rest of the code (more or less).
If you really want to break up the code into different files, then I
believe the technology you want is "inter process communication" and there
is an IPC package. Maybe that will help?
-Alan
------------------------------
Date: Sat, 20 Nov 2004 11:08:29 -0500
From: "Matt Garrish" <matthew.garrish@sympatico.ca>
Subject: Re: OT irregardless (was Re: Problem with Hashes)
Message-Id: <ZZJnd.36837$rc.2334144@news20.bellglobal.com>
"Tad McClellan" <tadmc@augustmail.com> wrote in message
news:slrncpttl0.aas.tadmc@magna.augustmail.com...
> Tassilo v. Parseval <tassilo.von.parseval@rwth-aachen.de> wrote:
>
> [snip]
>
>> irregardless how much sense that makes.
>
>
> Hmmm, lessee...
>
> "regardless" would mean "without regard", so "irregardless" must
> mean "not without regard", ie. *with* regard! [1]
>
Better get used to it, though, it's not going anywhere:
Irregardless originated in dialectal American speech in the early 20th
century. Its fairly widespread use in speech called it to the attention of
usage commentators as early as 1927. The most frequently repeated remark
about it is that "there is no such word." There is such a word, however. It
is still used primarily in speech, although it can be found from time to
time in edited prose. Its reputation has not risen over the years, and it is
still a long way from general acceptance. Use regardless instead.
Matt
------------------------------
Date: Sat, 20 Nov 2004 16:34:28 +0000
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: OT irregardless (was Re: Problem with Hashes)
Message-Id: <Pine.LNX.4.61.0411201624430.8280@ppepc56.ph.gla.ac.uk>
On Sat, 20 Nov 2004, Tad McClellan wrote:
> [2] The other two being:
[...]
> using i.e. when they mean e.g.
You can get bonus points for using viz. (in the right place, I mean),
and a double bonus for sc. (hardly ever seen these days, sadly...)
To wit: to woo.
------------------------------
Date: Sat, 20 Nov 2004 10:29:58 -0700
From: Scott Bryce <sbryce@scottbryce.com>
Subject: Re: OT irregardless (was Re: Problem with Hashes)
Message-Id: <10puvojbb36ea08@corp.supernews.com>
Tad McClellan wrote:
> Sorry... you just hit one of my three "hot buttons" there.[2] :-)
Can you loan me a dollar? If not, I could care less.
------------------------------
Date: Sat, 20 Nov 2004 12:27:18 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: OT irregardless (was Re: Problem with Hashes)
Message-Id: <slrncpv346.bor.tadmc@magna.augustmail.com>
Scott Bryce <sbryce@scottbryce.com> wrote:
> I could care less.
That's what killfiles are for. Just put me in there if my
posts do not interest you.
Or put "Subject: OT" in there if off-topic posts do not
interest you.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 20 Nov 2004 09:24:57 -0800
From: cpptutor2000@yahoo.com (Gandu)
Subject: PLEASE HELP! Perl script does not work!
Message-Id: <3c7c9804.0411200924.146258e@posting.google.com>
Could some Perl guru please help me? I have a very simple script to
remove
contents of the mozilla cache. It runs, but does nothing, the cache
remains
full as before. Could someone please point what I am doing wrong? The
file
is below:
#!/usr/bin/perl
$directory_name = '.mozilla/gandu/uar30qwk.slt/Cache';
print "Opening directory ...: $directory_name\n";
opendir(the_dir, $directory_name) || die("Directory could not be
opened");
@filelist = readdir(the_dir);
foreach $f (@filelist){
unless(($f eq ".") || ($f eq "..")){
printf("Removing ... $f\n");
unlink($f);
}
}
closedir(the_dir);
Thanks in advance for your help.
------------------------------
Date: 20 Nov 2004 18:15:44 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: PLEASE HELP! Perl script does not work!
Message-Id: <Xns95A786E8F7C17asu1cornelledu@132.236.56.8>
cpptutor2000@yahoo.com (Gandu) wrote in
news:3c7c9804.0411200924.146258e@posting.google.com:
> Could some Perl guru please help me? I have a very simple script to
> remove contents of the mozilla cache.
Please put the subject of your message in the subject line of your message.
Also please read the posting guidelines for this group
http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.text
> It runs, but does nothing, the cache remains full as before. Could
> someone please point what I am doing wrong?
You did not read the documentation for the functions you are using.
The file is below:
>
> #!/usr/bin/perl
use strict;
use warnings;
> $directory_name = '.mozilla/gandu/uar30qwk.slt/Cache';
$directory_name = '.mozilla/gandu/uar30qwk.slt/Cache';
> print "Opening directory ...: $directory_name\n";
>
> opendir(the_dir, $directory_name) || die("Directory could not be
> opened");
Why ignore "why" opendir failed?
The convention is either to use all upper case variables for directory
handles.
opendir THE_DIR, $directory_name
or die "Directory could not be opened: $!";
> @filelist = readdir(the_dir);
my @filelist = readdir(THE_DIR);
If the number of files is large this very inefficient. It is generally
better to process files one by one by calling readdir in scalar context.
Please read:
perldoc -f opendir
perldoc -f readdir
> foreach $f (@filelist){
> unless(($f eq ".") || ($f eq "..")){
> printf("Removing ... $f\n");
> unlink($f);
You are not checking if unlink succeeded. This code also does not check if
the file is actually a directory. Please read:
perldoc -f unlink
perldoc -f -x
> }
> }
>
> closedir(the_dir);
closedir THE_DIR;
Sinan
------------------------------
Date: Sat, 20 Nov 2004 21:21:55 +0000
From: Andrew Tkachenko <and11@rol.ru>
Subject: Re: PLEASE HELP! Perl script does not work!
Message-Id: <cno24g$hbg$1@news.rol.ru>
Gandu wrote on 20 Ноябрь 2004 17:24:
>
> foreach $f (@filelist){
> unless(($f eq ".") || ($f eq "..")){
> printf("Removing ... $f\n");
> unlink($f);
> }
> }
>
@filelist contains relative paths. To fix it, prepend $f with
$directory_name:
foreach $f (map {"$directory_name/$_"} grep {!/^\./} @filelist){
printf("Removing ... $f\n");
unlink($f);
}
--
Andrew
------------------------------
Date: Sat, 20 Nov 2004 12:48:00 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: PLEASE HELP! Perl script does not work!
Message-Id: <slrncpv4b0.bor.tadmc@magna.augustmail.com>
Gandu <cpptutor2000@yahoo.com> wrote:
> Subject: PLEASE HELP! Perl script does not work!
PLEASE HELP! Put the subject of your article in the Subject of your article!
Have you see the Posting Guidelines that are posted here frequently?
> Could some Perl guru please help me?
You do not need the help of a Perl guru.
You don't even need the help of a Perl programmer of any level.
You only need the help of any programmer, as any of them ought
to know that
You should read the documentation for the functions that you use.
Are you a programmer?
> It runs, but does nothing,
If you want to verify that the unlink() unlinked, then you
should check its return value:
unlink($f) or warn "could not unlink '$f' $!";
> Could someone please point what I am doing wrong?
You are doing the programming equivalent of signing a contract
without reading it, namely calling a function without have read
the documentation for that function.
> #!/usr/bin/perl
use warnings;
use strict;
Ask for all the help you can get!
> $directory_name = '.mozilla/gandu/uar30qwk.slt/Cache';
> opendir(the_dir, $directory_name) || die("Directory could not be
> opened");
>
> @filelist = readdir(the_dir);
>
> foreach $f (@filelist){
> unless(($f eq ".") || ($f eq "..")){
> printf("Removing ... $f\n");
> unlink($f);
perldoc -f readdir
If you're planning to filetest the return values out of a
"readdir", you'd better prepend the directory in question.
Otherwise, because we didn't "chdir" there, it would have been
testing the wrong file.
You are trying to remove the files from the *current directory*
rather than the directory where they really are:
unlink( "$directory_name/$f" ) or warn...
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 20 Nov 2004 09:24:41 -0800
From: jl_post@hotmail.com (J. Romano)
Subject: Re: the antichomp
Message-Id: <b893f5d4.0411200924.5199b578@posting.google.com>
ioneabu@yahoo.com (wana) wrote in message news:<bf0b47ca.0411170715.2aa1d853@posting.google.com>...
>
> Is there a better way to it than this?
>
> $_ .= "\n" for @ARGV;
This may or may not be of use to you, but it might be handy to
learn about Perl's "-l" switch.
If a Perl script begins with a line like:
#!/usr/bin/perl -l
(or if a script is invoked with "perl -l script.pl"), then two things
will happen:
1. The newline will be automatically stripped from any
input read with the <...> operator.
2. The newline will automatically be printed with every
call to print().
This switch is handy if anyone wants to, say, add a certain string
to the end of lines of input, but before their newlines.
For example, let's say that you wanted to add "!!!" to the end of
each line of input that you process (but before the newline). A
programmer who is not aware of the "-l" switch might write a script
like this:
#!/usr/bin/perl
use strict;
use warnings;
while (<>)
{
chomp; # remove the newline
$_ .= "!!!"; # append the "!!!" string
print "$_\n"; # print the line with a newline
}
__END__
or perhaps as a one-liner, like this:
perl -pe 'chomp; $_ .= "!!!\n"'
In each case, the programmer has to explicitly remove the newline
(done here with chomp()) and add it back in later.
However, a programmer who knows about the "-l" switch might write a
script like this:
#!/usr/bin/perl -l
use strict;
use warnings;
while (<>)
{
$_ .= "!!!"; # append the "!!!" string
print;
}
__END__
or perhaps as a one-liner, like this:
perl -lpe '$_ .= "!!!"'
Of course, this switch works well only if you don't mind that the
newline is always stripped out or that the newline is always printed
with the print() function. So don't use it if this poses a problem
for you.
I hope what I said was clear.
-- Jean-Luc
------------------------------
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 7431
***************************************
