[23810] in Perl-Users-Digest
Perl-Users Digest, Issue: 6013 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jan 29 20:01:11 2004
Date: Thu, 29 Jan 2004 17:00:44 -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 Thu, 29 Jan 2004 Volume: 10 Number: 6013
Today's topics:
install module without root access <markhamnr@bigfoot.com>
Re: install module without root access <spamtrap@dot-app.org>
Re: install module without root access <nospam@bigpond.com>
Re: install module without root access <jwillmore@remove.adelphia.net>
Re: install module without root access <Gunnar.News@gustra.org>
Re: install module without root access <markhamnr@bigfoot.com>
Installing 5.8.0 on Solaris with pkgadd, from Sunfreewa <mike@ellwoods.org.uk>
Interactive SSH sessions through perl? <jacob@jacobweber.com>
Re: Interactive SSH sessions through perl? <nospam@bigpond.com>
intermittent "Undefined subroutine" with mod_perl (Moulin Kluge)
Re: intermittent "Undefined subroutine" with mod_perl <pkent77tea@yahoo.com.tea>
Re: intermittent "Undefined subroutine" with mod_perl <nobull@mail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 27 Jan 2004 16:56:35 -0500
From: "Nicholas R. Markham" <markhamnr@bigfoot.com>
Subject: install module without root access
Message-Id: <bv6mqt$cau$1@newsfeeds.rpi.edu>
I'd like to install some modules on a machine on which I'm not root. I know
about using PREFIX= with perl Makefile.pl, and that works fine for the first
module. But if I want to install a module that depends on another module,
which other module I've installed in, say, ~/perl, I get warnings of
prerequisites not found. It seems that Makefile.pl doesn't know enough to
look in the PREFIX directory for modules... Has anyone experienced this and
solved it? Thanks.
------------------------------
Date: Tue, 27 Jan 2004 17:28:01 -0500
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: install module without root access
Message-Id: <WPGdnTJiHKVveIvdRVn-gg@adelphia.com>
Nicholas R. Markham wrote:
> It seems that Makefile.pl doesn't know enough to
> look in the PREFIX directory for modules...
You have to tell it what you want. Options for doing that are plentiful, but
unfortunately ESP isn't (yet) one of them.
If you're executing Makefile.PL manually, you can use the INC parameter.
If you're using the CPAN shell to manage your modules, you can configure it
to pass the appropriate INC parameter every time it runs Makefile.PL.
You could add your module directory to the PERL5LIB environment variable.
Note that the above aren't identical. You need to decide which is
appropriate for what you want to do - add to the library path for a single
invocation of Makefile.PL, for all such invocations via the CPAN shell, or
for all scripts you run under your login.
sherm--
------------------------------
Date: Wed, 28 Jan 2004 10:47:08 +1000
From: Gregory Toomey <nospam@bigpond.com>
Subject: Re: install module without root access
Message-Id: <bv70sk$njfdk$1@ID-202028.news.uni-berlin.de>
Nicholas R. Markham wrote:
Has anyone experienced this
> and
> solved it? Thanks.
Yes, get root access with an ISP that runs User Mode Linux.
http://user-mode-linux.sourceforge.net/uses.html
gtoomey
------------------------------
Date: Wed, 28 Jan 2004 01:10:33 -0500
From: James Willmore <jwillmore@remove.adelphia.net>
Subject: Re: install module without root access
Message-Id: <pan.2004.01.28.06.10.30.897078@remove.adelphia.net>
On Tue, 27 Jan 2004 16:56:35 -0500, Nicholas R. Markham wrote:
> I'd like to install some modules on a machine on which I'm not root. I
> know about using PREFIX= with perl Makefile.pl, and that works fine for
> the first module. But if I want to install a module that depends on
> another module, which other module I've installed in, say, ~/perl, I get
> warnings of prerequisites not found. It seems that Makefile.pl doesn't
> know enough to look in the PREFIX directory for modules... Has anyone
> experienced this and solved it? Thanks.
Set your PERL5LIB variable in your shell. I have used this method with
zero problems on a Sun box at work - except in cases where core Perl
modules need to be updated (like File::Spec). In that case, you have to
visit your friendly admin and convince him to to upgrade Perl :-)
Also, you'll need to tell your scripts (if the PERL5LIB is not set in the
shell) where your privately installed modules are. I usually use a BEGIN
block to 'push' the needed directories into @INC.
HTH
--
Jim
Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.
a fortune quote ...
You have junk mail.
------------------------------
Date: Wed, 28 Jan 2004 07:26:35 +0100
From: Gunnar Strand <Gunnar.News@gustra.org>
Subject: Re: install module without root access
Message-Id: <bv7kk6$ast$1@hudsucker.umdac.umu.se>
Try setting the PERL5LIB to ~/perl before you start the
make process. Example i tcsh:
setenv PERL5LIB ~/perl
If you have an internet connection I would recommend
using CPAN directly (if you are installing CPAN modules):
setenv PERL5LIB ~/perl # or ~/perl:${PERL5LIB}
perl -MCPAN -e shell
o conf makepl_arg LIB=~/perl # or PREFIX=~/lib
<install as usual>
I have done this for several users. Works like a charm.
Regards,
/Gunnar
Nicholas R. Markham wrote:
> I'd like to install some modules on a machine on which I'm not root. I know
> about using PREFIX= with perl Makefile.pl, and that works fine for the first
> module. But if I want to install a module that depends on another module,
> which other module I've installed in, say, ~/perl, I get warnings of
> prerequisites not found. It seems that Makefile.pl doesn't know enough to
> look in the PREFIX directory for modules... Has anyone experienced this and
> solved it? Thanks.
>
>
------------------------------
Date: Wed, 28 Jan 2004 10:53:30 -0500
From: "Nicholas R. Markham" <markhamnr@bigfoot.com>
Subject: Re: install module without root access
Message-Id: <bv8lu4$c92$1@newsfeeds.rpi.edu>
"Sherm Pendley" <spamtrap@dot-app.org> wrote in message
news:WPGdnTJiHKVveIvdRVn-gg@adelphia.com...
> Nicholas R. Markham wrote:
>
> > It seems that Makefile.pl doesn't know enough to
> > look in the PREFIX directory for modules...
>
> You have to tell it what you want. Options for doing that are plentiful,
but
> unfortunately ESP isn't (yet) one of them.
>
> If you're executing Makefile.PL manually, you can use the INC parameter.
>
> If you're using the CPAN shell to manage your modules, you can configure
it
> to pass the appropriate INC parameter every time it runs Makefile.PL.
>
> You could add your module directory to the PERL5LIB environment variable.
>
> Note that the above aren't identical. You need to decide which is
> appropriate for what you want to do - add to the library path for a single
> invocation of Makefile.PL, for all such invocations via the CPAN shell, or
> for all scripts you run under your login.
>
> sherm--
Ah, $PERL5LIB turned out to be what I was looking for. (At least until they
get the ESP thing working - will that be in Perl 6?) Thanks.
------------------------------
Date: Thu, 29 Jan 2004 16:16:44 +0000
From: Mike Ellwood <mike@ellwoods.org.uk>
Subject: Installing 5.8.0 on Solaris with pkgadd, from Sunfreeware.com; perlivp Perl header complaints
Message-Id: <Pine.WNT.4.50.0401291555230.-576287@oemcomputer>
This is addressed to anyone who has installed the prebuilt Perl 5.8.0 from
Sunfreeware on Solaris (Sparc) 8 or similar, or who knows the implications
of doing so. Apols to anyone who considers this borderline (or less) for
c.l.p.m. but I think it needs slightly more Perl expertise (more than
mine) than Solaris expertise (arguably):
After downloading Perl 5.8.0 from a mirror of
Sunfreeware.com, then using pkgadd to install on Solaris 8, with apparent
success, I ran perlivp, getting messages like:
Perl header `stdio.ph' does not appear to be properly installed
down to
# Perl header `values.ph' does not appear to be properly installed.
not ok 7
(with many others in between).
Also:
# Required module `GDBM_File' does not appear to be properly installed.
not ok 5
I guess the latter is only an issue if using DBMs, but the headers look
slightly more worrying. What are the implications?
Any thoughts?
I realise that another option is to try building from scratch (and be able
to get a slightly later version) but I was hoping to simplify life a bit
by installing something I know should be built for my environment, and
eliminate possible problems caused by my lack of Perl-building experience.
--
mike@ellwoods.org.uk
------------------------------
Date: Sat, 24 Jan 2004 19:25:47 GMT
From: Jacob Weber <jacob@jacobweber.com>
Subject: Interactive SSH sessions through perl?
Message-Id: <jacob-5C96F2.14254624012004@news05.east.earthlink.net>
Here's a weird one. I have a perl script which I run from the command
line. It tries to run a remote command via ssh. But the command requires
user input.
If I were running the command locally, it would pause and wait for the
user to type something. But when I run it through Net::SSH, it doesn't
stop for input. So it looks like STDIN is being changed.
Right now I'm using this:
Net::SSH::ssh_cmd($command, $args);
I tried changing Net::SSH to pass the -t argument to ssh, but then I get
this message:
[Net:SSH::ssh_cmd] STDERR Pseudo-terminal will not be allocated because
stdin is not a terminal.
Any ideas?
Thanks,
Jacob
------------------------------
Date: Sun, 25 Jan 2004 10:28:12 +1000
From: Gregory Toomey <nospam@bigpond.com>
Subject: Re: Interactive SSH sessions through perl?
Message-Id: <buv2jq$mjq60$1@ID-202028.news.uni-berlin.de>
Jacob Weber wrote:
> Here's a weird one. I have a perl script which I run from the command
> line. It tries to run a remote command via ssh. But the command requires
> user input.
>
> If I were running the command locally, it would pause and wait for the
> user to type something. But when I run it through Net::SSH, it doesn't
> stop for input. So it looks like STDIN is being changed.
>
> Right now I'm using this:
> Net::SSH::ssh_cmd($command, $args);
>
> I tried changing Net::SSH to pass the -t argument to ssh, but then I get
> this message:
>
> [Net:SSH::ssh_cmd] STDERR Pseudo-terminal will not be allocated because
> stdin is not a terminal.
>
> Any ideas?
> Thanks,
> Jacob
Try "expect" instead. Look at the man page.
gtoomey
------------------------------
Date: 26 Jan 2004 18:23:59 -0800
From: enunna@yahoo.com (Moulin Kluge)
Subject: intermittent "Undefined subroutine" with mod_perl
Message-Id: <cea64688.0401261823.7d3f7865@posting.google.com>
Hello,
I'm running a mod_perl application that works ok for a couple of
hours, but after a while I start getting an intermittent error:
Software error:
Undefined subroutine
&ModPerl::ROOT::ModPerl::Registry::var_www_cgi_2dbin_request_requestlist_2epl::PrintHeaders
called at /var/www/cgi-bin/request/requestlist.pl line 30.
It appears to only happen on a single thread, and when I hit this
thread, then I get the error. I'm running Redhat 9, completely
updated with Apache 2.0.40, mod_perl 1.99, and the latest update from
CPAN of CGI.pm.
I have multiple projects that use customized version of the same
private module, which doesn't really work with the latest mod_perl and
apache, because mod_perl scripts no longer have the current directory
set to the same as the script location, so I added the following to
the top of the scripts so that I can use my private modules:
BEGIN {
if( $ENV{"SCRIPT_FILENAME"} && $ENV{"SCRIPT_FILENAME"} =~
/^(.+)\/[^\/]+$/ )
{
chdir $1;
}
# Set library paths in @INC, at compile time
unshift @INC, '.';
}
The PrintHeaders function that is declared as "Undefined" above is in
the module. Is there possibly something weird going on here where one
of the threads perhaps ignoring this code? I know that this is not
the best way to handle modules (as opposed to putting them in the @INC
dirs), but it is really useful in a development environment.
Any help is appreciated. Thank you.
Eli
------------------------------
Date: Tue, 27 Jan 2004 22:22:26 +0000
From: pkent <pkent77tea@yahoo.com.tea>
Subject: Re: intermittent "Undefined subroutine" with mod_perl
Message-Id: <pkent77tea-949962.22222627012004@pth-usenet-01.plus.net>
In article <cea64688.0401261823.7d3f7865@posting.google.com>,
enunna@yahoo.com (Moulin Kluge) wrote:
> BEGIN {
> if( $ENV{"SCRIPT_FILENAME"} && $ENV{"SCRIPT_FILENAME"} =~
> /^(.+)\/[^\/]+$/ )
> {
> chdir $1;
> }
BEGIN blocks are executed at compile time. As you know, compilation
happens once under mod_perl.
Also the environment and cwd is reset on each request.
You don't paste any code but I suspect that this is related to the
problem - if you show us the relevant bit it might shed light on a
different place though. Personally though I think the chdir is not how
I'd do it, I'd do:
#### begin program.pl
use strict;
use lib '/home/moulin/lib';
use PrivateModule;
# some code
PrivateModule::thingy( $foo );
####################
or some variant with importing, or OO or whatever appropriate to the
task in hand.
P
--
pkent 77 at yahoo dot, er... what's the last bit, oh yes, com
Remove the tea to reply
------------------------------
Date: 27 Jan 2004 21:54:38 +0000
From: Brian McCauley <nobull@mail.com>
Subject: Re: intermittent "Undefined subroutine" with mod_perl
Message-Id: <u9smi05sc6.fsf@wcl-l.bham.ac.uk>
enunna@yahoo.com (Moulin Kluge) writes:
> I'm running a mod_perl application that works ok for a couple of
> hours, but after a while I start getting an intermittent error:
>
> Software error:
>
> Undefined subroutine
> &ModPerl::ROOT::ModPerl::Registry::var_www_cgi_2dbin_request_requestlist_2epl::PrintHeaders
> called at /var/www/cgi-bin/request/requestlist.pl line 30.
This is usually an effect of using Perl4-style libraries within
mod_perl. Don't do that. If you have a legacy library you have to
use then wrap it in a Perl5-style library (i.e. and module that uses
exporter).
> I have multiple projects that use customized version of the same
> private module, which doesn't really work with the latest mod_perl and
> apache, because mod_perl scripts no longer have the current directory
> set to the same as the script location,
I think you'll find it never really worked - perhaps you were
(unknowingly) already using kludge mentioned below.
> so I added the following to
> the top of the scripts so that I can use my private modules:
>
> BEGIN {
> if( $ENV{"SCRIPT_FILENAME"} && $ENV{"SCRIPT_FILENAME"} =~
> /^(.+)\/[^\/]+$/ )
> {
> chdir $1;
> }
> # Set library paths in @INC, at compile time
> unshift @INC, '.';
> }
Oh, so that would be your problem. Don't do that (muck about with
@INC) either.
The major point of mod_perl Registry is to only have to load each
module once rather than once per script. Once a module called Foo is
loaded no other module called Foo will be loaded by the same
interpreter thread.
> The PrintHeaders function that is declared as "Undefined" above is in
> the module. Is there possibly something weird going on here where one
> of the threads perhaps ignoring this code? I know that this is not
> the best way to handle modules (as opposed to putting them in the @INC
> dirs), but it is really useful in a development environment.
There are features mod_perl that allow different areas of the server
to effectively have different @INC (Apache::PerlVINC). It works by
reloading modules. This is intended as a development environment tool
- it's not something you'd want in a production environment. Be aware
that not all modules can be reloaded with impunity. Some will leak
memory. Some will do worse things.
In the case of a production environment ISTR that you can (in mod_perl2)
have multiple Perl interpreter pools and use different pools for
different areas of your website. (But then again do you really want
mod_perl2 in a production environment yet?).
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
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 6013
***************************************
