The principle of include files in PHP, not as in C++

[duzhidian]

failed to open stream: No such file or directory

I have the programs like this structure:

a.php is locate at .
b.php is located at ./lib
c.php is located at ./lib/sublib

a.php uses a function at b.php while b.php using a function at c.php

In a.php, it says: include_once(./lib/b.php) as it uses one function
in b.php
a.php is not supposed to know that b.php is using c.php, so it should
not include c.php.
In b.php, it says: include_once(./sublib/c.php) since it uses a
function in c.php.
b.php is not supposed to know that a.php uses itself, so it should not
include lib as include_once(../lib/sublib/c.php), but it does not
work.
The problem is: "... failed to open stream: No such file or directory
of c.php. .."

If using include_once(../lib/sublib/c.php) in b.php, the compiler is
happy. But it violates the general principle of who include files
only considering itself at it own position, not considering others who
use it (also, it is not supposed to know it) as in C++.
Any hints how to obey the above principle?

Thanks.

D.

[Lars Eighner]

In our last episode, <11*********************@i13g2000prf.googlegroups. com>,
the lovely and talented du*******@gmail.com broadcast on comp.lang.php:

If I move the programs to other places, using absolute paths will
suffer, need to change every file.

Generally I use a project.ini where I use set_ini to modify the include path
for the project, then I never have to use paths in includes except for the
path to project.ini (possibly), but since it is a perl one-line to change
that (if necessary) I don't see the problem.

PS: why ./lib/b.php instead of lib/b.php ?
--
Lars Eighner <http://larseighner.com/ <http://myspace.com/larseighner>
Countdown: 462 days to go.
What do you do when you're debranded?

[Jerry Stuckle]

Lars Eighner wrote:

In our last episode, <11*********************@i13g2000prf.googlegroups. com>,
the lovely and talented du*******@gmail.com broadcast on comp.lang.php:

>If I move the programs to other places, using absolute paths will
suffer, need to change every file.

Generally I use a project.ini where I use set_ini to modify the include path
for the project, then I never have to use paths in includes except for the
path to project.ini (possibly), but since it is a perl one-line to change
that (if necessary) I don't see the problem.

PS: why ./lib/b.php instead of lib/b.php ?

Until you run into two files with the same name... As in two different
packages.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[duzhidian]

Thanks for your guys info. All your suggestions is to use absolute
path somewhere.

In fact, here is my scenario, *SAME* file name, different location:

a. one php is locate at . called ./mylib.php
b. another php file is located at ./lib/mylib.php
c. third php file is located at ./lib/sublib/mylib.php
a calls a function in b while b calls a function in c.

What I need is just a clear picture how to include files in a and b,
i.e. in ./mylib.php and in ./lib/mylib.php without any trouble when
moving and future extension.
I can organize the codes, but it does not seems as transparent as what
c/c++ does as one file at root have to consider it's grandsons'
functions (location), not supposed to do that in c/c++.

Thanks again.

Du.

[Jerry Stuckle]

du*******@gmail.com wrote:

Thanks for your guys info. All your suggestions is to use absolute
path somewhere.

In fact, here is my scenario, *SAME* file name, different location:

a. one php is locate at . called ./mylib.php
b. another php file is located at ./lib/mylib.php
c. third php file is located at ./lib/sublib/mylib.php
a calls a function in b while b calls a function in c.

What I need is just a clear picture how to include files in a and b,
i.e. in ./mylib.php and in ./lib/mylib.php without any trouble when
moving and future extension.
I can organize the codes, but it does not seems as transparent as what
c/c++ does as one file at root have to consider it's grandsons'
functions (location), not supposed to do that in c/c++.

Thanks again.

Du.

You're still using relative paths. Anything starting with ".", ".." or
a path name is relative.

Absolute paths start with / in linux/unix.

It works exactly the same in C/C++. Relative paths there are relative
to the executable.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Tim Roberts]

Jerry Stuckle <js*******@attglobal.netwrote:

>du*******@gmail.com wrote:

>>
I can organize the codes, but it does not seems as transparent as what
c/c++ does as one file at root have to consider it's grandsons'
functions (location), not supposed to do that in c/c++.

You're still using relative paths. Anything starting with ".", ".." or
a path name is relative.

Absolute paths start with / in linux/unix.

It works exactly the same in C/C++. Relative paths there are relative
to the executable.

You missed the point. He's talking about #include files, and he is quite
correct. In C/C++, you never ever ever use an absolute pathname in an
#include statement. Further, the preprocessor rule is that relative paths
in an #include statement are relative to the directory that contains the
file being scanned.

PHP's rules are different. Not better, not worse. Just different.
--
Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.

[Rik Wasmus]

On Tue, 16 Oct 2007 03:49:05 +0200, du*******@gmail.com
<du*******@gmail.comwrote:

Thanks for your guys info. All your suggestions is to use absolute
path somewhere.

I gave you a perfectly serviceable solution.
1. Store current working dir somewhere ( $cwd = getcwd(); ).
2. Set current working dir to the one of the file
( chdir(dirname(__FILE__)); ).
3. Do a relative include/require/fopen/etc..
4. Restore the current working dir to the one you stored ( chdir($cwd); ).
--
Rik Wasmus

[duzhidian]

On Oct 16, 2:10 am, Tim Roberts <[e-mail]:

Jerry Stuckle <[e-mail]:

[e-mail] wrote:

I can organize the codes, but it does not seems as transparent as what
c/c++ does as one file at root have to consider it's grandsons'
functions (location), not supposed to do that in c/c++.

You're still using relative paths. Anything starting with ".", ".." or
a path name is relative.

Absolute paths start with / in linux/unix.

It works exactly the same in C/C++. Relative paths there are relative
to the executable.

You missed the point. He's talking about #include files, and he is quite
correct. In C/C++, you never ever ever use an absolute pathname in an
#include statement. Further, the preprocessor rule is that relative paths
in an #include statement are relative to the directory that contains the
file being scanned.

PHP's rules are different. Not better, not worse. Just different.
--
Tim Roberts, [e-mail]
Providenza & Boekelheide, Inc.

Yes, you are right. I was trying using C/C++ rules onto PHP programs
and it caused some problems. I can figure it out. Anyway, thanks
your guys.

[Jerry Stuckle]

Tim Roberts wrote:

Jerry Stuckle <js*******@attglobal.netwrote:

>du*******@gmail.com wrote:

>>I can organize the codes, but it does not seems as transparent as what
c/c++ does as one file at root have to consider it's grandsons'
functions (location), not supposed to do that in c/c++.

You're still using relative paths. Anything starting with ".", ".." or
a path name is relative.

Absolute paths start with / in linux/unix.

It works exactly the same in C/C++. Relative paths there are relative
to the executable.

You missed the point. He's talking about #include files, and he is quite
correct. In C/C++, you never ever ever use an absolute pathname in an
#include statement. Further, the preprocessor rule is that relative paths
in an #include statement are relative to the directory that contains the
file being scanned.

PHP's rules are different. Not better, not worse. Just different.

No, you missed the point.

Compilation is not the same as execution. When PHP is executed, it's
include statement works just alike any file operation in C/C++ when that
program is executed.

Just because they are both "include" statements does not mean they are
the same. In PHP they are executed. In C/C++ they are handled by the
preprocessor. Completely different environment with completely
different results.

And you are incorrect. In C/C++, include files are relative to the list
of directories in the -I (INCLUDE) compiler option (which can also be
specified in some IDE's). And you can use absolute paths in #include
statements.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Alexey Kulentsov]

Tim Roberts wrote:

>
PHP's rules are different. Not better, not worse. Just different.

Yes, not worse but just fully idiotic.
You have to use include_once
dirname(__FILE__).'some_path_to_file.php' to get portable code
independent from server.

[AnrDaemon]

Greetings, Alexey Kulentsov.
In reply to Your message dated Tuesday, October 16, 2007, 22:55:14,

AK You have to use include_once
AKdirname(__FILE__).'some_path_to_file.php' to get portable code
AKindependent from server.

dirname(__FILE__).'/some_path_to_file.php'

Exactly.
--
Sincerely Yours, AnrDaemon <an*******@freemail.ru>

[Rik Wasmus]

On Tue, 16 Oct 2007 20:55:14 +0200, Alexey Kulentsov <ak**@inbox.ruwrote:

Tim Roberts wrote:

> PHP's rules are different. Not better, not worse. Just different.

Yes, not worse but just fully idiotic.
You have to use include_once
dirname(__FILE__).'some_path_to_file.php' to get portable code
independent from server.

PHP was never meant to be independant from a server.... It can be, not the
general idea though.
--
Rik Wasmus

[Tim Roberts]

Jerry Stuckle <js*******@attglobal.netwrote:

>Tim Roberts wrote:

>>
You missed the point. ...
PHP's rules are different. Not better, not worse. Just different.

No, you missed the point.

Compilation is not the same as execution. When PHP is executed, it's
include statement works just alike any file operation in C/C++ when that
program is executed.

Just because they are both "include" statements does not mean they are
the same. In PHP they are executed. In C/C++ they are handled by the
preprocessor. Completely different environment with completely
different results.

Nonsense. The distinction between compilation and interpolation is
entirely artificial. PHP can be compiled, just as C can be interpreted.
We're talking about source files including other source files. The concept
is the same. PHP has different rules from C. It's just that simple, and I
don't know why you want to make it more complicated.

>And you are incorrect. In C/C++, include files are relative to the list
of directories in the -I (INCLUDE) compiler option (which can also be
specified in some IDE's). And you can use absolute paths in #include
statements.

I never denied that. However, I am NOT incorrect. The first place C and
C++ look for an "included" file is in the directory of the file currently
being scanned. If not found there, only then does the preprocessor move on
to the -I list.

If the #include uses angle brackets (i.e. <stdio.h>), THEN the current
directory is skipped and it goes straight to the -I path.
--
Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.