Help with strange include problem in PHP 5.2.0

Hi all,

I have a strange problem including files in PHP 5.2.0 running on Unix. If I
try to include a file using include 'filename.inc';, everything is fine. As
soon as I try to put a "." in front of the file name, for example
include './filename.inc';, I get a "failed to open stream: No such file or
directory" error. Does anyone have any suggestions as to what is going
wrong?` This all works with php 4.4.4 built with the same environment and
compiler on the same system.

thanks
Markus

The files I am testing are:
include.php:
<?php
$result = include 'filename.inc';
echo "Result of first include = $result";
$result = include './filename.inc';
echo "Result of second include = $result";
$result = include './include_test_dir/filename.inc';
echo "Result of third include = $result";
?>


filename.inc:
<?php
echo "I am the included file...";
?>


# ls -l
total 6
-rw-r--r-- 1 root webservd 44 Nov 30 13:45 filename.inc
-rw-r--r-- 1 root webservd 265 Nov 30 13:45 include.php
drwxr-sr-x 2 root webservd 512 Nov 30 13:44 include_test_dir
# ls -l include_test_dir/
total 2
-rw-r--r-- 1 root webservd 21 Nov 30 13:45 filename.inc

On Thu, November 30, 2006 6:49 am, Markus Mayer wrote:
> I have a strange problem including files in PHP 5.2.0 running on Unix.
> If I
> try to include a file using include 'filename.inc';, everything is
> fine. As
> soon as I try to put a "." in front of the file name, for example
> include './filename.inc';, I get a "failed to open stream: No such
> file or
> directory" error. Does anyone have any suggestions as to what is
> going
> wrong?` This all works with php 4.4.4 built with the same environment
> and
> compiler on the same system.

What is your include path in PHP 5.2.0?

I'm going to go out on a limb and bet a dollar that the PHP 4.4.4
include_path has "." as one element within the list and that the PHP
5.2.0 include_path does NOT have "." within the list.

I.e.:
4.4.4 include_path ".:include_test_dir"
5.2.0 include_path "include_test_dir"

In the first case, 4.4.4, you've got . in there, so . combined with ./
will "find" the file you want.

In the second case, 5.2.0, you've got no . in there, so ./ is looking
in a directory, not the directory you expect, and it ain't finding the
file because it's not there.

Rant #24, not directed at Markus, but the world at large :-)
PHP developers should understand and use include_path instead of
hacking up their source with hard-coded paths and weird sub-directory
/ parent-directory hacks in include/require statements.

It drives me nuts when I install nice software packages, but I can't
put their components where I want them.

End result:
rm -rf [insert your nifty project directory name here]

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

Hi Richard,
Hi all,

The include path is correct. That was one of the first things I played around
with. At the moment, it's include_path = ".". I also tried renaming the
php.ini file to php.ini.off so that it wasn't found and took all the
defaults, but with no success.

Last night I built PHP 5.1.6 and took the same php.ini file. Everything
worked. The build environment was the same, the configure arguments were the
same, only the php version was different.

I'm guessing that I've done something wrong somewhere because I haven't found
any references to this problem from any one else. I just have no idea what
it could be. I don't know if it's any help in locating the problem, my build
environment is Solaris 10, Sun Studio 10 with the Sun C and C++ compilers.
# cc-V
Sun C 5.7 2005/01/07
# CC -V
CC: Sun C++ 5.7 2005/01/07

LDFLAGS=-L/opt/sfw/lib -L/usr/sfw/lib -L/usr/lib -R/opt/sfw/lib:/usr/sfw/lib:/usr/lib:/opt/oracle/instantclient_10_2
CPPFLAGS=-I/opt/sfw/include -I/usr/sfw/include/openssl -I/usr/local/BerkeleyDB/include -I/usr/include -I/opt/oracle/instantclient_10_2/sdk/include
CFLAGS=-I/opt/sfw/include -I/usr/sfw/include/openssl -I/usr/local/BerkeleyDB/include -I/usr/include -I/opt/oracle/instantclient_10_2/sdk/include

And to your "rant" about the code developers make - I totally agree with you.
As the administrator of a server with close to 600 users who all put their
own applications in their own accounts up, then ask me why it "doesn't work",
I get annoyed at such things too.

regards
Markus



On Thursday 30 November 2006 19:04, Richard Lynch wrote:
> On Thu, November 30, 2006 6:49 am, Markus Mayer wrote:
> > I have a strange problem including files in PHP 5.2.0 running on Unix.
> > If I
> > try to include a file using include 'filename.inc';, everything is
> > fine. As
> > soon as I try to put a "." in front of the file name, for example
> > include './filename.inc';, I get a "failed to open stream: No such
> > file or
> > directory" error. Does anyone have any suggestions as to what is
> > going
> > wrong?` This all works with php 4.4.4 built with the same environment
> > and
> > compiler on the same system.
>
> What is your include path in PHP 5.2.0?
>
> I'm going to go out on a limb and bet a dollar that the PHP 4.4.4
> include_path has "." as one element within the list and that the PHP
> 5.2.0 include_path does NOT have "." within the list.
>
> I.e.:
> 4.4.4 include_path ".:include_test_dir"
> 5.2.0 include_path "include_test_dir"
>
> In the first case, 4.4.4, you've got . in there, so . combined with ./
> will "find" the file you want.
>
> In the second case, 5.2.0, you've got no . in there, so ./ is looking
> in a directory, not the directory you expect, and it ain't finding the
> file because it's not there.
>
> Rant #24, not directed at Markus, but the world at large :-)
> PHP developers should understand and use include_path instead of
> hacking up their source with hard-coded paths and weird sub-directory
> / parent-directory hacks in include/require statements.
>
> It drives me nuts when I install nice software packages, but I can't
> put their components where I want them.
>
> End result:
> rm -rf [insert your nifty project directory name here]
>
> --
> Some people have a "gift" link here.
> Know what I want?
> I want you to buy a CD from some starving artist.
> http://cdbaby.com/browse/from/lynch
> Yeah, I get a buck. So?

On Thursday 30 November 2006 19:04, Richard Lynch wrote:
[snip...]
And of course I forgot to put in the configure arguments....

'./configure' \
'--without-pear' \
'--with-apxs2=/usr/local/apache2/bin/apxs' \
'--enable-mm=shared' \
'--with-mysql=/usr/local/MySQL/mysql-standard-5.0.27-solaris10-sparc' \
'--with-ldap=/usr/local/open-ldap' \
'--with-openssl=/usr/sfw/' \
'--with-zlib' \
'--enable-inline-optimization' \
'--enable-mm=shared' \
'--with-libxml-dir=/usr/local/lib/libxml-2.6.27' \
'--with-oci8=/opt/oracle/instantclient_10_2' \
"$@"

Try running it under some kind of debugger and see if you can figure
out what directories it's even checking when it doesn't find the
file...

I dunno if Zend IDE (or whatever it's called now) or Komodo or XDebug
or whatnot will do that, but it's definitely sounding very odd if your
include_path has "." in it...

Oooh...
What does PHP think your cwd is?
echo '<hr />cwd: ', cwd(), "<hr />\n";
right before the include.

On Fri, December 1, 2006 3:47 am, Markus Mayer wrote:
> Hi Richard,
> Hi all,
>
> The include path is correct. That was one of the first things I
> played around
> with. At the moment, it's include_path = ".". I also tried renaming
> the
> php.ini file to php.ini.off so that it wasn't found and took all the
> defaults, but with no success.
>
> Last night I built PHP 5.1.6 and took the same php.ini file.
> Everything
> worked. The build environment was the same, the configure arguments
> were the
> same, only the php version was different.
>
> I'm guessing that I've done something wrong somewhere because I
> haven't found
> any references to this problem from any one else. I just have no idea
> what
> it could be. I don't know if it's any help in locating the problem,
> my build
> environment is Solaris 10, Sun Studio 10 with the Sun C and C++
> compilers.
> # cc-V
> Sun C 5.7 2005/01/07
> # CC -V
> CC: Sun C++ 5.7 2005/01/07
>
> LDFLAGS=-L/opt/sfw/lib -L/usr/sfw/lib -L/usr/lib
> -R/opt/sfw/lib:/usr/sfw/lib:/usr/lib:/opt/oracle/instantclient_10_2
> CPPFLAGS=-I/opt/sfw/include -I/usr/sfw/include/openssl
> -I/usr/local/BerkeleyDB/include -I/usr/include
> -I/opt/oracle/instantclient_10_2/sdk/include
> CFLAGS=-I/opt/sfw/include -I/usr/sfw/include/openssl
> -I/usr/local/BerkeleyDB/include -I/usr/include
> -I/opt/oracle/instantclient_10_2/sdk/include
>
> And to your "rant" about the code developers make - I totally agree
> with you.
> As the administrator of a server with close to 600 users who all put
> their
> own applications in their own accounts up, then ask me why it "doesn't
> work",
> I get annoyed at such things too.
>
> regards
> Markus
>
>
>
> On Thursday 30 November 2006 19:04, Richard Lynch wrote:
>> On Thu, November 30, 2006 6:49 am, Markus Mayer wrote:
>> > I have a strange problem including files in PHP 5.2.0 running on
>> Unix.
>> > If I
>> > try to include a file using include 'filename.inc';, everything is
>> > fine. As
>> > soon as I try to put a "." in front of the file name, for example
>> > include './filename.inc';, I get a "failed to open stream: No such
>> > file or
>> > directory" error. Does anyone have any suggestions as to what is
>> > going
>> > wrong?` This all works with php 4.4.4 built with the same
>> environment
>> > and
>> > compiler on the same system.
>>
>> What is your include path in PHP 5.2.0?
>>
>> I'm going to go out on a limb and bet a dollar that the PHP 4.4.4
>> include_path has "." as one element within the list and that the PHP
>> 5.2.0 include_path does NOT have "." within the list.
>>
>> I.e.:
>> 4.4.4 include_path ".:include_test_dir"
>> 5.2.0 include_path "include_test_dir"
>>
>> In the first case, 4.4.4, you've got . in there, so . combined with
>> ./
>> will "find" the file you want.
>>
>> In the second case, 5.2.0, you've got no . in there, so ./ is
>> looking
>> in a directory, not the directory you expect, and it ain't finding
>> the
>> file because it's not there.
>>
>> Rant #24, not directed at Markus, but the world at large :-)
>> PHP developers should understand and use include_path instead of
>> hacking up their source with hard-coded paths and weird
>> sub-directory
>> / parent-directory hacks in include/require statements.
>>
>> It drives me nuts when I install nice software packages, but I can't
>> put their components where I want them.
>>
>> End result:
>> rm -rf [insert your nifty project directory name here]
>>
>> --
>> Some people have a "gift" link here.
>> Know what I want?
>> I want you to buy a CD from some starving artist.
>> http://cdbaby.com/browse/from/lynch
>> Yeah, I get a buck. So?
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

Hi Richard,

I think I've identified the problem. It appears to be a problem with
PHPMyAdmin rather than PHP itself.

The directory permissions we have are the minimum we need, usually 710, file
permissions are 640. The group part of the permissions is how the apache
gets to the files in the directories. This time I did the installation of
PMA and changed all the directory and file permissions according to the
standards here. As it turns out, PMA demands read permission on the
directory in which it's distribution directory is installed. That is:

/usr/local/htdocs# ls -la pma/
total 16
drwxr-x--- 4 root webservd 512 Dec 6 10:48 .
drwxrwx--- 17 root webservd 2048 Dec 6 10:22 ..
drwxr-xr-x 9 root webservd 2048 Nov 30 14:06 phpMyAdmin-2.8.1
drwx--x--- 10 root webservd 2560 Dec 1 12:36
phpMyAdmin-2.9.1.1-all-languages

If the permission of this directory listed above has 710 instead of 750, PMA
falls over!

/usr/local/htdocs# ls -la pma/
total 16
drwx--x--- 4 root webservd 512 Dec 6 10:48 .
drwxrwx--- 17 root webservd 2048 Dec 6 10:22 ..
drwx--x--- 9 root webservd 2048 Nov 30 14:06 phpMyAdmin-2.8.1
drwx--x--- 10 root webservd 2560 Dec 1 12:36
phpMyAdmin-2.9.1.1-all-languages

It took quite a bit of scratching my head until I found this out. In
particular, PMA 2.9.1.1 really falls over with the 710 permissions that are
currently set. I think now I need to file a PMA bug report.

thanks for the suggestions you made, they did help me find this problem.

regards
Markus

On Friday 01 December 2006 22:27, Richard Lynch wrote:
> Try running it under some kind of debugger and see if you can figure
> out what directories it's even checking when it doesn't find the
> file...
>
> I dunno if Zend IDE (or whatever it's called now) or Komodo or XDebug
> or whatnot will do that, but it's definitely sounding very odd if your
> include_path has "." in it...
>
> Oooh...
> What does PHP think your cwd is?
> echo '<hr />cwd: ', cwd(), "<hr />\n";
> right before the include.
>
> On Fri, December 1, 2006 3:47 am, Markus Mayer wrote:
> > Hi Richard,
> > Hi all,
> >
> > The include path is correct. That was one of the first things I
> > played around
> > with. At the moment, it's include_path = ".". I also tried renaming
> > the
> > php.ini file to php.ini.off so that it wasn't found and took all the
> > defaults, but with no success.
> >
> > Last night I built PHP 5.1.6 and took the same php.ini file.
> > Everything
> > worked. The build environment was the same, the configure arguments
> > were the
> > same, only the php version was different.
> >
> > I'm guessing that I've done something wrong somewhere because I
> > haven't found
> > any references to this problem from any one else. I just have no idea
> > what
> > it could be. I don't know if it's any help in locating the problem,
> > my build
> > environment is Solaris 10, Sun Studio 10 with the Sun C and C++
> > compilers.
> > # cc-V
> > Sun C 5.7 2005/01/07
> > # CC -V
> > CC: Sun C++ 5.7 2005/01/07
> >
> > LDFLAGS=-L/opt/sfw/lib -L/usr/sfw/lib -L/usr/lib
> > -R/opt/sfw/lib:/usr/sfw/lib:/usr/lib:/opt/oracle/instantclient_10_2
> > CPPFLAGS=-I/opt/sfw/include -I/usr/sfw/include/openssl
> > -I/usr/local/BerkeleyDB/include -I/usr/include
> > -I/opt/oracle/instantclient_10_2/sdk/include
> > CFLAGS=-I/opt/sfw/include -I/usr/sfw/include/openssl
> > -I/usr/local/BerkeleyDB/include -I/usr/include
> > -I/opt/oracle/instantclient_10_2/sdk/include
> >
> > And to your "rant" about the code developers make - I totally agree
> > with you.
> > As the administrator of a server with close to 600 users who all put
> > their
> > own applications in their own accounts up, then ask me why it "doesn't
> > work",
> > I get annoyed at such things too.
> >
> > regards
> > Markus
> >
> > On Thursday 30 November 2006 19:04, Richard Lynch wrote:
> >> On Thu, November 30, 2006 6:49 am, Markus Mayer wrote:
> >> > I have a strange problem including files in PHP 5.2.0 running on
> >>
> >> Unix.
> >>
> >> > If I
> >> > try to include a file using include 'filename.inc';, everything is
> >> > fine. As
> >> > soon as I try to put a "." in front of the file name, for example
> >> > include './filename.inc';, I get a "failed to open stream: No such
> >> > file or
> >> > directory" error. Does anyone have any suggestions as to what is
> >> > going
> >> > wrong?` This all works with php 4.4.4 built with the same
> >>
> >> environment
> >>
> >> > and
> >> > compiler on the same system.
> >>
> >> What is your include path in PHP 5.2.0?
> >>
> >> I'm going to go out on a limb and bet a dollar that the PHP 4.4.4
> >> include_path has "." as one element within the list and that the PHP
> >> 5.2.0 include_path does NOT have "." within the list.
> >>
> >> I.e.:
> >> 4.4.4 include_path ".:include_test_dir"
> >> 5.2.0 include_path "include_test_dir"
> >>
> >> In the first case, 4.4.4, you've got . in there, so . combined with
> >> ./
> >> will "find" the file you want.
> >>
> >> In the second case, 5.2.0, you've got no . in there, so ./ is
> >> looking
> >> in a directory, not the directory you expect, and it ain't finding
> >> the
> >> file because it's not there.
> >>
> >> Rant #24, not directed at Markus, but the world at large :-)
> >> PHP developers should understand and use include_path instead of
> >> hacking up their source with hard-coded paths and weird
> >> sub-directory
> >> / parent-directory hacks in include/require statements.
> >>
> >> It drives me nuts when I install nice software packages, but I can't
> >> put their components where I want them.
> >>
> >> End result:
> >> rm -rf [insert your nifty project directory name here]
> >>
> >> --
> >> Some people have a "gift" link here.
> >> Know what I want?
> >> I want you to buy a CD from some starving artist.
> >> http://cdbaby.com/browse/from/lynch
> >> Yeah, I get a buck. So?
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php