[31842] in Perl-Users-Digest
Perl-Users Digest, Issue: 3105 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Aug 29 18:09:25 2010
Date: Sun, 29 Aug 2010 15:09:06 -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 Sun, 29 Aug 2010 Volume: 11 Number: 3105
Today's topics:
Re: Help writing 'simple' loop <hjp-usenet2@hjp.at>
How to suppress methodName element in soap:Body of enve <droesler@comcast.net>
Re: perldoc (was: Re: FAQ 5.23...) <ben@morrow.me.uk>
Re: perldoc (was: Re: FAQ 5.23...) <sherm.pendley@gmail.com>
Re: require hangs <whynot@pozharski.name>
The Camel source text (was Re: perldoc) (Randal L. Schwartz)
Re: Writing or copying file to another directory <ben@morrow.me.uk>
Re: Writing or copying file to another directory <paul@pstech-inc.com>
Re: Writing or copying file to another directory <jurgenex@hotmail.com>
Re: Writing or copying file to another directory <tadmc@seesig.invalid>
Re: Writing or copying file to another directory <tadmc@seesig.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 29 Aug 2010 14:57:21 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Help writing 'simple' loop
Message-Id: <slrni7km9h.o97.hjp-usenet2@hrunkner.hjp.at>
On 2010-08-28 17:46, Uri Guttman <uri@StemSystems.com> wrote:
>>>>>> "j" == joey <joey@igetit.invalid> writes:
> j> $score = ($h1_right + $h2_right) + ($h3_right + $h4_right) + ($h5_right +
> j> $h6_right) + ($h7_right + $h8_right) + ($h9_right + $h10_right);
>
> why all thos extra parens? have you never added numbers in real life? do
> you add them in pairs first?
#!/usr/bin/perl
use warnings;
use strict;
my @h_right = (2**52 + 1, -2**52);
for (2 .. 9) {
$h_right[$_] = $h_right[$_ - 2] * 4;
}
my $score1 = ($h_right[0] + $h_right[1]) + ($h_right[2] + $h_right[3])
+ ($h_right[4] + $h_right[5]) + ($h_right[6] + $h_right[7])
+ ($h_right[8] + $h_right[9]);
my $score2 = $h_right[0] + $h_right[1] + $h_right[2] + $h_right[3]
+ $h_right[4] + $h_right[5] + $h_right[6] + $h_right[7]
+ $h_right[8] + $h_right[9];
printf "%d %d\n", $score1, $score2;
__END__
prints "341 256".
SCNR,
hp
------------------------------
Date: Sun, 29 Aug 2010 10:06:21 -0700 (PDT)
From: droesler <droesler@comcast.net>
Subject: How to suppress methodName element in soap:Body of envelope with SOAP::Lite
Message-Id: <2b6eb1b5-5074-4a7e-a5a7-fb5ac4adb256@a36g2000yqc.googlegroups.com>
Hi,
Is there a way to suppress the surrounding methodName element of the
soap:Body section of the SOAP envelope?
The web service sends a fault back saying there is an unknown part
(the methodName element) in the request. This web service is
implemented as a doc/literal type if that makes a difference.
I looked at SOAP::Serializer but it wasn't clear to me how to apply
that to the SOAP object being sent with the methodName call.
It doesn't make any difference if I use the wsdl method or the lower
level uri/proxy method.
#/usr/bin/per
use strict;
use warnings;
use SOAP::Lite;
my $svc = SOAP::Lite ->service(q{,,,wsdl location ...});
my $result = $svc->methodName( <method params> );
or
my $soap = SOAP::Lite ->uri(...) ->on_action( sub{...}) ->proxy(...);
my $result = $soap->methodName(<method params>);
I thought using the wsdl method would construct the required soap:Body
part, but testing the web service in a tool such as soapUI it doesn't
wrap the soap:Body contents with a methodName element.
Thanks
Dennis
------------------------------
Date: Sun, 29 Aug 2010 05:41:52 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: perldoc (was: Re: FAQ 5.23...)
Message-Id: <g15pk7-tjm1.ln1@osiris.mauzo.dyndns.org>
Quoth Xiong Changnian <xiong108@xuefang.com>:
> On Sat, 28 Aug 2010 20:04:49 -0700, Keith Keller wrote:
>
> > The Perl docs are basically POD, and the other tools you mention
> > (perldoc, perldoc.perl.org, others) are generated from a POD parser.
>
> Yes; that's rather my complaint. POD is a rudimentary markup; I class it
> as plain text (or common workarounds such as *bold*). I suggest HTML and
> SVG as the primary format for certain types of documentation.
>
> I use pod2html regularly, although not to browse perldoc. I use it to
> check my own POD.
>
> POD has its place; I think it's good to lower the bar for module authors
> to include *some* sort of documentation. Extensive tutorials need more
> support than POD can give.
I suspect that any attempt to redo the core docs so
- they aren't in POD,
- they are harder to read on a terminal than presently, or
- they are harder for the programmers actually working on the perl
core to keep up to date
will be met with strong resistance. The last is probably the most
important: it's all very well redoing the docs once, but they need to be
maintained along with the code. Since noone can reasonably guarantee to
be around forever to do that maintenance, it's important it can be done
by the people writing the code, as they change things.
If you're talking about writing a Perl tutorial separate from the core,
well, then there are plenty of those already, mostly very bad. They tend
to suffer from two main problems: the person writing them often doesn't
know enough Perl to write them well, and they are very rarely kept up to
date with changes in the language or in best practices. Both these flaws
are a direct consequence of them not being under the eye of the core
developers, which is why most people here recommend sticking to the core
docs. However badly-written or -organised they may be, they are at least
mostly correct.
Ben
------------------------------
Date: Sun, 29 Aug 2010 11:20:22 -0400
From: Sherm Pendley <sherm.pendley@gmail.com>
Subject: Re: perldoc (was: Re: FAQ 5.23...)
Message-Id: <m27hj9fnt5.fsf@sherm.shermpendley.com>
Ben Morrow <ben@morrow.me.uk> writes:
> I will
> freely admit that I found it a lot easier to absorb the information in
> that form, with decent typography and formatting, than I would have
> reading in an 80x25 monospace terminal window.
That was one of my original motivations for writing CamelBones. I had
been using MacPerl for several years by the time Mac OS X was released,
and I had grown accustomed to the Shuck program's very nice layout of
the Perl docs. But Mac OS X uses a native *nix Perl, and Shuck wasn't
ported to it - so I created the framework I needed to write a new POD
reader for Mac OS X, and called it ShuX as a nod of appreciation for the
original.
> Since POD already allows format-specific markup, it would be possible to
> add diagrams where appropriate for the HTML version only; with some
> effort it might be possible to do so without including HTML-specific
> markup everywhere.
ShuX works by using Pod::Parser to translate POD data into HTML, and
then handing the generated HTML off to a WebKit control for display.
I believe that WebKit already supports inline SVG; if so, few (if any)
changes would need to be made to support it in ShuX.
So, for whatever it's worth, if someone is willing to go to the effort
of pushing these changes through p5p, you'll find at least one reader
app that supports them.
sherm--
--
Sherm Pendley
<http://camelbones.sourceforge.net>
Cocoa Developer
------------------------------
Date: Sun, 29 Aug 2010 09:34:40 +0300
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: require hangs
Message-Id: <slrni7jvs1.m24.whynot@orphan.zombinet>
with <IPSdnbep6IbEqOrRnZ2dnUVZ_tidnZ2d@insightbb.com> monkeys paw wrote:
> I have a few dependant modules, too extensive to post at this
> point.
Me smells blackmail.
> A general question, what could make a 'require' of
> a module hang, when a 'use' works? I could try to boil it
> down to something more specific, but the mystery lies
> within several thousand lines of code. Any suggestions
> are appreciated. Thanks.
perl -d -we 'require foo::bar'
then hit Ctrl-C -- debugger will stop where it wastes cycles. Although,
if that's not pure-Perl then go 'strace(1)'.
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
------------------------------
Date: Sun, 29 Aug 2010 07:19:42 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: The Camel source text (was Re: perldoc)
Message-Id: <86eidhmrgh.fsf_-_@red.stonehenge.com>
>>>>> "Ben" == Ben Morrow <ben@morrow.me.uk> writes:
Ben> However, both of those were generated directly from POD. (The Camel book
Ben> was written in a slightly-expanded version of POD developed by
Ben> O'Reilly.)
The second edition, sure.
The first edition was written in a set of nroff/troff macros that I
wrote originally at Tektronix, then carried away by coworker Steve
Talbott when he met up with Tim O'Reilly to start writing those X11
books, around which O'Reilly and Associates was formed.
Ten years later, when I started the Camel book project, I asked them
what text processing they used. The editor said "oh, we have our own
in-house macro set". When I got the details, and found out it was
*mine* (even with the same comments still intact), I chuckled at the
idea of all those O'Reilly books having been done with *my* macros over
the years. The editor asked if I had any questions about "their"
macros, and I got to tell the backstory. :)
As POD matured, Larry figured out a way to put enough into POD to
represent everything we were doing with the "O'Reilly" troff macros, and
then developed translators from "oramacs" to POD. Thus, starting with
the second camel (and the third llama, and the first alpaca), we've been
using this enhanced POD for all of the books. (The first two llamas
were written in FrameMaker, and the third llama was re-typed from
scratch so that there'd be no ties to the ill-fated second llama.)
print "Just another Perl hacker,"; # and the original Camel/Llama/Alpaca author
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
------------------------------
Date: Sun, 29 Aug 2010 05:33:00 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Writing or copying file to another directory
Message-Id: <sg4pk7-tjm1.ln1@osiris.mauzo.dyndns.org>
Quoth "Paul E. Schoen" <paul@pstech-inc.com>:
>
> I have the permissions on these files as 777 but I probably want to remove
> the write and possibly the read permissions in the cgi-bin folder. Does an
> executable script, accessed by anyone through a link in the web page, have
> write permission to files with permission set at, for example, 700? And
> should the mailer.pl script have permission 711 to keep anyone other than
> myself from reading or writing it?
You can't make a perl script unreadable. The perl interpreter needs to
be able to read the file in order to run the script.
> My problems were mostly because of the host configuration, and the sys admin
> told me that it was set up as a "jail" which restricted access.
Jails are a form of chroot, so this may be the cause of your file access
problems.
Ben
------------------------------
Date: Sun, 29 Aug 2010 14:53:15 -0400
From: "Paul E. Schoen" <paul@pstech-inc.com>
Subject: Re: Writing or copying file to another directory
Message-Id: <B0yeo.33510$6o7.15213@newsfe21.iad>
"Ben Morrow" <ben@morrow.me.uk> wrote in message
news:sg4pk7-tjm1.ln1@osiris.mauzo.dyndns.org...
>
> Quoth "Paul E. Schoen" <paul@pstech-inc.com>:
>>
>> I have the permissions on these files as 777 but I probably want to
>> remove
>> the write and possibly the read permissions in the cgi-bin folder. Does
>> an
>> executable script, accessed by anyone through a link in the web page,
>> have
>> write permission to files with permission set at, for example, 700? And
>> should the mailer.pl script have permission 711 to keep anyone other than
>> myself from reading or writing it?
>
> You can't make a perl script unreadable. The perl interpreter needs to
> be able to read the file in order to run the script.
I have added an index.html file to the cgi-bin directory which just displays
"Restricted access" and does not allow public viw of the directory, which at
least gives a bit better security. But I don't fully understand how the UNIX
system determines the identity of the originator of a read, write, or
execute request. If I log on using Telnet or an FTP program, it seems a bit
clearer, but when I use a browser to access a web page which calls a CGI
script, is my identity used to determine the file permissions I have? Is the
perl interpreter assumed to be a public entity? And then when my perl script
reads or writes to a file in the cgi-bin or another directory, are the
permissions based on my original identity as determined by the browser?
I'd like to have things set up with the maximum possible level of security,
but still allow the necessary processes to take place. I found this document
about security: http://www.w3.org/Security/Faq/wwwsf1.html and it answered
some questions. The perl faq was not helpful except to say that the perl
source is not easily hidden.
>
>> My problems were mostly because of the host configuration, and the sys
>> admin
>> told me that it was set up as a "jail" which restricted access.
>
> Jails are a form of chroot, so this may be the cause of your file access
> problems.
Yes, I was given a special URL to access a file from the perl script, and
now the files are found and can be written. But could a public or anonymous
user also use that URL to write to the file? I suppose I'm not very worried
about someone using my scripts for their own purposes (especially if they
are not well-written), but I would not want to supply enough clues for a
malicious hacker to cause mayhem. I can probably get good information from
my Smartnet system administrator, but I think these issues are frequently
encountered when adding CGI and perl scripts to a website and it would
probably be worth including in the perl FAQ.
Thanks,
Paul
------------------------------
Date: Sun, 29 Aug 2010 12:20:43 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Writing or copying file to another directory
Message-Id: <a3cl76dp3nbhokc21uahrb45bng5am8u53@4ax.com>
"Paul E. Schoen" <paul@pstech-inc.com> wrote:
>But I don't fully understand how the UNIX
>system determines the identity of the originator of a read, write, or
>execute request.
This really has pretty much nothing to do with Perl. It would be the
same if you used a different programming language or even a totally
different application.
>If I log on using Telnet or an FTP program, it seems a bit
>clearer, but when I use a browser to access a web page which calls a CGI
>script, is my identity used to determine the file permissions I have?
Please define "_my_ identity". Unless the program did a setuid or chown
it will run under whatever user called it. For CGI scripts that's often
'nobody' or 'www' or some other special account with very low
permissions.
>Is the perl interpreter assumed to be a public entity?
In general yes because there would be little point in having private
copies of it.
>And then when my perl script
>reads or writes to a file in the cgi-bin or another directory, are the
>permissions based on my original identity as determined by the browser?
Yes, typically they will be the same as the web browser's ID, e.g.
"nobody" or 'www' or whatever the sysadmin determined the cgi server
should run under.
>I'd like to have things set up with the maximum possible level of security,
>but still allow the necessary processes to take place. I found this document
>about security: http://www.w3.org/Security/Faq/wwwsf1.html and it answered
>some questions. The perl faq was not helpful except to say that the perl
>source is not easily hidden.
Well, that's not surprising considering that Perl doesn't require (or
offers) anything different compared to other programming languages.
You have a CGI question, not a Perl question. Why would a CGI question
be answered in a Perl FAQ?
>Yes, I was given a special URL to access a file from the perl script, and
>now the files are found and can be written. But could a public or anonymous
>user also use that URL to write to the file?
That depends how the web server has been set up. You need to ask in NG
that actually deals with the web server you are using.
>but I think these issues are frequently
>encountered when adding CGI and perl scripts to a website and it would
>probably be worth including in the perl FAQ.
They are just as frequently encountered when adding CGI and C or Fortran
or Cobol or Haskell or $name_your_favourite_programming_lang to a web
site. Therefore they should be answered in a CGI FAQ and not in the Perl
FAQ.
jue
------------------------------
Date: Sun, 29 Aug 2010 16:14:08 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Writing or copying file to another directory
Message-Id: <slrni7lj2m.jbq.tadmc@tadbox.sbcglobal.net>
Jürgen Exner <jurgenex@hotmail.com> wrote:
> "Paul E. Schoen" <paul@pstech-inc.com> wrote:
>>I'd like to have things set up with the maximum possible level of security,
>>but still allow the necessary processes to take place. I found this document
>>about security: http://www.w3.org/Security/Faq/wwwsf1.html and it answered
>>some questions. The perl faq was not helpful except to say that the perl
>>source is not easily hidden.
>
> Well, that's not surprising considering that Perl doesn't require (or
> offers) anything different compared to other programming languages.
Other programming languages have taint checking?
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Sun, 29 Aug 2010 16:40:55 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Writing or copying file to another directory
Message-Id: <slrni7lkks.jbq.tadmc@tadbox.sbcglobal.net>
Paul E. Schoen <paul@pstech-inc.com> wrote:
> But I don't fully understand how the UNIX
> system determines the identity of the originator of a read, write, or
> execute request.
Every process is run by a "user", identified by a UID (User IDentifier,
a number) which corresponds to a name, often called a "login" or
"account" or "user".
Perl has a special varable named $< that contains the UID of the
owner of the process that the Perl program is running in.
It also has a function that can cross-reference from the UID to
the login name:
my $uid = $<;
my $login = getpwuid($<);
print "uid=$uid login=$login\n";
So, if you are wondering who your Perl program is running as, insert
code like the above and see for sure who it is running as.
> If I log on using Telnet or an FTP program, it seems a bit
> clearer,
In that case, you are whatever user your provider setup for you,
such as "pschoen" or "pauls" or whatever.
> but when I use a browser to access a web page which calls a CGI
> script,
A browser makes an "HTTP Request".
A web server services that request, and provides an "HTTP Response".
This is how the WWW works.
Browsers do not really access a web page, they issue an HTTP Request
and recieve an HTTP Response.
Web pages never call CGI programs.
The Web Server might call a CGI program in the course of fulfilling
a request though.
Understanding the fundamentals of how the WWW works is valuable...
> is my identity used to determine the file permissions I have?
... because it allows you to answer that question.
Your CGI program runs as the *web server* user, which is often "www"
or "nobody", but can be pretty much anything it depends on how your
provider has configured their web server.
(it is also possible that the CGI program runs as "pschoen" but that
too depends on how your web server is configured. Are you getting the
sense that none of this permission stuff is specific to Perl? I hope
so. You would have the same issues if you were using Python or C.
You really must know how the web server that you are using is
configured, contact your provider.
)
> Is the
> perl interpreter assumed to be a public entity?
What does "public entity" mean when you say it?
perl never logs in. It's "identity" is the same as the process
that it is running in.
> And then when my perl script
> reads or writes to a file in the cgi-bin or another directory, are the
> permissions based on my original identity as determined by the browser?
Permissions are never determined by the browser.
Permissions are determined by the owner of the process that is
running the program (whether written in Perl or not). (that process
was, in turn, started by the web server.)
In a shell session, that is likely to be "pschoen" or somesuch.
In a CGI environment, that is like to be "www" or some such.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 3105
***************************************
