Je n'arrive pas à comprendre le jeu de règles concernant PHP, les chemins d'accès relatifs. Si j'exécute le fichier A.PHP et le fichier A.PHP inclut le fichier B.PHP, qui inclut le fichier C.PHP, si le le chemin relatif vers C.PHP soit par rapport à l’emplacement de B.PHP ou à l’emplacement de A.PHP? C’est-à-dire qu’il importe de savoir à quel fichier l’inclusion est appelée ou uniquement à partir de quoi le répertoire de travail actuel est- et qu'est-ce qui détermine le répertoire de travail actuel?
C'est relatif au script principal, dans ce cas A.php. Rappelez-vous que include()
insère simplement du code dans le script en cours d'exécution.
Autrement dit, le fichier dans lequel l'inclusion est appelée importe-t-il
Non.
Si vous voulez make ça compte, et faites une inclusion relative à B.php, utilisez le __FILE__
constante (ou __DIR__
depuis PHP 5.2 IIRC) qui indiquera toujours le fichier courant littéral dans lequel se trouve la ligne de code.
include(dirname(__FILE__)."/C.PHP");
@Pekka m'a amené là-bas, mais je veux juste partager ce que j'ai appris:
getcwd()
renvoie le répertoire dans lequel réside le fichier que vous avez commencé à exécuter.
dirname(__FILE__)
renvoie le répertoire du fichier contenant le code en cours d'exécution.
En utilisant ces deux fonctions, vous pouvez toujours créer un chemin d’inclusion relatif à ce dont vous avez besoin.
par exemple, si b.php et c.php partagent un répertoire, b.php peut inclure c.php comme ceci:
include(dirname(__FILE__).'/c.php');
peu importe d'où b.php a été appelé.
En fait, c'est le moyen préféré d'établir des chemins relatifs, car le code supplémentaire libère PHP) sans avoir à itérer via le chemin include_path lors de la tentative de localisation du fichier cible.
Sources:
Différence entre getcwd () et dirname (__ FILE__)? Lequel dois-je utiliser?
Pourquoi vous devriez utiliser dirname ( [~ # ~] fichier [~ # ~] )
Si le chemin d’inclusion ne commence pas par ./
Ou ../
, Par exemple:
include 'C.php'; // precedence: include_path (which include '.' at first),
// then path of current `.php` file (i.e. `B.php`), then `.`.
Si le chemin d’inclusion commence par ./
Ou ../
, Par exemple:
include './C.php'; // relative to '.'
include '../C.php'; // also relative to '.'
Le .
Ou ..
Ci-dessus est relatif à getcwd()
, le chemin par défaut du fichier d'entrée .php
(C'est-à-dire A.php
) .
Testé sur PHP 5.4.3 (Date de construction: le 8 mai 2012 00:47:34).
(Notez également que chdir()
peut modifier la sortie de getcwd()
.)
La réponse acceptée par Pekka est incomplète et, dans un contexte général, trompeuse. Si le fichier est fourni sous forme de chemin relatif, la construction de langage appelée include
le recherchera de la manière suivante.
Tout d'abord, il passera par les chemins de la variable d'environnement include_path
, Qui peut être définie avec ini_set
. Si cela échoue, il recherchera dans le répertoire propre du script appelant dirname(__FILE__)
(__DIR__
Avec php> = 5.3.) Si cela échoue également, alors il cherchera dans le répertoire de travail! Il s’avère que par défaut, la variable d’environnement include_path
Commence par .
, Qui est le répertoire de travail actuel. C'est la seule raison pour laquelle il recherche d'abord dans le répertoire de travail actuel. Voir http://php.net/manual/en/function.include.php .
Les fichiers sont inclus en fonction du chemin de fichier indiqué ou, si aucun n’est spécifié, du chemin d’inclusion spécifié. Si le fichier ne se trouve pas dans le chemin include_path, include archivera enfin le répertoire du script appelant et le répertoire de travail en cours avant d'échouer.
La réponse correcte à la première partie de la question est donc que l’emplacement du script d’appel inclus importe peu. La réponse à la dernière partie de la question est que le répertoire de travail initial , dans un contexte de serveur Web, est le répertoire du script appelé, le script cela inclut tous les autres en cours de traitement par PHP. Dans un contexte de ligne de commande, le répertoire de travail initial est celui que php soit appelé à l'invite, pas nécessairement le répertoire dans lequel se trouve le script appelé. Le répertoire de travail actuel peut cependant être modifié à l'exécution avec la fonction PHP function chdir
Voir http://php.net/manual/en/function.chdir.php .
Ce paragraphe est ajouté pour commenter d'autres réponses. Certains ont mentionné que compter sur include_path
Est moins robuste et qu'il est donc préférable d'utiliser des chemins complets tels que ./path
Ou __DIR__ . /path
. Certains sont allés jusqu'à dire que s'appuyer sur le répertoire de travail .
N'est pas sûr, car il peut être modifié. Toutefois, il est parfois nécessaire de s’appuyer sur des valeurs d’environnement. Par exemple, vous pouvez vouloir définir include_path
Vide, de sorte que le répertoire du script appelant soit le premier endroit où la recherche sera effectuée, même avant le répertoire de travail en cours. Le code est peut-être déjà écrit et mis à jour régulièrement à partir de sources externes et vous ne souhaitez pas réinsérer le préfixe __DIR__
Chaque fois que le code est mis à jour.
Réponse courte: c'est relatif au script incluant.
TFM l'explique correctement:
Si le fichier ne se trouve pas dans le chemin include_path, include archivera le répertoire du script appelant et le répertoire de travail en cours.
Donc, si /app/main.php dit include("./inc.php")
qui trouvera /app/inc.php.
Le . / n'est pas strictement nécessaire, mais supprime toute dépendance à include_path.
Je ne m'appuierais pas sur la recherche de fichiers include dans le répertoire de travail actuel au cas où quelqu'un le modifierait avec chdir()
.