[31914] in Perl-Users-Digest
Perl-Users Digest, Issue: 3177 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Oct 16 16:09:21 2010
Date: Sat, 16 Oct 2010 13:09:05 -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 Sat, 16 Oct 2010 Volume: 11 Number: 3177
Today's topics:
Re: a test posting <greymausg@mail.com>
Re: FAQ 4.38 Why don't my <<HERE documents work? <brian.d.foy@gmail.com>
perl curl get data from website <emailsrvr-groups@yahoo.com>
Re: perl curl get data from website <jurgenex@hotmail.com>
Re: where to install cpan modules <sherm.pendley@gmail.com>
Re: where to install cpan modules <john@example.invalid>
Re: where to install cpan modules <sherm.pendley@gmail.com>
Re: where to install cpan modules <sherm.pendley@gmail.com>
Re: where to install cpan modules <ben@morrow.me.uk>
Re: where to install cpan modules <john@example.invalid>
Re: why does this happen? <whynot@pozharski.name>
Re: why does this happen? <hjp-usenet2@hjp.at>
Re: why does this happen? <jurgenex@hotmail.com>
Re: why does this happen? <tzz@lifelogs.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 16 Oct 2010 19:52:21 GMT
From: maus <greymausg@mail.com>
Subject: Re: a test posting
Message-Id: <slrnibk19f.7fq.greymausg@gmaus.org>
On 2010-10-13, Ng Spim <ng@spim.woeishyang.com> wrote:
> Pellentesque mollis imperdiet nibh, eu blandit nisi consequat et. Nulla
> ullamcorper ullamcorper ante vel vehicula. Curabitur sit amet porta
> est. Aliquam placerat lectus in mauris sagittis tempus. Cras vel ligula
> eros. In vehicula auctor lacinia. Ut pretium ornare mauris at luctus.
> Etiam sit amet scelerisque nunc. Phasellus ac urna vel sapien pretium
> pharetra eu et dolor. Pellentesque blandit adipiscing diam egestas
> cursus. Pellentesque in orci justo.
alt.test
--
greymaus
.
..
...
------------------------------
Date: Sat, 16 Oct 2010 04:50:14 -0500
From: brian d foy <brian.d.foy@gmail.com>
Subject: Re: FAQ 4.38 Why don't my <<HERE documents work?
Message-Id: <161020100450146912%brian.d.foy@gmail.com>
In article <vYKdnVQka4psXSvRnZ2dnUVZ5oKdnZ2d@giganews.com>, John Smith
<john@example.invalid> wrote:
> > It looks to see whether each line begins with a common substring, and if
> > so, strips that substring off.
>
> I thought it was going to strip off usr, but apparently that's not the idea.
It's stripping off non-word things, like >> quoting from the front.
You probably don't want to mess with any of that anyway. It's a kludge.
------------------------------
Date: Sat, 16 Oct 2010 03:39:42 -0700 (PDT)
From: SVCitian <emailsrvr-groups@yahoo.com>
Subject: perl curl get data from website
Message-Id: <2403552c-19f3-4123-9be6-4de5f0c7558f@p37g2000pra.googlegroups.com>
These 3 URLs work on a browser.. and return the same results... both
Firefox and IE.
But, I want to retrieve this programmatically using curl or perl..
with the prefix and sn serial number changed each time... How can i
make it work..
Can you provide a simple curl command line .. or perl get http.. to
demonstrate the retrieval.. thanks.
http://www.bangkokflightservices.com/TrackTrace/showc_track.php?m_prefix=3D=
176&m_sn=3D75064953&h_prefix=3DHWB&h_sn=3D&ecy=3De076438db64c6190f7b9689a37=
9b7f7093368f1652d14db65fee1ab916713f3f5f4030f53369cb1f669614312c4748899c272=
f4d976a2b299274a21ad80fc072b1bab2ab1c181d08c670188722e51ec162f9ae337e3f2f13=
2c88d249133815558d241ce8a4e9b3fa75c144268b9e901037c2c7257142ee42ff9b2bf2767=
f57ed62b94fd938ea4dd2b28c53fea6af74be&ch=3D%A0%A0%A0%A0
http://www.bangkokflightservices.com/TrackTrace/search_awb.php?id=3D5.223&m=
_prefix=3D176&m_sn=3D75064953&h_prefix=3DHWB&h_sn=3D&ch=3D
http://www.bangkokflightservices.com/our_cargo_track&trace.php?m_prefix=3D1=
76&m_sn=3D75064953&h_prefix=3DHWB&h_sn=3D
------------------------------
Date: Sat, 16 Oct 2010 07:28:59 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: perl curl get data from website
Message-Id: <didjb6924to6mnesiqnf272rs8ihule2fn@4ax.com>
SVCitian <emailsrvr-groups@yahoo.com> wrote:
>These 3 URLs work on a browser.. and return the same results... both
>Firefox and IE.
>
>But, I want to retrieve this programmatically using curl or perl..
>with the prefix and sn serial number changed each time... How can i
>make it work..
>
>Can you provide a simple curl command line .. or perl get http.. to
>demonstrate the retrieval.. thanks.
See the FAQ: perldoc -q "HTML file"
"How do I fetch an HTML file?"
jue
------------------------------
Date: Fri, 15 Oct 2010 18:11:42 -0400
From: Sherm Pendley <sherm.pendley@gmail.com>
Subject: Re: where to install cpan modules
Message-Id: <m2pqvbm7hd.fsf@sherm.shermpendley.com>
John Smith <john@example.invalid> writes:
> It was always important to put modules in the right place.
Yes, it is.
> I'm trying to figure out what that place is
Why? MakeMaker & Module::Build already know how to put things where
they belong. You only need to hold their hands if you want to force them
to put things in the *wrong* place. :-)
sherm--
--
Sherm Pendley
<http://camelbones.sourceforge.net>
Cocoa Developer
------------------------------
Date: Fri, 15 Oct 2010 18:10:06 -0600
From: John Smith <john@example.invalid>
Subject: Re: where to install cpan modules
Message-Id: <V6SdnbcgwYfCcCXRnZ2dnUVZ5rWdnZ2d@giganews.com>
Sherm Pendley wrote:
> John Smith <john@example.invalid> writes:
>
>> It was always important to put modules in the right place.
>
> Yes, it is.
>
>> I'm trying to figure out what that place is
>
> Why? MakeMaker & Module::Build already know how to put things where
> they belong. You only need to hold their hands if you want to force them
> to put things in the *wrong* place. :-)
Well, Sherm, I thank you for your comment, but it may have motivated me
to screw the pooch. I thought, "ok, I'll choose one of those paths in
@INC, and unpack the tar file for the module there."
(When I screw up, there's usually a few paragraphs between where I
started and how the fire department had to come.)
So, I thought /usr/share/perl looks like a good place because I want to
share perl among users. It went like this:
$ pwd
/usr/share/perl
$ cd ..
$ ls -ald perl
drwxr-xr-x 3 root root 4096 2009-04-20 07:59 perl
$ sudo chmod o=rw perl
[sudo] password for ron:
$ ls -ald perl
drwxr-xrw- 3 root root 4096 2009-04-20 07:59 perl
$
So now I have write priveleges, but now that I do, when I run perl -V,
my interpreter can't discover the meaning of strict, so I think this
evidences of the above eluded-to pooch-screw:
$ perl -V
Can't locate strict.pm in @INC (@INC contains: /etc/perl
/usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5
/usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10
/usr/local/lib/site_perl .) at /usr/lib/perl/5.10/Config.pm line 5.
BEGIN failed--compilation aborted at /usr/lib/perl/5.10/Config.pm line 5.
Compilation failed in require.
BEGIN failed--compilation aborted.
$
So, what great thing have I done here?
--
John Smith
------------------------------
Date: Fri, 15 Oct 2010 20:39:36 -0400
From: Sherm Pendley <sherm.pendley@gmail.com>
Subject: Re: where to install cpan modules
Message-Id: <m2fww7c6nr.fsf@sherm.shermpendley.com>
John Smith <john@example.invalid> writes:
> Sherm Pendley wrote:
>> John Smith <john@example.invalid> writes:
>>
>>> It was always important to put modules in the right place.
>>
>> Yes, it is.
>>
>>> I'm trying to figure out what that place is
>>
>> Why? MakeMaker & Module::Build already know how to put things where
>> they belong. You only need to hold their hands if you want to force them
>> to put things in the *wrong* place. :-)
>
> Well, Sherm, I thank you for your comment, but it may have motivated
> me to screw the pooch. I thought, "ok, I'll choose one of those paths
> in @INC, and unpack the tar file for the module there."
>
> (When I screw up, there's usually a few paragraphs between where I
> started and how the fire department had to come.)
In this case, there isn't. The very first paragraph explains it - you
are doing things by hand, when a perfectly cromulent and entirely
automated means of doing them exists.
At a shell prompt, type:
$ sudo cpan Module::Name
And you're done.
sherm--
--
Sherm Pendley
<http://camelbones.sourceforge.net>
Cocoa Developer
------------------------------
Date: Fri, 15 Oct 2010 20:42:27 -0400
From: Sherm Pendley <sherm.pendley@gmail.com>
Subject: Re: where to install cpan modules
Message-Id: <m2lj5zotn0.fsf@sherm.shermpendley.com>
Sherm Pendley <sherm.pendley@gmail.com> writes:
> John Smith <john@example.invalid> writes:
>
>> Sherm Pendley wrote:
>>> John Smith <john@example.invalid> writes:
>>>
>>>> It was always important to put modules in the right place.
>>>
>>> Yes, it is.
>>>
>>>> I'm trying to figure out what that place is
>>>
>>> Why? MakeMaker & Module::Build already know how to put things where
>>> they belong. You only need to hold their hands if you want to force them
>>> to put things in the *wrong* place. :-)
>>
>> Well, Sherm, I thank you for your comment, but it may have motivated
>> me to screw the pooch. I thought, "ok, I'll choose one of those paths
>> in @INC, and unpack the tar file for the module there."
>>
>> (When I screw up, there's usually a few paragraphs between where I
>> started and how the fire department had to come.)
>
> In this case, there isn't. The very first paragraph explains it - you
> are doing things by hand, when a perfectly cromulent and entirely
> automated means of doing them exists.
>
> At a shell prompt, type:
>
> $ sudo cpan Module::Name
>
> And you're done.
Oh, and if you *must* install a module by hand for some reason, have a
look at 'perldoc perlmodinstall' for instructions about how to do so.
I'll give you a hint - it doesn't involve simply copying stuff into some
directory randomly chosen from @INC.
sherm--
--
Sherm Pendley
<http://camelbones.sourceforge.net>
Cocoa Developer
------------------------------
Date: Sat, 16 Oct 2010 02:01:34 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: where to install cpan modules
Message-Id: <e4ano7-4o52.ln1@osiris.mauzo.dyndns.org>
Quoth John Smith <john@example.invalid>:
>
[ installing CPAN modules ]
>
> Well, Sherm, I thank you for your comment, but it may have motivated me
> to screw the pooch. I thought, "ok, I'll choose one of those paths in
> @INC, and unpack the tar file for the module there."
No, no, that's quite wrong. If you're starting with a tarball, you untar
it somewhere temporary, and let the installer install it in the right
place. Better would be to use the cpan client directly.
> So, I thought /usr/share/perl looks like a good place because I want to
> share perl among users.
I would not recommend installing modules by hand into a perl tree
managed by your system package manager. That way lies much confusion
when you come to upgrade. Either use the package manager to install the
modules you need (if they're available), compile your own perl that
lives somewhere else (I tend to use /opt/perl; I would install perl like
this:
% tar -xzvf perl-5.12.2.tar.gz
% cd perl-5.12.2
% ./Configure -des -Dprefix=/opt/perl -Uinstallusrbinperl
-Dman1dir=none -Dman3dir=none -Dinc_version_list=none
-Dusemymalloc=y -Duse64bitint -Ud_dosuid
% make && make test
# make install
) or install and use local::lib.
> It went like this:
>
> $ pwd
> /usr/share/perl
> $ cd ..
> $ ls -ald perl
> drwxr-xr-x 3 root root 4096 2009-04-20 07:59 perl
> $ sudo chmod o=rw perl
*WHAT?* That is a completely insane thing to do. I hope noone but you
uses or has access to this machine...
You should never make a perl module directory world-writable. It is an
*enormous* security hole. Directories for your own use only should be
owned by you, global directories should be owned by root, and neither
should be world-writable.
You have also taken the other-execute bit off. Do you know what that
does?
> [sudo] password for ron:
> $ ls -ald perl
> drwxr-xrw- 3 root root 4096 2009-04-20 07:59 perl
> $
>
> So now I have write priveleges, but now that I do, when I run perl -V,
> my interpreter can't discover the meaning of strict, so I think this
> evidences of the above eluded-to pooch-screw:
Well, yeah. You took the other-execute bit off.
Wipe out all that and reinstall it with your package manager. Then see
if you can install what you want with said package manager. If not, read
the docs for local::lib on search.cpan.org and use that.
Ben
------------------------------
Date: Sat, 16 Oct 2010 13:43:03 -0600
From: John Smith <john@example.invalid>
Subject: Re: where to install cpan modules
Message-Id: <0YmdnQbIlrHVnSfRnZ2dnUVZ5uednZ2d@giganews.com>
Ben Morrow wrote:
> Quoth John Smith <john@example.invalid>:
> [ installing CPAN modules ]
>> Well, Sherm, I thank you for your comment, but it may have motivated me
>> to screw the pooch. I thought, "ok, I'll choose one of those paths in
>> @INC, and unpack the tar file for the module there."
>
> No, no, that's quite wrong. If you're starting with a tarball, you untar
> it somewhere temporary, and let the installer install it in the right
> place. Better would be to use the cpan client directly.
Ok.
>
>> So, I thought /usr/share/perl looks like a good place because I want to
>> share perl among users.
>
> I would not recommend installing modules by hand into a perl tree
> managed by your system package manager. That way lies much confusion
> when you come to upgrade. Either use the package manager to install the
> modules you need (if they're available), compile your own perl that
> lives somewhere else (I tend to use /opt/perl; I would install perl like
> this:
>
> % tar -xzvf perl-5.12.2.tar.gz
> % cd perl-5.12.2
> % ./Configure -des -Dprefix=/opt/perl -Uinstallusrbinperl
> -Dman1dir=none -Dman3dir=none -Dinc_version_list=none
> -Dusemymalloc=y -Duse64bitint -Ud_dosuid
> % make && make test
> # make install
>
> ) or install and use local::lib.
I haven't gotten this far yet, as I've simply been repairing the damage.
>
>> It went like this:
>>
>> $ pwd
>> /usr/share/perl
>> $ cd ..
>> $ ls -ald perl
>> drwxr-xr-x 3 root root 4096 2009-04-20 07:59 perl
>> $ sudo chmod o=rw perl
>
> *WHAT?* That is a completely insane thing to do. I hope noone but you
> uses or has access to this machine...
I'm just a cowboy on a keyboard, but the whole idea is that I've created
another user on ubuntu to see how things work. It's been the most
eye-opening thing I've done on linux yet.
Einstein defined insanity as doing the same thing repeatedly and
expecting different results. As I have only done this once, this fails
to meet his criterion.
>
> You should never make a perl module directory world-writable. It is an
> *enormous* security hole. Directories for your own use only should be
> owned by you, global directories should be owned by root, and neither
> should be world-writable.
Ok.
>
> You have also taken the other-execute bit off. Do you know what that
> does?
Yeah, it causes the perl interpreter to be unable to find the meaning of
strict, which is the most fundamental of pragmata.
I wanted to add rw to owner, so what I should have done is
chmod o=rwx perl
, but of course, I shouldn't have changed this permission to begin with.
The execution of
perl -V
requires the pragma strict found here:
# locate strict.pm
/usr/share/perl/5.10.0/strict.pm
# ls -l strict.pm
-rw-r--r-- 1 root root 879 2009-06-26 13:03 strict.pm
As I look at it now, I think I just have to generally say that if you
lose the execution bit for owner on usr/local/perl, the perl compiler
cannot leave square one.
>
>> [sudo] password for ron:
>> $ ls -ald perl
>> drwxr-xrw- 3 root root 4096 2009-04-20 07:59 perl
>> $
>>
>> So now I have write priveleges, but now that I do, when I run perl -V,
>> my interpreter can't discover the meaning of strict, so I think this
>> evidences of the above eluded-to pooch-screw:
>
> Well, yeah. You took the other-execute bit off.
>
> Wipe out all that and reinstall it with your package manager. Then see
> if you can install what you want with said package manager. If not, read
> the docs for local::lib on search.cpan.org and use that.
I'm gonna see if I can do it off the command line first.
Thanks for your help, Ben. I like to think that my screw-ups with
permissions don't evidence of the same mistake because the underlying
task is usually different.
--
John Smith
------------------------------
Date: Sat, 16 Oct 2010 12:23:51 +0300
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: why does this happen?
Message-Id: <slrnibirp6.ka8.whynot@orphan.zombinet>
with <slrnibhe4i.7uf.hjp-usenet2@hrunkner.hjp.at> Peter J. Holzer wrote:
*SKIP*
> Oh, and since some people here are touting the security card: The
> current behaviour can be seen as a security risk, too: If you open a
> file which is readable only by the group (or even only by the owner)
> and you save it it, you might not expect that the new file is
> world-readable and accidentally divulge confidential information.
(btw, who's that "you"? I observe at least two security mornos here.)
Anyway, if a file contains sensitive information than one *creating*
such must set permissions correctly anyway. And one must not rely on
features of tools in use. Permissions must be verified after "cp"
either, mustn't they?
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
------------------------------
Date: Sat, 16 Oct 2010 14:07:59 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: why does this happen?
Message-Id: <slrnibj5d0.ui6.hjp-usenet2@hrunkner.hjp.at>
On 2010-10-16 09:23, Eric Pozharski <whynot@pozharski.name> wrote:
> with <slrnibhe4i.7uf.hjp-usenet2@hrunkner.hjp.at> Peter J. Holzer wrote:
>> Oh, and since some people here are touting the security card: The
>> current behaviour can be seen as a security risk, too: If you open a
>> file which is readable only by the group (or even only by the owner)
>> and you save it it, you might not expect that the new file is
>> world-readable and accidentally divulge confidential information.
>
> (btw, who's that "you"? I observe at least two security mornos here.)
"You" is the impersonal you, not any specific contributor to this
thread.
> Anyway, if a file contains sensitive information than one *creating*
> such must set permissions correctly anyway. And one must not rely on
> features of tools in use. Permissions must be verified after "cp"
> either, mustn't they?
Yes. If you've been bitten often enough by the behaviour of Unix tools,
you learn to check these things. For example, one problem with "cp" is
that it doesn't set the group explicitely, so you may wind up with a
copy which has the group bits set correctly but for the wrong group.
There is also the problem that if you copy a file from one directory to
the other there are at least two sane assumptions of what you want to
achieve:
1) You want to preserve the original permissions. If access to the
original file was restricted, it was for a reason, and the copy (having
the same contents) should have the same restrictions.
2) The permissions should be adapted to the new directory. You had a
reason to copy that file to a different location, and that reason
was most probably to make it available to the users who have access
to the target directory, so the permissions of the copy should
reflect that.
(our users frequently expect #2 and are confused if doesn't work that
way)
But the OP wasn't trying to do anything that fancy. He was opening a
script he had written himself and was saving it under a different name
in the same directory. I think it is very hard to argue that in this
case the permissions should be different than the original.
hp
------------------------------
Date: Sat, 16 Oct 2010 07:34:27 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: why does this happen?
Message-Id: <iodjb6p9fantts8al18lqqkg5to8rib9eo@4ax.com>
"Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
>There is also the problem that if you copy a file from one directory to
>the other there are at least two sane assumptions of what you want to
>achieve:
>
> 1) You want to preserve the original permissions. If access to the
> original file was restricted, it was for a reason, and the copy (having
> the same contents) should have the same restrictions.
I disagree. One of the most frequent reasons to copy a file is to create
a private copy which can be amended and modified by me, no matter that
the original was owned by someone else and naturally write protected.
jue
------------------------------
Date: Sat, 16 Oct 2010 10:06:15 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: why does this happen?
Message-Id: <87y69ykwig.fsf@lifelogs.com>
On Sat, 16 Oct 2010 07:34:27 -0700 Jürgen Exner <jurgenex@hotmail.com> wrote:
JE> "Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
>> There is also the problem that if you copy a file from one directory to
>> the other there are at least two sane assumptions of what you want to
>> achieve:
>>
>> 1) You want to preserve the original permissions. If access to the
>> original file was restricted, it was for a reason, and the copy (having
>> the same contents) should have the same restrictions.
JE> I disagree. One of the most frequent reasons to copy a file is to create
JE> a private copy which can be amended and modified by me, no matter that
JE> the original was owned by someone else and naturally write protected.
I think the obvious conclusion from all this is "it depends on what the
user wants" and thus it should be up to the user as an editor option,
ideally conditional by file name or at least extension.
Explicitly setting permissions bypasses the umask, the most fundamental
safeguard for file creation. In a shared system you always want a
restrictive umask, for instance. So again "it depends."
It's pretty easy to do this kind of conditional logic in Emacs Lisp.
Most regular editors, including Eclipse, don't have that kind of
flexibility.
Ted
------------------------------
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 3177
***************************************
