[30425] in Perl-Users-Digest
Perl-Users Digest, Issue: 1668 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jun 23 18:09:56 2008
Date: Mon, 23 Jun 2008 15:09:19 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 23 Jun 2008 Volume: 11 Number: 1668
Today's topics:
Re: converting Java code to Perl (using LWP?) PugetSoundSylvia@gmail.com
Re: current directory, practical problem <MSwanberg@gmail.com>
Re: Difference of * and + in regular expression <tzz@lifelogs.com>
Re: Difference of * and + in regular expression xhoster@gmail.com
Re: FAQ 8.26 Why doesn't open() return an error when a <brian.d.foy@gmail.com>
Re: FAQ 8.26 Why doesn't open() return an error when a <szrRE@szromanMO.comVE>
Re: FAQ 9.16 How do I decode a CGI form? <benkasminbullock@gmail.com>
Re: FAQ 9.16 How do I decode a CGI form? <brian.d.foy@gmail.com>
Re: FAQ 9.16 How do I decode a CGI form? <szrRE@szromanMO.comVE>
How to ensure I'm doing lwp with https correctly? PugetSoundSylvia@gmail.com
Re: How to make list of all htm file... <glennj@ncf.ca>
Re: How to make list of all htm file... <szrRE@szromanMO.comVE>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 23 Jun 2008 09:48:41 -0700 (PDT)
From: PugetSoundSylvia@gmail.com
Subject: Re: converting Java code to Perl (using LWP?)
Message-Id: <16de9e5e-4583-4775-91d5-782496d54bed@w5g2000prd.googlegroups.com>
Hi Ben - thanks for the response. I finally figured it out -
embarassingly enough, I wasn't sending the userid/password through
correctly, I had switched the one with the other. I finally figured
it out when I un-encoded the encoded stuff, and there it was, plain as
day.
Sylvia
On Jun 13, 4:33=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth PugetSoundSyl...@gmail.com:
>
>
>
>
>
> > Thanks for your response, Ben. =A0I've posted what I have so far below
> > (it doesn't work, returns 'Error: 401 Unauthorized').
>
> > Also, here's what my limited documentation says:
>
> > =A0 =A0In order to be allowed through the firewall, users must send an
> > authentication HTTP header
> > =A0 =A0along with every request.
> > =A0 =A0The header structure is: =A0 Authorization: BASIC xxxxxxxxxxxxxxx=
x=85
> > =A0 =A0where =A0xxxxxxx is a firewall user name and password separated b=
y
> > =93:=94 and converted into BASE64-
> > =A0 =A0encoded format.
>
> > ***************************************
> > ***************************************
>
> > use MIME::Base64;
> > useLWP::UserAgent;
>
> > $ua =3DLWP::UserAgent->new;
>
> > $req =3D HTTP::Request->new(GET =3D> 'http://SiteName.org/login.php?
> > name=3DAppName&pass=3DAppPWD&service_type=3Dxxx');
> > $Encoded =3D encode_base64('FireWallName:FireWallPWD',''); =A0 #Encode
> > into Base64
> > $FullAuthorization =3D 'Basic ' . $Encoded; =A0 =A0 =A0 # not sure if Ba=
sic is
> > upper or lower - documentation is contradictory
>
> It's case-insensitive, so either ought to work.
>
> > =A0 $req->header('Authorization' =3D> $FullAuthorization);
>
> > # send request
> > $res =3D $ua->request($req);
>
> > # check the outcome
> > if ($res->is_success) {
> > =A0 print $res->decoded_content;
> > }
> > else {
> > =A0 print "Error: " . $res->status_line . "\n";
> > }
>
> That ought to work, I'd say. It would be easier to simply call
> $ua->credentials, passing the appropriate information, and letLWP
> handle constructing the header for you; finding out what the correct
> 'netloc' and 'realm' are will mean printing out the contents of the 401
> response.
>
> If this doesn't work, add
>
> =A0 =A0 useLWP::Debug qw/+conns/;
>
> to the top of your script, and post the output.
>
> Ben
>
> --
> Many users now operate their own computers day in and day out on various
> applications without ever writing a program. Indeed, many of these users
> cannot write new programs for their machines...
> =A0 =A0 -- F.P. Brooks, 'No Silver Bullet', 1987 =A0 =A0 =A0 =A0 =A0 =A0 [=
b...@morrow.me.uk]- Hide quoted text -
>
> - Show quoted text -
------------------------------
Date: Mon, 23 Jun 2008 12:43:10 -0700 (PDT)
From: MSwanberg <MSwanberg@gmail.com>
Subject: Re: current directory, practical problem
Message-Id: <715bfe84-2930-4df9-9f22-e70dbfd06f6f@e39g2000hsf.googlegroups.com>
On Jun 17, 8:42=A0am, cartercc <carte...@gmail.com> wrote:
> I know that Perl has a notion of the current directory, and that this
> notion can be changed.
>
> I wrote a script a couple of years ago that generates about a dozen
> files, deleting some and moving others to various directories. Since
> that time, others have modified it in various ways, unfortunately
> without following through the dependencies. Late last week, the script
> stopped working, and I was invited to fix it. I was able to compare
> the script that I released with the current script and make it work.
> In the process, I was requested to generate an additional file, to be
> placed in the script directory. The script now generates the file, but
> places it into another directory.
>
> Neither
> open RESULTS, ">results.txt"; =A0nor
> open RESULTS, ">./results.txt";
> work, and I don't want to hard code the directory path because the
> script gets moved from machine to machine and the path differs. (I use
> a config file which initializes the relative paths of where to put the
> files.)
>
> The script is now 15 pages long and quite frankly I don't want to go
> through it line by line -- I simply don't have the time. Any pointers
> on how to fix this? Other than hard coding the absolute path? (I just
> did this, and it works for now, until it's run on another server.)
>
> Thanks, CC.
It seems to me that the special variable $0 (that's a zero, not an oh)
has the path and filename of the executing script. You could munge
that with some regex to get the directory/folder where the script is.
Something like:
($scriptpath)=3D$0=3D~m[(.*/)[^/]*$];
Then, it's a simple matter to do an
open(OUT,">$scriptpath$filename");
and then write to it.
Just be careful... in DOS/Windows, the backslash is used in the path:
($scriptpath)=3D$0=3D~m[(.*\\)[^\\]*$];
-Mike
------------------------------
Date: Mon, 23 Jun 2008 11:26:47 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Difference of * and + in regular expression
Message-Id: <86abhcqfqw.fsf@lifelogs.com>
On Sun, 22 Jun 2008 20:41:02 -0700 (PDT) "comp.llang.perl.moderated" <ced@blv-sam-01.ca.boeing.com> wrote:
clpm> I still prefer to think of this as another aspect of greediness: *
clpm> can be greedy but only as greedy as needed to get the earliest
clpm> match. Thus, even greed embraces the cardinal Perl virtue of
clpm> laziness....
I'd call that opportunism, not laziness.
"The two cardinal virtues of Perl are TMTOWTDI and laziness and
opportunism... No, no. The THREE cardinal virtues of Perl are TMTOWTDI
and laziness and opportunism and DWIM... DAMN IT... The FOUR cardinal
virtues of Perl are... etc."
Ted
------------------------------
Date: 23 Jun 2008 19:18:22 GMT
From: xhoster@gmail.com
Subject: Re: Difference of * and + in regular expression
Message-Id: <20080623151824.923$Q2@newsreader.com>
Peng Yu <PengYu.UT@gmail.com> wrote:
> On Jun 21, 9:39 pm, Gunnar Hjalmarsson <nore...@gunnar.cc> wrote:
> > Peng Yu wrote:
> > > If I used the uncommented if-statement, I would get no match.
> >
> > Not true. $1 is defined, so the regex does match.
> >
> > > $string="a namespace a { namespace b { namespace c { ";
> >
> > > #if ($string =~ /\s*((namespace\s+\w(\w|\d)*\s*\{\s*)+)/) {
> > > if ($string =~ /\s*((namespace\s+\w(\w|\d)*\s*\{\s*)*)/) {
> > > print "$1\$\n";
> > > }
> >
> > With the * quantifier, the regex seems to behave non-greedy, though.
>
> According to the manual, *? is non-greedy.
> Why * is also non-greedy?
It depends on what you mean. "Greedy" in CS generally means you make
locally optimal decisions, rather than looking for globally optimal ones.
But what is considered "optimal" in the local matching of a regex?
In this sense, it is greedy either way, in that it still optimizes locally
rather than globally. It is just that what we consider optimal changes
with the addition of ?.
At this point, perhaps they revert from a CS meaning to a moral/political
meaning--greedy no longer means local vs. global, now it means as much as
possible vs. as little as possible.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Mon, 23 Jun 2008 10:39:34 -0500
From: brian d foy <brian.d.foy@gmail.com>
Subject: Re: FAQ 8.26 Why doesn't open() return an error when a pipe open fails?
Message-Id: <230620081039345944%brian.d.foy@gmail.com>
In article <g3mim801uek@news4.newsguy.com>, szr <szrRE@szromanMO.comVE>
wrote:
> PerlFAQ Server wrote:
> [...]
> > 8.26: Why doesn't open() return an error when a pipe open fails?
> >
> > If the second argument to a piped open() contains shell
> > metacharacters, perl fork()s, then exec()s a shell to decode the
> > metacharacters and eventually run the desired program. If the
> > program couldn't be run, it's the shell that gets the message, not
> > Perl. All your Perl program can find out is whether the shell
> > itself could be successfully started.
>
> When it invokes a shell, why doesn't it just return the value or $? (or
> equivalent exit status variable) so that the open returns the correct
> exit status?
It does return the exit value, but in the forked process, not your
main process.
The answer is a bit vague though, so I'll fix that.
------------------------------
Date: Mon, 23 Jun 2008 10:47:36 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: FAQ 8.26 Why doesn't open() return an error when a pipe open fails?
Message-Id: <g3onjo0o14@news4.newsguy.com>
brian d foy wrote:
> In article <g3mim801uek@news4.newsguy.com>, szr
> <szrRE@szromanMO.comVE> wrote:
>
>> PerlFAQ Server wrote:
>> [...]
>>> 8.26: Why doesn't open() return an error when a pipe open fails?
>>>
>>> If the second argument to a piped open() contains shell
>>> metacharacters, perl fork()s, then exec()s a shell to decode the
>>> metacharacters and eventually run the desired program. If the
>>> program couldn't be run, it's the shell that gets the message,
>>> not Perl. All your Perl program can find out is whether the shell
>>> itself could be successfully started.
>>
>> When it invokes a shell, why doesn't it just return the value or $?
>> (or equivalent exit status variable) so that the open returns the
>> correct exit status?
>
> It does return the exit value, but in the forked process, not your
> main process.
Ah, thanks for clearing that up.
> The answer is a bit vague though, so I'll fix that.
Sounds good.
--
szr
------------------------------
Date: Mon, 23 Jun 2008 13:38:50 +0000 (UTC)
From: Ben Bullock <benkasminbullock@gmail.com>
Subject: Re: FAQ 9.16 How do I decode a CGI form?
Message-Id: <g3o91a$4vb$1@ml.accsnet.ne.jp>
On Mon, 23 Jun 2008 06:03:04 -0700, PerlFAQ Server wrote:
> Use the CGI.pm module that comes with Perl. It's quick, it's
> easy, and it actually does quite a bit of work to ensure things
> happen correctly. It handles GET, POST, and HEAD requests,
> multipart forms, multivalued fields, query string and message
> body combinations, and many other things you probably don't want
> to think about.
Was this statement really written by someone who uses CGI.pm
regularly?
> It doesn't get much easier:
Hmm.
> the CGI module automatically parses the
> input and makes each value available through the "param()" function.
Yeah but - how hard is it to parse the input without CGI.pm? Not very,
and then you have the advantage of having complete control, and not
having to deal with the vagaries of a crackpot module like CGI.pm.
> use CGI qw(:standard);
>
> my $total = param( 'price' ) + param( 'shipping' );
>
> my @items = param( 'item' ); # multiple values, same field name
>
> If you want an object-oriented approach, CGI.pm can do that too.
But if you want to use JavaScript, CSS, or any encoding other than
ASCII, CGI.pm will make your life miserable. I've been there and done
that, and my experience has been that CGI.pm is a pain in the neck.
> Many people try to write their own decoder (or copy one from another
> program) and then run into one of the many "gotchas" of the task.
> It's much easier and less hassle to use CGI.pm.
I really doubt that. My experience of CGI.pm is that one ends up
having to use "here documents" instead of start_html and header, and
endless "decode" statements on everything returned from param, because
CGI.pm is too inflexible to allow you to do things correctly.
------------------------------
Date: Mon, 23 Jun 2008 10:37:25 -0500
From: brian d foy <brian.d.foy@gmail.com>
Subject: Re: FAQ 9.16 How do I decode a CGI form?
Message-Id: <230620081037258226%brian.d.foy@gmail.com>
In article <g3o91a$4vb$1@ml.accsnet.ne.jp>, Ben Bullock
<benkasminbullock@gmail.com> wrote:
> On Mon, 23 Jun 2008 06:03:04 -0700, PerlFAQ Server wrote:
>
> > Use the CGI.pm module that comes with Perl. It's quick, it's
> > easy, and it actually does quite a bit of work to ensure things
> Was this statement really written by someone who uses CGI.pm
> regularly?
It was written by me. See the . So, what are you trying to say?
> > the CGI module automatically parses the
> > input and makes each value available through the "param()" function.
> Yeah but - how hard is it to parse the input without CGI.pm?
You might not think it is, but I've seen almost everyone get it wrong.
Note that for most people, they won't know most of the gotchas.Using a
module is a lot easier than reinventing the wheel. You don't have to
recode what already works, already comes with Perl, and what has worked
for most people for years.
> But if you want to use JavaScript, CSS, or any encoding other than
> ASCII, CGI.pm will make your life miserable.
I think you're doing it wrong, then. The CGI is about the input. What
you send as the response it up to you. It can be anything you like. You
don't have to use the HTML convenience functions.
------------------------------
Date: Mon, 23 Jun 2008 11:01:29 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: FAQ 9.16 How do I decode a CGI form?
Message-Id: <g3oodr0om6@news4.newsguy.com>
Ben Bullock wrote:
> On Mon, 23 Jun 2008 06:03:04 -0700, PerlFAQ Server wrote:
>
>> Use the CGI.pm module that comes with Perl. It's quick, it's
>> easy, and it actually does quite a bit of work to ensure things
>> happen correctly. It handles GET, POST, and HEAD requests,
>> multipart forms, multivalued fields, query string and message
>> body combinations, and many other things you probably don't want
>> to think about.
>
> Was this statement really written by someone who uses CGI.pm
> regularly?
I have used it many time over the years and I can't say I've found any
instance where it doesn't do what it should. I've had not rpoblems with
it.
[...]
>> the CGI module automatically parses the
>> input and makes each value available through the "param()"
>> function.
>
> Yeah but - how hard is it to parse the input without CGI.pm? Not very,
> and then you have the advantage of having complete control, and not
> having to deal with the vagaries of a crackpot module like CGI.pm.
What vagaries are you referring to, exactly?
>> use CGI qw(:standard);
>>
>> my $total = param( 'price' ) + param( 'shipping' );
>>
>> my @items = param( 'item' ); # multiple values, same
>> field name
>>
>> If you want an object-oriented approach, CGI.pm can do that too.
>
> But if you want to use JavaScript, CSS, or any encoding other than
> ASCII, CGI.pm will make your life miserable. I've been there and done
> that, and my experience has been that CGI.pm is a pain in the neck.
When did JavaScript or CSS become "encodings"? CSS is a style sheet
language, that is either inlined into an x?html document or in an
external document referenced from an x?html document. JavaScript/JS is a
client side (and server side in the case of ASP) scripting language that
too can appear within or linked externally from an x?html document.
By encoding do you mean ContentType? such as text/css or
text/javascript? Even so, what exactly does that have to do with CGI.pm
or cgi in general?
>> Many people try to write their own decoder (or copy one from
>> another program) and then run into one of the many "gotchas" of
>> the task. It's much easier and less hassle to use CGI.pm.
>
> I really doubt that. My experience of CGI.pm is that one ends up
> having to use "here documents" instead of start_html and header, and
> endless "decode" statements on everything returned from param, because
> CGI.pm is too inflexible to allow you to do things correctly.
Could you please provide an example or two where you feel CGI.pm fell
short? I think this will better help myself and others to understand
where you are coming from, as everyone might have different experiences.
(Also, what's wrong with HEREDOCs? :-) )
--
szr
------------------------------
Date: Mon, 23 Jun 2008 11:29:36 -0700 (PDT)
From: PugetSoundSylvia@gmail.com
Subject: How to ensure I'm doing lwp with https correctly?
Message-Id: <24264b77-2af3-4507-bed6-dd61c6707644@p39g2000prm.googlegroups.com>
Hello all,
I'm using LWP for programatic access to a website. I'm using https,
and have installed Crypt::SSLeay (hopefully correctly).
What I'd like to do is make sure that my https access is actually
correctly set up, and that I am accessing everything securely. Any
ideas on how I can double-check that everything is happening
correctly? Or is there something I can use to audit my connection?
If I didn't do the Crypt::SSLeay install correctly, would https access
just not work, or would it just default to http?
Thanks in advance for any pointers,
Sylvia
------------------------------
Date: 23 Jun 2008 16:05:37 GMT
From: Glenn Jackman <glennj@ncf.ca>
Subject: Re: How to make list of all htm file...
Message-Id: <slrng5viei.43k.glennj@smeagol.ncf.ca>
At 2008-06-22 05:55PM, "szr" wrote:
> Dr.Ruud wrote:
> > szr schreef:
> >
> >> $ find . | grep -P 'html?$'
> >
> > That is quite wasteful, even if the current directory doesn't contain
> > millions of subdirectories and files.
> >
> > And it would erroneously return ./test_html and such.
> >
> > $ find . -type f -name "*.htm" -or -name "*.html"
> >
> > $ find . -type f -regex ".*\.html?"
>
> Ah, yes, I forgot the *. in my examples. And I forgot you could use
> regex with find.
They're not regular expressions: they're shell glob patterns.
--
Glenn Jackman
Write a wise saying and your name will live forever. -- Anonymous
------------------------------
Date: Mon, 23 Jun 2008 11:13:51 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: How to make list of all htm file...
Message-Id: <g3op500p6g@news4.newsguy.com>
Glenn Jackman wrote:
> At 2008-06-22 05:55PM, "szr" wrote:
>> Dr.Ruud wrote:
>>> szr schreef:
>>>
>>>> $ find . | grep -P 'html?$'
>>>
>>> That is quite wasteful, even if the current directory doesn't
>>> contain millions of subdirectories and files.
>>>
>>> And it would erroneously return ./test_html and such.
>>>
>>> $ find . -type f -name "*.htm" -or -name "*.html"
>>>
>>> $ find . -type f -regex ".*\.html?"
>>
>> Ah, yes, I forgot the *. in my examples. And I forgot you could use
>> regex with find.
>
> They're not regular expressions: they're shell glob patterns.
>
>
> --
> Glenn Jackman
> Write a wise saying and your name will live forever. -- Anonymous
I know that. I didn't mean it as a regex. The *.htm is anything, ending
with .htm
It is nice, though, that one can use just -regex when using find :-)
--
szr
------------------------------
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 V11 Issue 1668
***************************************
