comment determiner si l'on est sous environnement windows ?
17 réponses
heulman
Bonjour,
Comment déterminer à coup sûr en php si l'on est sous environnement windows
?
Je pense utiliser la constante PHP_OS mais je m'interroge sur sa fiabilité.
Windows XP me retourne WINNT.
Est-ce toutes les versions de windows retournent une valeur commençant par
WIN ?
Peut-être existe-t-il une routine standard qui serait plus fiable ?
Le 01 Dec 2006 15:07:35 GMT, Michael DENIS écrivait dans fr.comp.lang.php:
if windows $chemin="C:mon_cheminwwwimagestest.jpg" else //linux $chemin="/home/www/images/test.jpg }
on met
//définition des variables globales if windows $racine="C:mon_cheminwww" $separ="" else $racine="/home/www/" $separ="/"
Techniquement, dans Windows, / et sont équivalents dans le nom d'un fichier. Donc, vous n'avez pas besoin de vous casser la tête pour ce qui est des adresses **relatives**. Évidemment, pour les adresses absolues et la casse, c'est autre chose. Il n'y a donc pas lieu de créer la variable $separ.
Par ailleurs, j'indiquerais le chemin par rapport au nom du domaine si c'est pour un site en ligne (mais le chemin réel si c'est pour un script utilisé hors-ligne).
Vous pouvez donc développer sur Windows avec par exemple:
base/mapage.php avec un lien vers ../images/image.jpg et cela fonctionnera sous Windows.
Il faut préciser que le / ou ne cause problème qu'en DOS. Il y a plusieurs versions (DOS 3 ?), on pouvait changer le SWITCH (quelque chose comme SET SWITCH="-"), sinon l'analyseur de commandes suppose que le / est le commutateur des options.
dir /s xyz*.toto devenant dir -s xyz/*.toto
Mais ce n'est vrai qu'avec la ligne de commande. Les navigateurs doivent faire la conversion si ce n'est pas Windows qui la fait.
Denis
Le 01 Dec 2006 15:07:35 GMT, Michael DENIS <news-mDEL@DEL2nis.net>
écrivait dans fr.comp.lang.php:
if windows
$chemin="C:mon_cheminwwwimagestest.jpg"
else //linux
$chemin="/home/www/images/test.jpg
}
on met
//définition des variables globales
if windows
$racine="C:mon_cheminwww"
$separ=""
else
$racine="/home/www/"
$separ="/"
Techniquement, dans Windows, / et sont équivalents dans le nom
d'un fichier. Donc, vous n'avez pas besoin de vous casser la tête
pour ce qui est des adresses **relatives**. Évidemment, pour les
adresses absolues et la casse, c'est autre chose. Il n'y a donc
pas lieu de créer la variable $separ.
Par ailleurs, j'indiquerais le chemin par rapport au nom du domaine
si c'est pour un site en ligne (mais le chemin réel si c'est pour
un script utilisé hors-ligne).
Vous pouvez donc développer sur Windows avec par exemple:
base/mapage.php avec un lien vers ../images/image.jpg
et cela fonctionnera sous Windows.
Il faut préciser que le / ou ne cause problème qu'en DOS.
Il y a plusieurs versions (DOS 3 ?), on pouvait changer le
SWITCH (quelque chose comme SET SWITCH="-"), sinon l'analyseur
de commandes suppose que le / est le commutateur des options.
dir /s xyz*.toto devenant dir -s xyz/*.toto
Mais ce n'est vrai qu'avec la ligne de commande. Les navigateurs
doivent faire la conversion si ce n'est pas Windows qui la fait.
Le 01 Dec 2006 15:07:35 GMT, Michael DENIS écrivait dans fr.comp.lang.php:
if windows $chemin="C:mon_cheminwwwimagestest.jpg" else //linux $chemin="/home/www/images/test.jpg }
on met
//définition des variables globales if windows $racine="C:mon_cheminwww" $separ="" else $racine="/home/www/" $separ="/"
Techniquement, dans Windows, / et sont équivalents dans le nom d'un fichier. Donc, vous n'avez pas besoin de vous casser la tête pour ce qui est des adresses **relatives**. Évidemment, pour les adresses absolues et la casse, c'est autre chose. Il n'y a donc pas lieu de créer la variable $separ.
Par ailleurs, j'indiquerais le chemin par rapport au nom du domaine si c'est pour un site en ligne (mais le chemin réel si c'est pour un script utilisé hors-ligne).
Vous pouvez donc développer sur Windows avec par exemple:
base/mapage.php avec un lien vers ../images/image.jpg et cela fonctionnera sous Windows.
Il faut préciser que le / ou ne cause problème qu'en DOS. Il y a plusieurs versions (DOS 3 ?), on pouvait changer le SWITCH (quelque chose comme SET SWITCH="-"), sinon l'analyseur de commandes suppose que le / est le commutateur des options.
dir /s xyz*.toto devenant dir -s xyz/*.toto
Mais ce n'est vrai qu'avec la ligne de commande. Les navigateurs doivent faire la conversion si ce n'est pas Windows qui la fait.
Denis
John GALLET
Techniquement, dans Windows, / et sont équivalents dans le nom d'un fichier.
Accessoirement quand on a vraiment besoin de le faire, PHP définit la constante ad hoc (DIRECTORY_SEPARATOR je crois ? J'ai la flemme d'aller regarder dans le man). On n'a donc même pas à se poser la question.
Par ailleurs, j'indiquerais le chemin par rapport au nom du domaine si c'est pour un site en ligne (mais le chemin réel si c'est pour un script utilisé hors-ligne).
Dans tous les cas on s'en fiche, on doit toujours pouvoir donner la possibilité à l'utilisateur (au sens : celui qui installe l'application, ici) de mettre les choses là où il le veut, et donc on met un paramètre de config dans un fichier (de config!) et on en parle plus.
A part pour utiliser des fonctionnalités spécifiques à un OS comme printer sous windows ou les IPC sous unix, mais dont doit déjà déterminer la disponibilité car ces extensions ne sont pas nécessairement installées/compilées sur l'environnement local, ou si on veut jouer avec setlocale (ce qui à mon sens est triplement problématique, mais libre à chacun de faire ce qu'il veut), détecter la version de l'OS sur lequel tourne PHP ne sert à rien. Ou plus précisement : ne devrait servir à rien car on peut écrire du code totalement indépendant pour pas tellement plus cher, ni en dev initial, ni en maintenance.
JG
Techniquement, dans Windows, / et sont équivalents dans le nom
d'un fichier.
Accessoirement quand on a vraiment besoin de le faire, PHP définit la
constante ad hoc (DIRECTORY_SEPARATOR je crois ? J'ai la flemme d'aller
regarder dans le man). On n'a donc même pas à se poser la question.
Par ailleurs, j'indiquerais le chemin par rapport au nom du domaine
si c'est pour un site en ligne (mais le chemin réel si c'est pour
un script utilisé hors-ligne).
Dans tous les cas on s'en fiche, on doit toujours pouvoir donner la
possibilité à l'utilisateur (au sens : celui qui installe l'application,
ici) de mettre les choses là où il le veut, et donc on met un paramètre de
config dans un fichier (de config!) et on en parle plus.
A part pour utiliser des fonctionnalités spécifiques à un OS comme printer
sous windows ou les IPC sous unix, mais dont doit déjà déterminer la
disponibilité car ces extensions ne sont pas nécessairement
installées/compilées sur l'environnement local, ou si on veut jouer avec
setlocale (ce qui à mon sens est triplement problématique, mais libre à
chacun de faire ce qu'il veut), détecter la version de l'OS sur lequel
tourne PHP ne sert à rien. Ou plus précisement : ne devrait servir à rien
car on peut écrire du code totalement indépendant pour pas tellement plus
cher, ni en dev initial, ni en maintenance.
Techniquement, dans Windows, / et sont équivalents dans le nom d'un fichier.
Accessoirement quand on a vraiment besoin de le faire, PHP définit la constante ad hoc (DIRECTORY_SEPARATOR je crois ? J'ai la flemme d'aller regarder dans le man). On n'a donc même pas à se poser la question.
Par ailleurs, j'indiquerais le chemin par rapport au nom du domaine si c'est pour un site en ligne (mais le chemin réel si c'est pour un script utilisé hors-ligne).
Dans tous les cas on s'en fiche, on doit toujours pouvoir donner la possibilité à l'utilisateur (au sens : celui qui installe l'application, ici) de mettre les choses là où il le veut, et donc on met un paramètre de config dans un fichier (de config!) et on en parle plus.
A part pour utiliser des fonctionnalités spécifiques à un OS comme printer sous windows ou les IPC sous unix, mais dont doit déjà déterminer la disponibilité car ces extensions ne sont pas nécessairement installées/compilées sur l'environnement local, ou si on veut jouer avec setlocale (ce qui à mon sens est triplement problématique, mais libre à chacun de faire ce qu'il veut), détecter la version de l'OS sur lequel tourne PHP ne sert à rien. Ou plus précisement : ne devrait servir à rien car on peut écrire du code totalement indépendant pour pas tellement plus cher, ni en dev initial, ni en maintenance.
JG
John GALLET
J'ai eu le cas sur un site que j'ai du reprendre en vitesse (pas le temps de refaire tout le système) et déterminer l'OS me fut bien utile.
On est toujours/souvent obligé de faire n'importe quoi, au moins temporairement, quand on récupère des trucs écrits avec les pieds, c'est pas un scoop. Ca ne veut pas dire que c'est incontournable, et encore moins à élever au pinnacle comme méthode standard de développement (d'aucuns diraient comme "best practice" pour faire à la mode).
JG
J'ai eu le cas sur un site que j'ai du reprendre en vitesse (pas le
temps de refaire tout le système) et déterminer l'OS me fut bien utile.
On est toujours/souvent obligé de faire n'importe quoi, au moins
temporairement, quand on récupère des trucs écrits avec les pieds, c'est
pas un scoop. Ca ne veut pas dire que c'est incontournable, et encore
moins à élever au pinnacle comme méthode standard de développement
(d'aucuns diraient comme "best practice" pour faire à la mode).
J'ai eu le cas sur un site que j'ai du reprendre en vitesse (pas le temps de refaire tout le système) et déterminer l'OS me fut bien utile.
On est toujours/souvent obligé de faire n'importe quoi, au moins temporairement, quand on récupère des trucs écrits avec les pieds, c'est pas un scoop. Ca ne veut pas dire que c'est incontournable, et encore moins à élever au pinnacle comme méthode standard de développement (d'aucuns diraient comme "best practice" pour faire à la mode).
JG
heulman
"Michael DENIS" a écrit dans le message de news:
Le 29 Nov 2006 10:55:34 GMT, CrazyCat écrivait:
Je suis d'accord mais il y a toujours des exceptions, ne serait-ce que lorsqu'on doit traiter des fichiers en utilisant les chemins physiques.
Non. Cet exemple en tous les cas rentre parfaitement dans le cas expliqué par John. Au lieu de mettre quelquechose comme:
on met
//définition des variables globales if windows $racine="C:mon_cheminwww" $separ="" else $racine="/home/www/" $separ="/" }
Et donc là le "if windows ... else ...." on le détermine comment ?
heulman
"Michael DENIS" <news-mDEL@DEL2nis.net> a écrit dans le message de news:
oa90n2l522su318iurifnmlppqms2sbnni@4ax.com...
Le 29 Nov 2006 10:55:34 GMT, CrazyCat <crazycat@nospam.c-p-f.org>
écrivait:
Je suis d'accord mais il y a toujours des exceptions, ne serait-ce que
lorsqu'on doit traiter des fichiers en utilisant les chemins physiques.
Non. Cet exemple en tous les cas rentre parfaitement dans le cas
expliqué par John. Au lieu de mettre quelquechose comme:
on met
//définition des variables globales
if windows
$racine="C:mon_cheminwww"
$separ=""
else
$racine="/home/www/"
$separ="/"
}
Et donc là le "if windows ... else ...." on le détermine comment ?
Je suis d'accord mais il y a toujours des exceptions, ne serait-ce que lorsqu'on doit traiter des fichiers en utilisant les chemins physiques.
Non. Cet exemple en tous les cas rentre parfaitement dans le cas expliqué par John. Au lieu de mettre quelquechose comme:
on met
//définition des variables globales if windows $racine="C:mon_cheminwww" $separ="" else $racine="/home/www/" $separ="/" }
Et donc là le "if windows ... else ...." on le détermine comment ?
heulman
John GALLET
Et donc là le "if windows ... else ...." on le détermine comment ?
On ne le détermine pas, c'est l'admin qui installe le biniou qui le gère, ou plus précisement qui peut la surcharger si ce qu'on a mis par défaut ne lui convient pas.
En prenant ici le cas des chemins :
Pour le choix de la valeur par défaut, ou on met une valeur relative (ce qui est plus portable même sur un même OS, sinon on a du mal à faire tourner plusieurs versions de la même application sur la même machine) ou on met une valeur absole si justement on veut partager les données (fichiers de config par exemple) et dans ce cas on commence par regarder ce que PHP nous propose ou en lisant le manuel, ou en tentant sa chance avec un script d'une ligne:
<?php print_r(get_defined_constants());?> On trouve par exemple : [DIRECTORY_SEPARATOR] => / [PATH_SEPARATOR] => : si on voulait jouer avec les chemins, ou par exemple : [PHP_CONFIG_FILE_PATH] => /usr/local/php/lib
Si on ne trouve rien qui nous arrange et qu'on a *vraiment* (encore une fois, j'insiste, ce besoin n'est PAS si courant que ça) de définir explicitement un répertoire absolu du genre C:machinbidule (qui s'écrit aussi C:/machin/bidule d'ailleurs) ou /usr/local/mon_app/ ) alors on met dans le fichier de configuration :
// Choose your platform and installation path. Examples : // cfg['mon_chemin_absolu']='/choose/absolute/path/'; // cfg['mon_chemin_absolu']='C:chooseabsolutepath';
cfg['mon_chemin_absolu']='/usr/local/mon_app/';
Et si besoin est, on livre des scripts d'installation, un .bat et un .sh, qui se chargent de recopier le bon fichier, ou comme pour spip par exemple, un script PHP qui fait saisir quelques valeur par un formulaire et gère l'instalation. Les solutions ne manquent pas si on veut faire une installation simplifiée/neuneu compliant.
a++; JG
Et donc là le "if windows ... else ...." on le détermine comment ?
On ne le détermine pas, c'est l'admin qui installe le biniou qui le gère,
ou plus précisement qui peut la surcharger si ce qu'on a mis par défaut ne
lui convient pas.
En prenant ici le cas des chemins :
Pour le choix de la valeur par défaut, ou on met une valeur relative (ce
qui est plus portable même sur un même OS, sinon on a du mal à faire
tourner plusieurs versions de la même application sur la même machine) ou
on met une valeur absole si justement on veut partager les données
(fichiers de config par exemple) et dans ce cas on commence par regarder
ce que PHP nous propose ou en lisant le manuel, ou en tentant sa chance
avec un script d'une ligne:
<?php print_r(get_defined_constants());?>
On trouve par exemple :
[DIRECTORY_SEPARATOR] => /
[PATH_SEPARATOR] => :
si on voulait jouer avec les chemins, ou par exemple :
[PHP_CONFIG_FILE_PATH] => /usr/local/php/lib
Si on ne trouve rien qui nous arrange et qu'on a *vraiment* (encore une
fois, j'insiste, ce besoin n'est PAS si courant que ça) de définir
explicitement un répertoire absolu du genre C:machinbidule (qui s'écrit
aussi C:/machin/bidule d'ailleurs) ou /usr/local/mon_app/ ) alors on met
dans le fichier de configuration :
// Choose your platform and installation path. Examples :
// cfg['mon_chemin_absolu']='/choose/absolute/path/';
// cfg['mon_chemin_absolu']='C:chooseabsolutepath';
cfg['mon_chemin_absolu']='/usr/local/mon_app/';
Et si besoin est, on livre des scripts d'installation, un .bat et un .sh,
qui se chargent de recopier le bon fichier, ou comme pour spip par
exemple, un script PHP qui fait saisir quelques valeur par un formulaire
et gère l'instalation. Les solutions ne manquent pas si on veut faire une
installation simplifiée/neuneu compliant.
Et donc là le "if windows ... else ...." on le détermine comment ?
On ne le détermine pas, c'est l'admin qui installe le biniou qui le gère, ou plus précisement qui peut la surcharger si ce qu'on a mis par défaut ne lui convient pas.
En prenant ici le cas des chemins :
Pour le choix de la valeur par défaut, ou on met une valeur relative (ce qui est plus portable même sur un même OS, sinon on a du mal à faire tourner plusieurs versions de la même application sur la même machine) ou on met une valeur absole si justement on veut partager les données (fichiers de config par exemple) et dans ce cas on commence par regarder ce que PHP nous propose ou en lisant le manuel, ou en tentant sa chance avec un script d'une ligne:
<?php print_r(get_defined_constants());?> On trouve par exemple : [DIRECTORY_SEPARATOR] => / [PATH_SEPARATOR] => : si on voulait jouer avec les chemins, ou par exemple : [PHP_CONFIG_FILE_PATH] => /usr/local/php/lib
Si on ne trouve rien qui nous arrange et qu'on a *vraiment* (encore une fois, j'insiste, ce besoin n'est PAS si courant que ça) de définir explicitement un répertoire absolu du genre C:machinbidule (qui s'écrit aussi C:/machin/bidule d'ailleurs) ou /usr/local/mon_app/ ) alors on met dans le fichier de configuration :
// Choose your platform and installation path. Examples : // cfg['mon_chemin_absolu']='/choose/absolute/path/'; // cfg['mon_chemin_absolu']='C:chooseabsolutepath';
cfg['mon_chemin_absolu']='/usr/local/mon_app/';
Et si besoin est, on livre des scripts d'installation, un .bat et un .sh, qui se chargent de recopier le bon fichier, ou comme pour spip par exemple, un script PHP qui fait saisir quelques valeur par un formulaire et gère l'instalation. Les solutions ne manquent pas si on veut faire une installation simplifiée/neuneu compliant.
a++; JG
Michael DENIS
Le 01 Dec 2006 17:16:08 GMT, Denis Beauregard écrivait:
Techniquement, dans Windows, / et sont équivalents dans le nom d'un fichier.
Exact. Et je ne suis même pas pardonnable car je teste sous Windows avant de mettre en ligne sous Linux sans jamais rien changer. J'aurais d'ailleurs peut-être dû parler de deux fonctions particulièrement utiles pour la gestion des chemins:
$_SERVER['DOCUMENT_ROOT'] qui renvoie la racine du site et qui permet des choses comme ça: include($_SERVER['DOCUMENT_ROOT'] . "/include/mon_fichier.php");
$_SERVER['HTTP_HOST'] qui renvoie le domaine du serveur (qui peut être 127.0.0.1) et qui permet des choses comme ça: echo "<img src="http://" . $_SERVER['HTTP_HOST'] . "/images/mon_image.jpg" alt="mon image">";
-- Michaël DENIS
Déco? <http://www.toiles-de-mayenne.com/>
Le 01 Dec 2006 17:16:08 GMT, Denis Beauregard
<denis.b-at-francogene.com.invalid@nospam.com.invalid> écrivait:
Techniquement, dans Windows, / et sont équivalents dans le nom
d'un fichier.
Exact. Et je ne suis même pas pardonnable car je teste sous Windows
avant de mettre en ligne sous Linux sans jamais rien changer. J'aurais
d'ailleurs peut-être dû parler de deux fonctions particulièrement
utiles pour la gestion des chemins:
$_SERVER['DOCUMENT_ROOT'] qui renvoie la racine du site et qui permet
des choses comme ça:
include($_SERVER['DOCUMENT_ROOT'] . "/include/mon_fichier.php");
$_SERVER['HTTP_HOST'] qui renvoie le domaine du serveur (qui peut être
127.0.0.1) et qui permet des choses comme ça:
echo "<img src="http://" . $_SERVER['HTTP_HOST'] .
"/images/mon_image.jpg" alt="mon image">";
Le 01 Dec 2006 17:16:08 GMT, Denis Beauregard écrivait:
Techniquement, dans Windows, / et sont équivalents dans le nom d'un fichier.
Exact. Et je ne suis même pas pardonnable car je teste sous Windows avant de mettre en ligne sous Linux sans jamais rien changer. J'aurais d'ailleurs peut-être dû parler de deux fonctions particulièrement utiles pour la gestion des chemins:
$_SERVER['DOCUMENT_ROOT'] qui renvoie la racine du site et qui permet des choses comme ça: include($_SERVER['DOCUMENT_ROOT'] . "/include/mon_fichier.php");
$_SERVER['HTTP_HOST'] qui renvoie le domaine du serveur (qui peut être 127.0.0.1) et qui permet des choses comme ça: echo "<img src="http://" . $_SERVER['HTTP_HOST'] . "/images/mon_image.jpg" alt="mon image">";
-- Michaël DENIS
Déco? <http://www.toiles-de-mayenne.com/>
John GALLET
Bonjour,
d'ailleurs peut-être dû parler de deux fonctions particulièrement utiles pour la gestion des chemins: $_SERVER['DOCUMENT_ROOT'] qui renvoie la racine du site et qui permet des choses comme ça: include($_SERVER['DOCUMENT_ROOT'] . "/include/mon_fichier.php"); $_SERVER['HTTP_HOST'] qui renvoie le domaine du serveur (qui peut être 127.0.0.1) et qui permet des choses comme ça: echo "<img src="http://" . $_SERVER['HTTP_HOST'] . "/images/mon_image.jpg" alt="mon image">";
Se méfier quand même de toutes ces belles variables, qui fonctionnent comme elles peuvent dans certains cas (c'est à dire mal).
Là dedans sont complètement faux ou inexploitables :
- le document root, étant donné qu'il donne celui du domaine et ne prends pas en compte le user. Il est juste, mais on ne peut rien en faire.
- PATH_INFO : complètement à l'ouest.
- PATH_TRANSLATED : encore pire, il ne prend ni le bon user, ni le bon script. Fête du slip totale.
- PHP_SELF : partiellement correct, mais bonjour le bazar.
Donc attention aux variables de $_SERVER, outre le fait qu'on peut leur faire manger pas mal de choses (des ' au hasard...) elles ne sont pas nécessairement fiables en contenu dans toutes les configurations.
a++; JG
Bonjour,
d'ailleurs peut-être dû parler de deux fonctions particulièrement
utiles pour la gestion des chemins:
$_SERVER['DOCUMENT_ROOT'] qui renvoie la racine du site et qui permet
des choses comme ça:
include($_SERVER['DOCUMENT_ROOT'] . "/include/mon_fichier.php");
$_SERVER['HTTP_HOST'] qui renvoie le domaine du serveur (qui peut être
127.0.0.1) et qui permet des choses comme ça:
echo "<img src="http://" . $_SERVER['HTTP_HOST'] .
"/images/mon_image.jpg" alt="mon image">";
Se méfier quand même de toutes ces belles variables, qui fonctionnent
comme elles peuvent dans certains cas (c'est à dire mal).
Là dedans sont complètement faux ou inexploitables :
- le document root, étant donné qu'il donne celui du domaine et ne prends
pas en compte le user. Il est juste, mais on ne peut rien en faire.
- PATH_INFO : complètement à l'ouest.
- PATH_TRANSLATED : encore pire, il ne prend ni le bon user, ni le bon
script. Fête du slip totale.
- PHP_SELF : partiellement correct, mais bonjour le bazar.
Donc attention aux variables de $_SERVER, outre le fait qu'on peut leur
faire manger pas mal de choses (des ' au hasard...) elles ne sont pas
nécessairement fiables en contenu dans toutes les configurations.
d'ailleurs peut-être dû parler de deux fonctions particulièrement utiles pour la gestion des chemins: $_SERVER['DOCUMENT_ROOT'] qui renvoie la racine du site et qui permet des choses comme ça: include($_SERVER['DOCUMENT_ROOT'] . "/include/mon_fichier.php"); $_SERVER['HTTP_HOST'] qui renvoie le domaine du serveur (qui peut être 127.0.0.1) et qui permet des choses comme ça: echo "<img src="http://" . $_SERVER['HTTP_HOST'] . "/images/mon_image.jpg" alt="mon image">";
Se méfier quand même de toutes ces belles variables, qui fonctionnent comme elles peuvent dans certains cas (c'est à dire mal).
Là dedans sont complètement faux ou inexploitables :
- le document root, étant donné qu'il donne celui du domaine et ne prends pas en compte le user. Il est juste, mais on ne peut rien en faire.
- PATH_INFO : complètement à l'ouest.
- PATH_TRANSLATED : encore pire, il ne prend ni le bon user, ni le bon script. Fête du slip totale.
- PHP_SELF : partiellement correct, mais bonjour le bazar.
Donc attention aux variables de $_SERVER, outre le fait qu'on peut leur faire manger pas mal de choses (des ' au hasard...) elles ne sont pas nécessairement fiables en contenu dans toutes les configurations.
