Ma machine de dev (debian testing) est en php 5.2.0 depuis fin décembre
et jusqu'à pas si longtemps (a priori fin mars), le code suivant
(l'exemple est simplifié à dessein, bien sûr) :
$path = "/home/pillot/public_html/realpath.php/../../";
echo "<p>path = $path</p>";
echo "<p>rpath = " . realpath($path) . "</p>";
donnait le résultat suivant :
path = /home/toto/public_html/realpath.php/../../
rpath = /home/toto
On peut discuter du bien-fondé de la chose (l'écriture
"...fichier/../.."), mais ça marchait : j'en suis sûr, c'est dans des
routines couvertes par des tests unitaires qui ont tourné tous les jours
de décembre à mars ;-)
[...] si je tape :
% ls /home/pillot/public_html/realpath.php/../../
j'ai une erreur "Not a directory"
J'allais abandonné en pensant que le jeu ne valait pas la chandelle mais
j'ai eu qd même l'envie de voir ce que celà donnait sur un serveur de
prod encore en sarge et en php 4.3.10 :
eh bien le 'ls' donne toujours "Not a directory",
mais ce coup-ci
realpath ne renacle plus et renvoie bien "/home/toto".
Ma machine de dev (debian testing) est en php 5.2.0 depuis fin décembre
et jusqu'à pas si longtemps (a priori fin mars), le code suivant
(l'exemple est simplifié à dessein, bien sûr) :
$path = "/home/pillot/public_html/realpath.php/../../";
echo "<p>path = $path</p>";
echo "<p>rpath = " . realpath($path) . "</p>";
donnait le résultat suivant :
path = /home/toto/public_html/realpath.php/../../
rpath = /home/toto
On peut discuter du bien-fondé de la chose (l'écriture
"...fichier/../.."), mais ça marchait : j'en suis sûr, c'est dans des
routines couvertes par des tests unitaires qui ont tourné tous les jours
de décembre à mars ;-)
[...] si je tape :
% ls /home/pillot/public_html/realpath.php/../../
j'ai une erreur "Not a directory"
J'allais abandonné en pensant que le jeu ne valait pas la chandelle mais
j'ai eu qd même l'envie de voir ce que celà donnait sur un serveur de
prod encore en sarge et en php 4.3.10 :
eh bien le 'ls' donne toujours "Not a directory",
mais ce coup-ci
realpath ne renacle plus et renvoie bien "/home/toto".
Ma machine de dev (debian testing) est en php 5.2.0 depuis fin décembre
et jusqu'à pas si longtemps (a priori fin mars), le code suivant
(l'exemple est simplifié à dessein, bien sûr) :
$path = "/home/pillot/public_html/realpath.php/../../";
echo "<p>path = $path</p>";
echo "<p>rpath = " . realpath($path) . "</p>";
donnait le résultat suivant :
path = /home/toto/public_html/realpath.php/../../
rpath = /home/toto
On peut discuter du bien-fondé de la chose (l'écriture
"...fichier/../.."), mais ça marchait : j'en suis sûr, c'est dans des
routines couvertes par des tests unitaires qui ont tourné tous les jours
de décembre à mars ;-)
[...] si je tape :
% ls /home/pillot/public_html/realpath.php/../../
j'ai une erreur "Not a directory"
J'allais abandonné en pensant que le jeu ne valait pas la chandelle mais
j'ai eu qd même l'envie de voir ce que celà donnait sur un serveur de
prod encore en sarge et en php 4.3.10 :
eh bien le 'ls' donne toujours "Not a directory",
mais ce coup-ci
realpath ne renacle plus et renvoie bien "/home/toto".
Je suppose que realpath.php est un fichier de type « regular » et pas un
répertoire, n'est-ce pas ?
Je ne vois pas bien comment « pillot » peut se transformer en « toto »,
mais aussi je ne vois pas comment il pourrait exister un fichier de type
directory et de nom .. sous un fichier regular.
Ah, donc tu avais un comportement voulu basé sur un bug... et je suppose
que tu voudrais rester bug-compatible.
Normal. Qui plus est, même si realpath.php était de type directory,
encore faudrait-il vérifier les droits d'exécution pour savoir si on a
le droit d'aller chercher « .. ». Se contenter de supprimer un bout du
« path » sous prétexte qu'on reconnaît la chaîne « .. » est un vrai bug
à mon avis.
C'est donc l'implémentation de la fonction realpath qui est buguée. Si
cela t'amuse tu peux en écrire une du même genre à base de recherches
sur les chaînes, mais ce ne sera pas un vrai realpath.
Je suppose que realpath.php est un fichier de type « regular » et pas un
répertoire, n'est-ce pas ?
Je ne vois pas bien comment « pillot » peut se transformer en « toto »,
mais aussi je ne vois pas comment il pourrait exister un fichier de type
directory et de nom .. sous un fichier regular.
Ah, donc tu avais un comportement voulu basé sur un bug... et je suppose
que tu voudrais rester bug-compatible.
Normal. Qui plus est, même si realpath.php était de type directory,
encore faudrait-il vérifier les droits d'exécution pour savoir si on a
le droit d'aller chercher « .. ». Se contenter de supprimer un bout du
« path » sous prétexte qu'on reconnaît la chaîne « .. » est un vrai bug
à mon avis.
C'est donc l'implémentation de la fonction realpath qui est buguée. Si
cela t'amuse tu peux en écrire une du même genre à base de recherches
sur les chaînes, mais ce ne sera pas un vrai realpath.
Je suppose que realpath.php est un fichier de type « regular » et pas un
répertoire, n'est-ce pas ?
Je ne vois pas bien comment « pillot » peut se transformer en « toto »,
mais aussi je ne vois pas comment il pourrait exister un fichier de type
directory et de nom .. sous un fichier regular.
Ah, donc tu avais un comportement voulu basé sur un bug... et je suppose
que tu voudrais rester bug-compatible.
Normal. Qui plus est, même si realpath.php était de type directory,
encore faudrait-il vérifier les droits d'exécution pour savoir si on a
le droit d'aller chercher « .. ». Se contenter de supprimer un bout du
« path » sous prétexte qu'on reconnaît la chaîne « .. » est un vrai bug
à mon avis.
C'est donc l'implémentation de la fonction realpath qui est buguée. Si
cela t'amuse tu peux en écrire une du même genre à base de recherches
sur les chaînes, mais ce ne sera pas un vrai realpath.
mais aussi je ne vois pas comment il pourrait exister un fichier de type
directory et de nom .. sous un fichier regular.
<off-topic mode=slightly">
Ça, ça se discute. Je ne sais pas (honte à moi) ce que dit la norme
(POSIX je suppose ?) et il est possible (et j'accepte comme tel) qu'elle
indique /arbitrairement/ que l'expression '/..' ne puisse être suffixée
qu'à un path de directory, pas à celui d'un fichier, mais il ne me
semble pas délirant de considérer que puisque le token '..' indique le
répertoire père du path auquel il est suffixé (après un token
séparateur) il puisse donc être suffixé à n'importe quel path, celui
d'un fichier comme celui d'un directory. Non ? D'ailleurs (et ça
répondra peut-être à ma question), où sont précisées la syntaxe et la
sémantique des expressions de path ?
</off-topic>
mais aussi je ne vois pas comment il pourrait exister un fichier de type
directory et de nom .. sous un fichier regular.
<off-topic mode=slightly">
Ça, ça se discute. Je ne sais pas (honte à moi) ce que dit la norme
(POSIX je suppose ?) et il est possible (et j'accepte comme tel) qu'elle
indique /arbitrairement/ que l'expression '/..' ne puisse être suffixée
qu'à un path de directory, pas à celui d'un fichier, mais il ne me
semble pas délirant de considérer que puisque le token '..' indique le
répertoire père du path auquel il est suffixé (après un token
séparateur) il puisse donc être suffixé à n'importe quel path, celui
d'un fichier comme celui d'un directory. Non ? D'ailleurs (et ça
répondra peut-être à ma question), où sont précisées la syntaxe et la
sémantique des expressions de path ?
</off-topic>
mais aussi je ne vois pas comment il pourrait exister un fichier de type
directory et de nom .. sous un fichier regular.
<off-topic mode=slightly">
Ça, ça se discute. Je ne sais pas (honte à moi) ce que dit la norme
(POSIX je suppose ?) et il est possible (et j'accepte comme tel) qu'elle
indique /arbitrairement/ que l'expression '/..' ne puisse être suffixée
qu'à un path de directory, pas à celui d'un fichier, mais il ne me
semble pas délirant de considérer que puisque le token '..' indique le
répertoire père du path auquel il est suffixé (après un token
séparateur) il puisse donc être suffixé à n'importe quel path, celui
d'un fichier comme celui d'un directory. Non ? D'ailleurs (et ça
répondra peut-être à ma question), où sont précisées la syntaxe et la
sémantique des expressions de path ?
</off-topic>
Bon, prenons l'exemple d'un fichier de type lien symbolique.
Bon, prenons l'exemple d'un fichier de type lien symbolique.
Bon, prenons l'exemple d'un fichier de type lien symbolique.
Bon, prenons l'exemple d'un fichier de type lien symbolique.
Ben et alors ? Il ne t'échappe pas, je pense, que les exemples que tu
décrit, fonctionnent déjà, je veux dire qu'ils ne provoquent pas
d'erreurs !
[...]
(1) il n'existe pas de "fichier de type lien symbolique" ni de
"répertoire de type lien symbolique" d'ailleurs, seulement des liens
symboliques.
Bon, prenons l'exemple d'un fichier de type lien symbolique.
Ben et alors ? Il ne t'échappe pas, je pense, que les exemples que tu
décrit, fonctionnent déjà, je veux dire qu'ils ne provoquent pas
d'erreurs !
[...]
(1) il n'existe pas de "fichier de type lien symbolique" ni de
"répertoire de type lien symbolique" d'ailleurs, seulement des liens
symboliques.
Bon, prenons l'exemple d'un fichier de type lien symbolique.
Ben et alors ? Il ne t'échappe pas, je pense, que les exemples que tu
décrit, fonctionnent déjà, je veux dire qu'ils ne provoquent pas
d'erreurs !
[...]
(1) il n'existe pas de "fichier de type lien symbolique" ni de
"répertoire de type lien symbolique" d'ailleurs, seulement des liens
symboliques.