require and dir parsing

prp

Hi all. I ran into a strange problem with nested require statements and how directory positions are parsed when I moved my code from one host to another. I am wondering what I should do about it...

In /index.php, I have a call:

 require "common/prpsql.php";

Which works fine. In common/prpsql.php, I have another call:

 require "common/browse.php";

This works fine on two hosts (linux/apache/php4 and XPPro/apache/php4), but not on another (WinNT/MS-IIS/php4).
On the "broken" host, it seems that php interprets the call in prpsql.php as originating in the common/ directory, and cannot find /common/common/browse.php. On the "unbroken" hosts, the source location is interpreted as / since that's where the starting file (index.php) is, no matter how many nested require statements there are. What's going on? Why is the behavior different? And what's the right way to handle this (include_path?)?

mtimdog

what happens if you change it to ./common/browse.php ??

prp

Hi. I tried that, but it acted the same way. I think the ./ just brings it back to common/. I also tried ../common/browse.php and /common/browse.php which didn't work either. The only thing that worked was simply require "browse.php".

tekky

I ran into this problem before and what I did was write a function to append ../../.. based on the directory depth of the FULL path from a given directory....

so... common/file.php would turn into ../common/file.php
and file.php would just return file.php

some/other/file.php would be ../../some/other/file.php

hope that makes sense 😉

mtimdog

very interesting....if you change the requires to includes what happens?

Also, is the second require inside a conditional statement (i.e. if{})?? If it is, did you put {} around it??

prp

Changing the requires to includes makes no difference. I also checked all of my require statements and they are all properly bracketed.

The thing that is bugging me is why would the behavior be different from host to host? Is there some php config variable that would account for the shift in behavior?

mtimdog

Well, according to the php bug reports....

When you use include("/some/path"); you are using
the absolute path in the file system, not the relative
path to your webroot.

....this was "fixed" in php 4.3

So, you need to put the ./ in front of both files.

prp

I still don't get it. First of all, the two hosts that work are running php 4.3.4, and the one that doesn't is running 4.3.3. I don't think that would account for the difference.

Also, I don't understand how using ./ helps - doesn't the "./" just mean the current directory?

In the meantime, I am trying to avoid the problem altogether by changing the include_path variable using ini_set, and adding the common dir to the path. That way, I think, once the ini_set is executed, all other references can just call out the file name (i.e. browse.php) and not worry about the path.

mtimdog

Well, supposedly if you put int /dir/file.php it looks for it absolutely at /dir/file.php and then looks at the include path to find it.

To use relative links one would use ./ or ../ I suppose.

p.s. it's possible that your last 2 hosts had . in the php.ini include_dir list and the new one does not have .

prp

Hmmm... all three hosts have "." in the include_path.

I'm moving forward with changing the include_path at this point, and I'll see if that works ok across all three hosts. Unfortunately, each ini_set call has to be different to accommodate the underlying OS's path conventions.

Thanks for your help in thinking about this problem!