Sane

I have a perl script that works fine when I access it via HTTP, but when I telnet into the server, and run the Perl script that way ("perl my_file.pl") I get an error saying it can't find some of the script's .pm files in @INC.

How can I get it to work from the shell, and not just when it's called from Apache?

DaWei

Is everything you have locally available remotely? In the same places?

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Sane

Hmm, either you're ahead of me already, or I messed up my explanation.

When I say "locally" I mean remotely with respect to my computer, but locally with respect to the server. So all of the resources should be the same, since it's being run in the same location. Is that correct?

DaWei

Hmmmm. I don't know. Let me just ask a question: is it possible that when accessed via http that the paths involved are relative to the document root, whereas they're different via telenet?

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Sane

Sounds entirely possible. When I ran it in telnet, the working directory was the same as the directory the script was located within. Maybe Apache makes the working directory the Perl folder or something.

I will write a script to output where it was called from to find out.

Edit : Well, that's interesting. /www/user/cgi-bin

It says the (absolute) working directory is one that doesn't even exist. Where the hank is /www/ on my machine?

DaWei

Mine's Apache2/htdocs/www.

It was a lucky shot in the dark. I get bit by it all the time writing PHP. Some paths need to be URLs, which relate to home (www), others need to deal with the filesystem path.

EDIT. If your server is a paid host, check the environment variables for something like DOCUMENT_ROOT. Mine is, for example, /mnt/w0302/d08/s33/b0246102/www. The part before www is the environment variable, HOMEDIR. In my case, the filesystem path to cgi-bin is under HOMEDIR, but Apache/my host map it, URL-wise, as if it's a subdirectory of www.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Sane

Hmm, I have a guess on what the problem is.

I printed out @INC (the equivilent of PATH for Perl), when it was run in the terminal, and it's identical to the @INC from when it's called by Apache.

Although the PATH is the same, it's missing the one pm file "DBD/mysql.pm". This is the only pm file it's missing out of all the files it includes. And I can't find that anywhere on the computer.

It didn't occur to me until now that the "server" I'm accessing might not be a server at all. I believe it's a document repository that's pointed to by Apache to serve the files.

Okay, I just checked. There's two separate IPs. One IP for the website, and one IP for the "server".

Since "DBD/mysql.pm" is not specified in @INC, but Apache can still find it, it's probably on the other computer.

There's not going to be a way around this is there? How can I confirm that "DBD/mysql.pm" is indeed not on the server, but on the Apache server, before I report this to my boss? I don't want to tell him some made-up problem without any proof.

DaWei

Sorry, I have no idea. You picked my brain clean on the subject.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

stevengs

gee, this is fun...

__________________
-Steven
"Is this a piece of your brain?" - Basil Fawlty

stevengs

Have you considered the file privileges?

viele Grüße
Steven

__________________
-Steven
"Is this a piece of your brain?" - Basil Fawlty