many module questions

[Christopher Palmer]

I'm in a bit of bind here.  I started an online intro Perl course, and
the current task is to make sure my machine is loaded with the latest
versions of DBI.pm, CGI.pm, and the DBD of my choice.  The instructor
gave the class Windows-centric instructions...so I now have a few
questions/problems...btw - this is the stock perl install with a G5,
and 10.3.

1) How can I tell what versions of modules I have installed, if any,
aside from finding, say, CGI.pm and opening it up in BBEdit to check?
(which is what I did anyway)

2) How can I install DBI.pm?  I got the source from CPAN, but that
doesn't appear to be of much use.  Can I just drop the source file into
wherever else it needs to be?  I know, nothing is ever that easy, so it
probably needs to be compiled.  Where does one find something like
DBI.pm with the makefile I need?  I tried to do it from the CPAN shell,
but it says it doesn't know what I'm talking about.

3) Can I just call the source of a module with my script, and specify
where the file lives on the local disk?  Probably a major perfomance
hit tho, eh?

4) I tried to install DBD::mysql, and I get this at the very end:

Warning: prerequisite DBI 1.08 not found.

Error: Unable to locate installed Perl libraries or Perl source code.

It is recommended that you install perl in a standard location before
building extensions. Some precompiled versions of perl do not contain
these header files, so you cannot build extensions. In such a case,
please build and install your perl from a fresh perl distribution. It
usually solves this kind of problem.

(You get this message, because MakeMaker could not find
"/System/Library/Perl/5.8.1/darwin-thread-multi-2level/CORE/perl.h")
Running make test
  Make had some problems, maybe interrupted? Won't test
Running make install
  Make had some problems, maybe interrupted? Won't install


5) thank you in advance for any help...please spell out what I need to
do...my command line skills are a bit rusty.  Also, are there any other
resources for Perl on OS X out there?  Books, FAQs?  Just so I can try
to answer more troubles like this before it comes to posting for
help...thanks again!

Re: many module questions

[Sherm Pendley]

On Jan 31, 2004, at 7:11 PM, Christopher Palmer wrote:

I'm in a bit of bind here.  I started an online intro Perl course, and
the current task is to make sure my machine is loaded with the latest
versions of DBI.pm, CGI.pm, and the DBD of my choice.
That's a pretty bogus course, IMHO. Module installation can get hairy, 
and saddling a newbie with it as one of their first tasks isn't very 
friendly.

Okay. This stuff is covered in detail in "perldoc perlmodinstall", so 
I'll just hit the high points here. Oh, and if you didn't know, 
"perldoc" is a documentation reader similar to "man", that takes the 
name of the perl documentation page, or the name of a module, as an 
argument.

So, the first thing you want to do is configure the CPAN shell. Since 
your course is Windows-centric, they may have mentioned ActiveState's 
PPM tool for package management; the CPAN shell is a similar tool 
that's used in UNIX environments. You need to run it as root, so start 
it like this:

sudo cpan

It will ask you a number of questions about where you want to get your 
modules and so on. For the most part, the defaults are fine, and you 
can simply accept them by hitting "return." You do need to choose a 
mirror (or three) however; this is where you'll be downloading your 
modules from.

1) How can I tell what versions of modules I have installed, if any,
aside from finding, say, CGI.pm and opening it up in BBEdit to check?
(which is what I did anyway)
In the CPAN shell:

i ModuleName

This will give you information about ModuleName, including the 
currently installed version (if it's installed), and the version 
available from CPAN.

Note that the Perl that ships with Panther already includes a very 
recent CGI module, so you don't need to install it unless you want the 
absolute latest.

Also notice that the name of the module is "CGI" - not "CGI.pm". The 
CGI module, like most modules, does include a file that has the name of 
the module + ".pm", but the extension isn't part of the module name, 
and isn't used in the CPAN shell.

2) How can I install DBI.pm?
In the CPAN shell:

install ModuleName

This will attempt to download and install ModuleName.pm using the 
default, standard procedure. This should work fine for DBI, but 
DBD::mysql will need some hand-holding.

4) I tried to install DBD::mysql, and I get this at the very end:

Warning: prerequisite DBI 1.08 not found.
One of the more useful aspects of the CPAN shell is that it manages 
prerequisites for you. You can configure it to (never/always/ask about) 
installing them; I configure it to ask, because I'm a little bit 
paranoid. If you're the trusting type, you can tell it to always 
install them without asking, or if you're *really* paranoid, you can 
tell it to never install them.

One thing you'll need to do before installing DBD::mysql is install 
MySQL itself. The simplest way to do that is via Fink. You'll also need 
the related -dev package from Fink, which includes the headers and 
libraries you'll need. If you intend to run the DBD::mysql module's 
self-tests, which is advisable, you'll need to start up mysql and set 
the root password.

As I said before, DBD::mysql needs more hand-holding than the default 
'install ModuleName' will provide. More to the point, extra parameters 
need to be passed to "Makefile.PL" when you run it. To do this, use the 
CPAN shell's handy "look" command:

look DBD::mysql

This will download the latest DBD::mysql module, unpack the tarball, 
and open up a subshell in the build directory. First, read the 
INSTALL.html file that's included with DBD::mysql; it gives a complete 
list of options. The most common problem, however, is that since you're 
running the self-tests as root, MySQL will want a password. To provide 
that password, you use the --testpassword option, like this:

perl Makefile.PL --testpassword=blah

There are many other options. You can tell it where to find 
mysql_config (if it's not in your PATH), what database to use for the 
self tests, what user to log in as, the host name and port to connect 
to if you want to run the tests against a remote server, etc.

Once you've configured it with the options you need, you can proceed by 
running:

make
make test
If "make test" succeeds, you can install the module with:

make install

If "make test" fails one or more tests, you have a choice to make. If 
you understand what tests failed, and you're certain that the feature 
being tested won't apply to what you're doing, you can go ahead and do 
the "make install" anyway. For that matter, you can skip the "make 
test" step entirely, and install a module without running its 
self-tests; I would recommend living that dangerously, but you can do 
it.

(I just noticed that there's a DBD::mysql package available via Fink. I 
haven't tried it, but it might be a viable option if the above seems 
too imposing.)

Error: Unable to locate installed Perl libraries or Perl source code.
This message usually indicates that you hav

Re: many module questions

[MAC OS X]

On 01 Feb 2004, at 01:11, Christopher Palmer wrote:

I'm in a bit of bind here.  I started an online intro Perl course, and
the current task is to make sure my machine is loaded with the latest
versions of DBI.pm, CGI.pm, and the DBD of my choice.  The instructor
gave the class Windows-centric instructions...so I now have a few
questions/problems...btw - this is the stock perl install with a G5,
and 10.3.
[ .. snip ..]

Being a Mac user I would have doubts about following a Perl course 
where the instructor gives Windows-Centric instructions.

You're going to learn a lot of Windows specific rubbish which you'll 
never use because they do not exist on LINUX*NIX*BSD or Mac OS X.

Win32::EventLog
File::Spec::Win32
Win32::ODBC
etc. etc.
I know Randal has said before that Learning Perl for Windows should 
never have been and that Perl is platform independent but IMHO You 
should follow a Perl course given on a LINUX*NIX*BSD platform. And if 
you're going to develop professionally on a Windows machine, 
commiseration but don't practice on Mac OS X..

Having said that.. Good luck with Learning Perl, buy the book, it is 
excellent and practice on your Mac.

http://www.oreilly.com/catalog/lperl3/

Regards,

Jerry Rocteur

permission denied during open

[timothy driscoll]

greetings,

I am testing my fledling Perl knowledge by creating a new file via a cgi
script, like this:



#! /usr/bin/perl -w

use strict;
use CGI;
use CGIMolv::Error;


my $q = new CGI;

# Parse_form_data is a sub that parses user input from a Web form. 
my %query = Parse_form_data() 
   or error ($q,"Invalid submission.");

my $cmds = $query{cmds};

open (PEVSAVE,">","temp/demo.pev") 
   or error ($q,"unable to create file demo.pev: $!");

print PEVSAVE $cmds;

close PEVSAVE 
   or error ($q,"unable to close file ${filename}${filetype}: $!");




this fails with an error 'Permission denied' when the target dir 'temp' looks
like this:

drwxrwxr-x  3 nobodynobody   102  1 Feb 08:44 temp


but it works if I make the dir writeable by everyone:

drwxrwxrwx  3 nobodynobody   102  1 Feb 08:44 temp


I thought perl ran as nobody, so giving r/w access to 'nobody' should work.
but obviously it doesn't - so what did I do wrong?



thanks for any help,

:tim

-- 
timothy driscoll
molvisions - molecular graphics & visualization

usa:north carolina:wake forest

Re: many module questions

[Charlie Garrison]

Good morning,

On 1/2/04 at 8:11 AM -0500, Sherm Pendley <[EMAIL PROTECTED]> wrote:

>One thing you'll need to do before installing DBD::mysql is install 
>MySQL itself. The simplest way to do that is via Fink. You'll also need 

There is now a package/binary download for OSX from the mySQL site. I think
that is now easier than the fink install. Of course there are still plenty of
other good reasons to use fink, so if you already have fink installed, then
using it to grab mysql may be just as good.

And that was a great reply from Sherm for all of Christopher's questions. I
had forgotten about the cpan 'look' command. I could have used that recently
to save some time had I remembered it.

Charlie

-- 
   Charlie Garrison[EMAIL PROTECTED]
   PO Box 141, Windsor, NSW 2756, Australia

Re: permission denied during open

[Andrew M. Langmead]

On Feb 1, 2004, at 8:59 AM, timothy driscoll wrote:

I thought perl ran as nobody, so giving r/w access to 'nobody' should 
work.
but obviously it doesn't - so what did I do wrong?
Perl runs as the user that invokes the script (except for one
specific circumstance called setuid, but lets ignore that.)
In the context of the CGI protocol, a perl script run in a CGI 
environment
will be run by a web server, and the script will usually run as the user
the web server runs as.

Often, this is a user called nobody. A user who otherwise shouldn't own
anything on the machine. I believe that "nobody" was originally created
on Unix with conjunction with NFS, and it was designed to map the root
user on one machine to an unprivileged account on the other, preventing
the root's authority from spreading from one machine to another. The 
problem
with people reusing nobody for unprivileged accounts for other 
software, is
that security flaws on program to spread to another.

So Apple is a vendor who seems to belong to the school of thought of 
giving
different applications their own unprivileged accounts, and firewall 
applications
from each other. For the web server that is included with OS X, it runs 
as a user
called 'www'.

As a few bits of additional, unsolicited advice; you might want to run 
the
script with "-Tw" on the command line to turn on some extra security 
checking
and the directory that you want to write into you might want to set the
sticky bit (chmod 4777). The "-T" flag will prevent some careless coding
errors become security flaws by tracking user input data and preventing 
it
from being use for anything external to the script. See the perlsec man
page for details.  The sticky bit on a directory will prevent anybody
other than the owner of a file from being able to move or delete the
file. See the sticky(8) man page for details (type "man 8 sticky" at
a shell).

Re: permission denied during open

[Sherm Pendley]

On Feb 1, 2004, at 8:59 AM, timothy driscoll wrote:

open (PEVSAVE,">","temp/demo.pev")
   or error ($q,"unable to create file demo.pev: $!");

this fails with an error 'Permission denied' when the target dir 
'temp' looks
like this:

drwxrwxr-x  3 nobodynobody   102  1 Feb 08:44 temp
The "temp/demo.pev" path above is relative; that is, it refers to a 
directory "temp" that's located in the current working directory. The 
cwd for your CGI script probably isn't the one immediately above the 
"temp/" directory you want to use, so the open fails.

What you need to do is specify a fully-qualified path to temp/. For 
example, "/Users/Timothy/temp/demo.pev".

I thought perl ran as nobody
Perl scripts run as whatever user started them, unless the suid or sgid 
bits are set on the file, in which case they run as the owner/group 
associated with the file.

While Apache is often configured to run as "nobody", the Apache bundled 
with Mac OS X is configured to run as "www". Because CGIs are launched 
as child processes of Apache, they inherit Apache's user, and run as 
"www" also.

sherm--

Re: many module questions

[Phil Dobbin]

On 02/02/2004, at 14:52 (GMT), Charlie Garrison, [EMAIL PROTECTED] wrote:

>Good morning,
>
>On 1/2/04 at 8:11 AM -0500, Sherm Pendley <[EMAIL PROTECTED]> wrote:
>
>>One thing you'll need to do before installing DBD::mysql is install 
>>MySQL itself. The simplest way to do that is via Fink. You'll also need 
>
>There is now a package/binary download for OSX from the mySQL site. I 
>think
>that is now easier than the fink install.

[...]

There is also Marc Liyanage's excellent MySQL binary at:



which is simplicity itself to install and will give you many details/links on how to 
get started,

Regards,

Phil.

Re: permission denied during open

[timothy driscoll]

at 11.08a EDT on 2004 February 01 Sunday Andrew M. Langmead said:

> On Feb 1, 2004, at 8:59 AM, timothy driscoll wrote:
> 
> > I thought perl ran as nobody, so giving r/w access to 'nobody' should
> > work. but obviously it doesn't - so what did I do wrong?
> 
> So Apple is a vendor who seems to belong to the school of thought of
> giving different applications their own unprivileged accounts, and
> firewall applications from each other. For the web server that is
> included with OS X, it runs as a user called 'www'.
> 

ah - www, not nobody.  that fixed it.  thanks very much to everyone who
answered.  and for the "unsolicited advice" - which is always welcome.  :-)

regards,

:tim

-- 
timothy driscoll
molvisions - molecular graphics & visualization

usa:north carolina:wake forest





at 11.08a EDT on 2004 February 01 Sunday Andrew M. Langmead said:

> On Feb 1, 2004, at 8:59 AM, timothy driscoll wrote:
> 
> > I thought perl ran as nobody, so giving r/w access to 'nobody' should
> > work. but obviously it doesn't - so what did I do wrong?
> 
> Perl runs as the user that invokes the script (except for one specific
> circumstance called setuid, but lets ignore that.)
> 
> In the context of the CGI protocol, a perl script run in a CGI
> environment will be run by a web server, and the script will usually
> run as the user the web server runs as.
> 
> Often, this is a user called nobody. A user who otherwise shouldn't own
> anything on the machine. I believe that "nobody" was originally created
> on Unix with conjunction with NFS, and it was designed to map the root
> user on one machine to an unprivileged account on the other, preventing
> the root's authority from spreading from one machine to another. The
> problem with people reusing nobody for unprivileged accounts for other
> software, is that security flaws on program to spread to another.
> 
> So Apple is a vendor who seems to belong to the school of thought of
> giving different applications their own unprivileged accounts, and
> firewall applications from each other. For the web server that is
> included with OS X, it runs as a user called 'www'.
> 
> As a few bits of additional, unsolicited advice; you might want to run
> the script with "-Tw" on the command line to turn on some extra
> security checking and the directory that you want to write into you
> might want to set the sticky bit (chmod 4777). The "-T" flag will
> prevent some careless coding errors become security flaws by tracking
> user input data and preventing it from being use for anything external
> to the script. See the perlsec man page for details.  The sticky bit on
> a directory will prevent anybody other than the owner of a file from
> being able to move or delete the file. See the sticky(8) man page for
> details (type "man 8 sticky" at a shell).
> 

Re: permission denied during open

[Rick Measham]

On 2 Feb 2004, at 12:59 am, timothy driscoll wrote:
this fails with an error 'Permission denied' when the target dir 
'temp' looks
like this:

drwxrwxr-x  3 nobodynobody   102  1 Feb 08:44 temp

but it works if I make the dir writeable by everyone:

drwxrwxrwx  3 nobodynobody   102  1 Feb 08:44 temp

I thought perl ran as nobody, so giving r/w access to 'nobody' should 
work.
but obviously it doesn't - so what did I do wrong?
G'day Tim,

perl itself will run as whoever calls it. In the case of CGI it will be 
run by Apache or whichever http server you're running.

By default apache used to run as 'nobody.nobody', then on some installs 
it runs as 'apache.apache'. However, on MacOS-X it runs as 'www.www'. 
Check the httpd.conf file to see (It's the 'user' and 'group' 
directives).

Assuming you're on OS-X, set your file's owner.group to www.www and you 
should be fine with a 744.

Cheers!
Rick


Rick Measham
Senior Designer and Developer
Printaform Pty Ltd
Tel: (03) 9850 3255
Fax: (03) 9850 3277
http://www.printaform.com.au
http://www.printsupply.com.au
vcard: http://www.printaform.com.au/staff/rickm.vcf

Re: permission denied during open

[Rick Measham]

OK, I'm a git. I didn't scroll down so I didn't realise this had 
already been answered half a dozen times. Sorry!

On 2 Feb 2004, at 10:32 am, Rick Measham wrote:

On 2 Feb 2004, at 12:59 am, timothy driscoll wrote:
this fails with an error 'Permission denied' when the target dir 
'temp' looks
like this:

drwxrwxr-x  3 nobodynobody   102  1 Feb 08:44 temp

but it works if I make the dir writeable by everyone:

drwxrwxrwx  3 nobodynobody   102  1 Feb 08:44 temp

I thought perl ran as nobody, so giving r/w access to 'nobody' should 
work.
but obviously it doesn't - so what did I do wrong?
G'day Tim,

perl itself will run as whoever calls it. In the case of CGI it will 
be run by Apache or whichever http server you're running.

By default apache used to run as 'nobody.nobody', then on some 
installs it runs as 'apache.apache'. However, on MacOS-X it runs as 
'www.www'. Check the httpd.conf file to see (It's the 'user' and 
'group' directives).

Assuming you're on OS-X, set your file's owner.group to www.www and 
you should be fine with a 744.

Cheers!
Rick


Rick Measham
Senior Designer and Developer
Printaform Pty Ltd
Tel: (03) 9850 3255
Fax: (03) 9850 3277
http://www.printaform.com.au
http://www.printsupply.com.au
vcard: http://www.printaform.com.au/staff/rickm.vcf
Rick Measham
Senior Designer and Developer
Printaform Pty Ltd
Tel: (03) 9850 3255
Fax: (03) 9850 3277
http://www.printaform.com.au
http://www.printsupply.com.au
vcard: http://www.printaform.com.au/staff/rickm.vcf

Image::Magick - "Segmentation fault"

[kynan]

Hi all,

I haven't used perl for years but am starting to get into it again  
since getting Panther. I have apparently managed to get Image:Magick  
installed (instructions at  
http://maikimo.net/weblog/archives/2002/12/27/ 
building_imagemagick_in_mac_os_x_jaguar_with_perl_580.html if anyone's  
interested - CPAN doesn't work and Fink needs a bit of help too) but  
have stalled at the first hurdle:

   # MAKE A NEW Image::Magick OBJECT
   my $p = new Image::Magick;
   # READ IT
   $p->Read("$fullPath/test.jpg");
   # DEBUG
   print "GOT HERE\n";
The script stops before it prints the DEBUG info and outputs:

"Segmentation fault"

This has also been posted on site I mentioned but I can't find any  
other mention of it. Any ideas? Like, is it something that only happens  
when there's a problem with a module?

Thanks,

K



+

Kynan Hughes

phone 9281 2088
fax 9211 4433
mobile 0411 231099
Additive design pty ltd
Amitabha pty ltd
http://www.additive.net.au
Level 4, 104 Commonwealth St
Surry Hills NSW 2010
Australia
+

Re: Setting empty type/creator codes?

[John Gruber]

John Gruber <[EMAIL PROTECTED]> wrote on 1/31/04 at 3:24a:

> If I do this:
> 
> MacPerl::SetFileInfo('', '', $f);
> 
> the type and creator are set to garbage values. I can't figure out a
> way to do it using the developer tools' SetFile command, nor using
> AppleScript. The problem is that with all three techniques --
> MacPerl, SetFile, and AppleScript -- the underlying mechanism
> insists on 4-character strings for the values, and refuses to coerce
> and empty string into a blank OSType.

Answering my own question, based on an AppleScript solution sent to
me by Jim Correia:

#!/usr/bin/perl
use strict;
use warnings;
use MacPerl;
foreach my $f (@ARGV) {
MacPerl::SetFileInfo("\0\0\0\0", "\0\0\0\0", $f);
}

-J.G.

Re: Image::Magick - "Segmentation fault"

[robert ackerman]

On Feb 1, 2004, at 7:13 PM, kynan wrote:

   # MAKE A NEW Image::Magick OBJECT
   my $p = new Image::Magick;
   # READ IT
   $p->Read("$fullPath/test.jpg");
...
can u show us that $fullPath exists, is valid, and doesn't end in a 
slash?