J'ai un morceau de script qui passe bien sur x86 mais pas sur une station
HP (hppa/risc).
Sur mon portable x86 avec Ubuntu, le morceau de php:
echo "<pre>";
passthru("top -bn1 -d1 | head -n 15");
echo "</pre>";
affiche bien les 15 premières lignes de la commande top.
Mais pas sur la station hp sur laquelle la commande "top" est pourtant
installée. (elle marche bien en console).
Qu'aie-je oublié ?
--
> > Allez vous faire enculer avec votre pinceau.
> Clair et concis.
Pas si on se place du point de vue du pinceau.
Hugo (né il y a 1 340 305 813 secondes)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Olivier Miakinen
Sur mon portable x86 avec Ubuntu, le morceau de php: echo "<pre>"; passthru("top -bn1 -d1 | head -n 15"); echo "</pre>"; affiche bien les 15 premières lignes de la commande top.
Mais pas sur la station hp sur laquelle la commande "top" est pourtant installée. (elle marche bien en console).
Qu'aie-je oublié ?
1) Est-ce que la commande head existe bien (en principe oui, mais on ne sait jamais) ?
2) Sont-elles dans le PATH connu par PHP ?
3) Et si tu mettais le chemin complet (/usr/bin/head au lieu de head par exemple) ?
Sur mon portable x86 avec Ubuntu, le morceau de php:
echo "<pre>";
passthru("top -bn1 -d1 | head -n 15");
echo "</pre>";
affiche bien les 15 premières lignes de la commande top.
Mais pas sur la station hp sur laquelle la commande "top" est pourtant
installée. (elle marche bien en console).
Qu'aie-je oublié ?
1) Est-ce que la commande head existe bien (en principe oui, mais on ne
sait jamais) ?
2) Sont-elles dans le PATH connu par PHP ?
3) Et si tu mettais le chemin complet (/usr/bin/head au lieu de head par
exemple) ?
Sur mon portable x86 avec Ubuntu, le morceau de php: echo "<pre>"; passthru("top -bn1 -d1 | head -n 15"); echo "</pre>"; affiche bien les 15 premières lignes de la commande top.
Mais pas sur la station hp sur laquelle la commande "top" est pourtant installée. (elle marche bien en console).
Qu'aie-je oublié ?
1) Est-ce que la commande head existe bien (en principe oui, mais on ne sait jamais) ?
2) Sont-elles dans le PATH connu par PHP ?
3) Et si tu mettais le chemin complet (/usr/bin/head au lieu de head par exemple) ?
Hugolino
Le 15 Oct 2006 16:36:27 GMT, Olivier Miakinen a écrit:
Sur mon portable x86 avec Ubuntu, le morceau de php: echo "<pre>"; passthru("top -bn1 -d1 | head -n 15"); echo "</pre>"; affiche bien les 15 premières lignes de la commande top.
Mais pas sur la station hp sur laquelle la commande "top" est pourtant installée. (elle marche bien en console).
Qu'aie-je oublié ?
1) Est-ce que la commande head existe bien (en principe oui, mais on ne sait jamais) ?
Oui, et pour éviter tout problème avec le pipe, j'ai réécrit la ligne comme suit: passthru("/usr/bin/top -bn1", $return_var); echo $return_var
2) Sont-elles dans le PATH connu par PHP ?
Dans quel fichier le PATH se configure-t-il ? Le fichier /etc/php4/apache2/php.ini ne contient pas de référence à /usr/bin, pourtant la fonction phpinfo() affiche plusieurs occurences de "/usr/local/bin:/usr/bin:/bin" * dans la section "Apache Environment" pour la variable "PATH" * dans la section "Environment" pour la variable "PATH" * dans la section "PHP Variables", pour les variables _SERVER["PATH"] et _ENV["PATH"]
3) Et si tu mettais le chemin complet (/usr/bin/head au lieu de head par exemple) ?
J'ai mis le chemin complet pour la commande top comme indiqué ci-dessus, mais la variable $return_var contient "1". Pourtant un passthru("ls -l"); affiche bien le contenu du répertoire. J'ai essayé aussi: exec("/usr/bin/top >stdout.txt 2>stderr.txt", $result_var); Mais les fichiers ne sont pas créés et $result_var contient "Array".
Un contributeur (Thierry B.) avait ouvert un fil "Apache et windows->recuperer sortie com mande exec()" le 15 10 2005 et il ne s'en était sorti qu'en installant php5 qui n'est malheureusement pas disponible en package debian pour l'architecture hppa.
--
...à la faible latence entre le premier contact et la phase "sous la couette" et son coté intéractif ? Le rythme auquel sont délivrés les ACK^wAAH pourrait indiquer la suprématie de la classe marteau-piqueur dans la QoS, mais les spécialistes objecteront sûrement que l'upload, suite aux nombreuses...
Le 15 Oct 2006 16:36:27 GMT, Olivier Miakinen a écrit:
Sur mon portable x86 avec Ubuntu, le morceau de php:
echo "<pre>";
passthru("top -bn1 -d1 | head -n 15");
echo "</pre>";
affiche bien les 15 premières lignes de la commande top.
Mais pas sur la station hp sur laquelle la commande "top" est pourtant
installée. (elle marche bien en console).
Qu'aie-je oublié ?
1) Est-ce que la commande head existe bien (en principe oui, mais on ne
sait jamais) ?
Oui, et pour éviter tout problème avec le pipe, j'ai réécrit la ligne
comme suit:
passthru("/usr/bin/top -bn1", $return_var);
echo $return_var
2) Sont-elles dans le PATH connu par PHP ?
Dans quel fichier le PATH se configure-t-il ?
Le fichier /etc/php4/apache2/php.ini ne contient pas de référence à
/usr/bin, pourtant la fonction phpinfo() affiche plusieurs occurences de
"/usr/local/bin:/usr/bin:/bin"
* dans la section "Apache Environment" pour la variable "PATH"
* dans la section "Environment" pour la variable "PATH"
* dans la section "PHP Variables", pour les variables _SERVER["PATH"] et
_ENV["PATH"]
3) Et si tu mettais le chemin complet (/usr/bin/head au lieu de head par
exemple) ?
J'ai mis le chemin complet pour la commande top comme indiqué ci-dessus,
mais la variable $return_var contient "1".
Pourtant un passthru("ls -l"); affiche bien le contenu du répertoire.
J'ai essayé aussi: exec("/usr/bin/top >stdout.txt 2>stderr.txt", $result_var);
Mais les fichiers ne sont pas créés et $result_var contient "Array".
Un contributeur (Thierry B.) avait ouvert un fil "Apache et
windows->recuperer sortie com mande exec()" le 15 10 2005 et il ne s'en
était sorti qu'en installant php5 qui n'est malheureusement pas
disponible en package debian pour l'architecture hppa.
--
...à la faible latence entre le premier contact et la phase "sous la couette"
et son coté intéractif ? Le rythme auquel sont délivrés les ACK^wAAH pourrait
indiquer la suprématie de la classe marteau-piqueur dans la QoS, mais les
spécialistes objecteront sûrement que l'upload, suite aux nombreuses...
Le 15 Oct 2006 16:36:27 GMT, Olivier Miakinen a écrit:
Sur mon portable x86 avec Ubuntu, le morceau de php: echo "<pre>"; passthru("top -bn1 -d1 | head -n 15"); echo "</pre>"; affiche bien les 15 premières lignes de la commande top.
Mais pas sur la station hp sur laquelle la commande "top" est pourtant installée. (elle marche bien en console).
Qu'aie-je oublié ?
1) Est-ce que la commande head existe bien (en principe oui, mais on ne sait jamais) ?
Oui, et pour éviter tout problème avec le pipe, j'ai réécrit la ligne comme suit: passthru("/usr/bin/top -bn1", $return_var); echo $return_var
2) Sont-elles dans le PATH connu par PHP ?
Dans quel fichier le PATH se configure-t-il ? Le fichier /etc/php4/apache2/php.ini ne contient pas de référence à /usr/bin, pourtant la fonction phpinfo() affiche plusieurs occurences de "/usr/local/bin:/usr/bin:/bin" * dans la section "Apache Environment" pour la variable "PATH" * dans la section "Environment" pour la variable "PATH" * dans la section "PHP Variables", pour les variables _SERVER["PATH"] et _ENV["PATH"]
3) Et si tu mettais le chemin complet (/usr/bin/head au lieu de head par exemple) ?
J'ai mis le chemin complet pour la commande top comme indiqué ci-dessus, mais la variable $return_var contient "1". Pourtant un passthru("ls -l"); affiche bien le contenu du répertoire. J'ai essayé aussi: exec("/usr/bin/top >stdout.txt 2>stderr.txt", $result_var); Mais les fichiers ne sont pas créés et $result_var contient "Array".
Un contributeur (Thierry B.) avait ouvert un fil "Apache et windows->recuperer sortie com mande exec()" le 15 10 2005 et il ne s'en était sorti qu'en installant php5 qui n'est malheureusement pas disponible en package debian pour l'architecture hppa.
--
...à la faible latence entre le premier contact et la phase "sous la couette" et son coté intéractif ? Le rythme auquel sont délivrés les ACK^wAAH pourrait indiquer la suprématie de la classe marteau-piqueur dans la QoS, mais les spécialistes objecteront sûrement que l'upload, suite aux nombreuses...
Olivier Miakinen
1) Est-ce que la commande head existe bien (en principe oui, mais on ne sait jamais) ?
Oui, et pour éviter tout problème avec le pipe, j'ai réécrit la ligne comme suit: passthru("/usr/bin/top -bn1", $return_var); echo $return_var
Est-ce que l'utilisateur qui lance PHP a bien le droit d'exécuter cette commande ?
2) Sont-elles dans le PATH connu par PHP ?
Dans quel fichier le PATH se configure-t-il ?
À priori, je pense que c'est le PATH par défaut au moment où le process Apache se lance. Peut-être dans /etc/profile ou un truc de ce genre, mais de toute façon il ne faut pas le modifier juste pour ça.
Le fichier /etc/php4/apache2/php.ini ne contient pas de référence à /usr/bin, pourtant la fonction phpinfo() affiche plusieurs occurences de "/usr/local/bin:/usr/bin:/bin" * dans la section "Apache Environment" pour la variable "PATH" * dans la section "Environment" pour la variable "PATH" * dans la section "PHP Variables", pour les variables _SERVER["PATH"] et _ENV["PATH"]
Oui, c'est bon. Tu devrais donc pouvoir lancer la commande directement, mais il est toujours plus sûr d'y mettre le chemin complet comme tu l'as fait dernièrement.
3) Et si tu mettais le chemin complet (/usr/bin/head au lieu de head par exemple) ?
J'ai mis le chemin complet pour la commande top comme indiqué ci-dessus, mais la variable $return_var contient "1".
Et en ligne de commande, si tu fais « echo $? » après avoir lancé ta commande top, ça retourne 0 ?
Pourtant un passthru("ls -l"); affiche bien le contenu du répertoire.
Ce n'est donc pas un problème de la fonction passthru(), et donc vraisemblablement pas un problème PHP du tout. Essaye de chercher du côté des droits d'accès (utilisateur PHP). Par exemple, regarde ce que t'affiche « passthru("id") ».
J'ai essayé aussi: exec("/usr/bin/top >stdout.txt 2>stderr.txt", $result_var); Mais les fichiers ne sont pas créés et $result_var contient "Array".
L'interprétation de « > » et « 2> » ne se fait pas par l'exécutable mais par le shell, c'est donc normal que les fichiers ne soient pas créés. Ils le seraient probablement avec system() au lieu de exec(), et je suppose que stdout.txt serait vide, mais peut-être que tu aurais un message d'erreur dans stderr.txt : cela peut être une bonne idée d'essayer, donc.
Un contributeur (Thierry B.) avait ouvert un fil "Apache et windows->recuperer sortie com mande exec()" le 15 10 2005 et il ne s'en était sorti qu'en installant php5 qui n'est malheureusement pas disponible en package debian pour l'architecture hppa.
En tout cas, cela prouve que tu fais l'effort de chercher dans les archives, et je t'en félicite. Bon, essaye déjà les quelques propositions que je t'ai faites, et tu nous diras si cela donne quelque chose.
1) Est-ce que la commande head existe bien (en principe oui, mais on ne
sait jamais) ?
Oui, et pour éviter tout problème avec le pipe, j'ai réécrit la ligne
comme suit:
passthru("/usr/bin/top -bn1", $return_var);
echo $return_var
Est-ce que l'utilisateur qui lance PHP a bien le droit d'exécuter cette
commande ?
2) Sont-elles dans le PATH connu par PHP ?
Dans quel fichier le PATH se configure-t-il ?
À priori, je pense que c'est le PATH par défaut au moment où le process
Apache se lance. Peut-être dans /etc/profile ou un truc de ce genre,
mais de toute façon il ne faut pas le modifier juste pour ça.
Le fichier /etc/php4/apache2/php.ini ne contient pas de référence à
/usr/bin, pourtant la fonction phpinfo() affiche plusieurs occurences de
"/usr/local/bin:/usr/bin:/bin"
* dans la section "Apache Environment" pour la variable "PATH"
* dans la section "Environment" pour la variable "PATH"
* dans la section "PHP Variables", pour les variables _SERVER["PATH"] et
_ENV["PATH"]
Oui, c'est bon. Tu devrais donc pouvoir lancer la commande directement,
mais il est toujours plus sûr d'y mettre le chemin complet comme tu l'as
fait dernièrement.
3) Et si tu mettais le chemin complet (/usr/bin/head au lieu de head par
exemple) ?
J'ai mis le chemin complet pour la commande top comme indiqué ci-dessus,
mais la variable $return_var contient "1".
Et en ligne de commande, si tu fais « echo $? » après avoir lancé ta
commande top, ça retourne 0 ?
Pourtant un passthru("ls -l"); affiche bien le contenu du répertoire.
Ce n'est donc pas un problème de la fonction passthru(), et donc
vraisemblablement pas un problème PHP du tout. Essaye de chercher du
côté des droits d'accès (utilisateur PHP). Par exemple, regarde ce
que t'affiche « passthru("id") ».
J'ai essayé aussi: exec("/usr/bin/top >stdout.txt 2>stderr.txt", $result_var);
Mais les fichiers ne sont pas créés et $result_var contient "Array".
L'interprétation de « > » et « 2> » ne se fait pas par l'exécutable mais
par le shell, c'est donc normal que les fichiers ne soient pas créés.
Ils le seraient probablement avec system() au lieu de exec(), et je
suppose que stdout.txt serait vide, mais peut-être que tu aurais un
message d'erreur dans stderr.txt : cela peut être une bonne idée
d'essayer, donc.
Un contributeur (Thierry B.) avait ouvert un fil "Apache et
windows->recuperer sortie com mande exec()" le 15 10 2005 et il ne s'en
était sorti qu'en installant php5 qui n'est malheureusement pas
disponible en package debian pour l'architecture hppa.
En tout cas, cela prouve que tu fais l'effort de chercher dans
les archives, et je t'en félicite. Bon, essaye déjà les quelques
propositions que je t'ai faites, et tu nous diras si cela donne
quelque chose.
1) Est-ce que la commande head existe bien (en principe oui, mais on ne sait jamais) ?
Oui, et pour éviter tout problème avec le pipe, j'ai réécrit la ligne comme suit: passthru("/usr/bin/top -bn1", $return_var); echo $return_var
Est-ce que l'utilisateur qui lance PHP a bien le droit d'exécuter cette commande ?
2) Sont-elles dans le PATH connu par PHP ?
Dans quel fichier le PATH se configure-t-il ?
À priori, je pense que c'est le PATH par défaut au moment où le process Apache se lance. Peut-être dans /etc/profile ou un truc de ce genre, mais de toute façon il ne faut pas le modifier juste pour ça.
Le fichier /etc/php4/apache2/php.ini ne contient pas de référence à /usr/bin, pourtant la fonction phpinfo() affiche plusieurs occurences de "/usr/local/bin:/usr/bin:/bin" * dans la section "Apache Environment" pour la variable "PATH" * dans la section "Environment" pour la variable "PATH" * dans la section "PHP Variables", pour les variables _SERVER["PATH"] et _ENV["PATH"]
Oui, c'est bon. Tu devrais donc pouvoir lancer la commande directement, mais il est toujours plus sûr d'y mettre le chemin complet comme tu l'as fait dernièrement.
3) Et si tu mettais le chemin complet (/usr/bin/head au lieu de head par exemple) ?
J'ai mis le chemin complet pour la commande top comme indiqué ci-dessus, mais la variable $return_var contient "1".
Et en ligne de commande, si tu fais « echo $? » après avoir lancé ta commande top, ça retourne 0 ?
Pourtant un passthru("ls -l"); affiche bien le contenu du répertoire.
Ce n'est donc pas un problème de la fonction passthru(), et donc vraisemblablement pas un problème PHP du tout. Essaye de chercher du côté des droits d'accès (utilisateur PHP). Par exemple, regarde ce que t'affiche « passthru("id") ».
J'ai essayé aussi: exec("/usr/bin/top >stdout.txt 2>stderr.txt", $result_var); Mais les fichiers ne sont pas créés et $result_var contient "Array".
L'interprétation de « > » et « 2> » ne se fait pas par l'exécutable mais par le shell, c'est donc normal que les fichiers ne soient pas créés. Ils le seraient probablement avec system() au lieu de exec(), et je suppose que stdout.txt serait vide, mais peut-être que tu aurais un message d'erreur dans stderr.txt : cela peut être une bonne idée d'essayer, donc.
Un contributeur (Thierry B.) avait ouvert un fil "Apache et windows->recuperer sortie com mande exec()" le 15 10 2005 et il ne s'en était sorti qu'en installant php5 qui n'est malheureusement pas disponible en package debian pour l'architecture hppa.
En tout cas, cela prouve que tu fais l'effort de chercher dans les archives, et je t'en félicite. Bon, essaye déjà les quelques propositions que je t'ai faites, et tu nous diras si cela donne quelque chose.
Hugolino
Le 16 Oct 2006 07:41:16 GMT, Olivier Miakinen a écrit:
1) Est-ce que la commande head existe bien (en principe oui, mais on ne sait jamais) ?
Oui, et pour éviter tout problème avec le pipe, j'ai réécrit la ligne comme suit: passthru("/usr/bin/top -bn1", $return_var); echo $return_var
Est-ce que l'utilisateur qui lance PHP a bien le droit d'exécuter cette commande ?
Si l'utilisateur qui lance PHP est www-data, alors la réponse est oui.
[cut]
3) Et si tu mettais le chemin complet (/usr/bin/head au lieu de head par exemple) ?
J'ai mis le chemin complet pour la commande top comme indiqué ci-dessus, mais la variable $return_var contient "1".
Et en ligne de commande, si tu fais « echo $? » après avoir lancé ta commande top, ça retourne 0 ?
Oui
Pourtant un passthru("ls -l"); affiche bien le contenu du répertoire.
Ce n'est donc pas un problème de la fonction passthru(), et donc vraisemblablement pas un problème PHP du tout. Essaye de chercher du côté des droits d'accès (utilisateur PHP). Par exemple, regarde ce que t'affiche « passthru("id") ».
uid3(www-data) gid3(www-data) groups3(www-data)
J'ai essayé aussi: exec("/usr/bin/top >stdout.txt 2>stderr.txt", $result_var); Mais les fichiers ne sont pas créés et $result_var contient "Array".
L'interprétation de « > » et « 2> » ne se fait pas par l'exécutable mais par le shell, c'est donc normal que les fichiers ne soient pas créés. Ils le seraient probablement avec system() au lieu de exec(), et je suppose que stdout.txt serait vide, mais peut-être que tu aurais un message d'erreur dans stderr.txt : cela peut être une bonne idée d'essayer, donc.
Essayé mais il faut changer les droits en 777 sur /var/www. C'est aussi l'occasion de voir que top (donc PHP ?) est exécuté par l'utilisateur www-data. Et stderr.txt contient la ligne "TERM environment variable not set"... Et je ne sais pas ou configurer cette variable. Donc tu as sans doute raison, on devient quelque peu HC, ça n'a plus grand chose à voir avec PHP.
Merci de ton aide.
-- Linux, c'est simple : ça s'adresse à une machine qui est parfois un peu maraboutée mais qui d'habitude n'a pas d'états d'âme. Sur Usenet y'a plein d'humains et de primates, et ça devient vraiment gore par moment. -+- TP in : Guide du linuxien pervers - "Le linuxien a-t-il une âme ?" -+-
Le 16 Oct 2006 07:41:16 GMT, Olivier Miakinen a écrit:
1) Est-ce que la commande head existe bien (en principe oui, mais on ne
sait jamais) ?
Oui, et pour éviter tout problème avec le pipe, j'ai réécrit la ligne
comme suit:
passthru("/usr/bin/top -bn1", $return_var);
echo $return_var
Est-ce que l'utilisateur qui lance PHP a bien le droit d'exécuter cette
commande ?
Si l'utilisateur qui lance PHP est www-data, alors la réponse est oui.
[cut]
3) Et si tu mettais le chemin complet (/usr/bin/head au lieu de head par
exemple) ?
J'ai mis le chemin complet pour la commande top comme indiqué ci-dessus,
mais la variable $return_var contient "1".
Et en ligne de commande, si tu fais « echo $? » après avoir lancé ta
commande top, ça retourne 0 ?
Oui
Pourtant un passthru("ls -l"); affiche bien le contenu du répertoire.
Ce n'est donc pas un problème de la fonction passthru(), et donc
vraisemblablement pas un problème PHP du tout. Essaye de chercher du
côté des droits d'accès (utilisateur PHP). Par exemple, regarde ce
que t'affiche « passthru("id") ».
uid3(www-data) gid3(www-data) groups3(www-data)
J'ai essayé aussi: exec("/usr/bin/top >stdout.txt 2>stderr.txt", $result_var);
Mais les fichiers ne sont pas créés et $result_var contient "Array".
L'interprétation de « > » et « 2> » ne se fait pas par l'exécutable mais
par le shell, c'est donc normal que les fichiers ne soient pas créés.
Ils le seraient probablement avec system() au lieu de exec(), et je
suppose que stdout.txt serait vide, mais peut-être que tu aurais un
message d'erreur dans stderr.txt : cela peut être une bonne idée
d'essayer, donc.
Essayé mais il faut changer les droits en 777 sur /var/www.
C'est aussi l'occasion de voir que top (donc PHP ?) est exécuté par
l'utilisateur www-data.
Et stderr.txt contient la ligne "TERM environment variable not set"...
Et je ne sais pas ou configurer cette variable.
Donc tu as sans doute raison, on devient quelque peu HC, ça n'a plus
grand chose à voir avec PHP.
Merci de ton aide.
--
Linux, c'est simple : ça s'adresse à une machine qui est parfois un peu
maraboutée mais qui d'habitude n'a pas d'états d'âme. Sur Usenet y'a
plein d'humains et de primates, et ça devient vraiment gore par moment.
-+- TP in : Guide du linuxien pervers - "Le linuxien a-t-il une âme ?" -+-
Le 16 Oct 2006 07:41:16 GMT, Olivier Miakinen a écrit:
1) Est-ce que la commande head existe bien (en principe oui, mais on ne sait jamais) ?
Oui, et pour éviter tout problème avec le pipe, j'ai réécrit la ligne comme suit: passthru("/usr/bin/top -bn1", $return_var); echo $return_var
Est-ce que l'utilisateur qui lance PHP a bien le droit d'exécuter cette commande ?
Si l'utilisateur qui lance PHP est www-data, alors la réponse est oui.
[cut]
3) Et si tu mettais le chemin complet (/usr/bin/head au lieu de head par exemple) ?
J'ai mis le chemin complet pour la commande top comme indiqué ci-dessus, mais la variable $return_var contient "1".
Et en ligne de commande, si tu fais « echo $? » après avoir lancé ta commande top, ça retourne 0 ?
Oui
Pourtant un passthru("ls -l"); affiche bien le contenu du répertoire.
Ce n'est donc pas un problème de la fonction passthru(), et donc vraisemblablement pas un problème PHP du tout. Essaye de chercher du côté des droits d'accès (utilisateur PHP). Par exemple, regarde ce que t'affiche « passthru("id") ».
uid3(www-data) gid3(www-data) groups3(www-data)
J'ai essayé aussi: exec("/usr/bin/top >stdout.txt 2>stderr.txt", $result_var); Mais les fichiers ne sont pas créés et $result_var contient "Array".
L'interprétation de « > » et « 2> » ne se fait pas par l'exécutable mais par le shell, c'est donc normal que les fichiers ne soient pas créés. Ils le seraient probablement avec system() au lieu de exec(), et je suppose que stdout.txt serait vide, mais peut-être que tu aurais un message d'erreur dans stderr.txt : cela peut être une bonne idée d'essayer, donc.
Essayé mais il faut changer les droits en 777 sur /var/www. C'est aussi l'occasion de voir que top (donc PHP ?) est exécuté par l'utilisateur www-data. Et stderr.txt contient la ligne "TERM environment variable not set"... Et je ne sais pas ou configurer cette variable. Donc tu as sans doute raison, on devient quelque peu HC, ça n'a plus grand chose à voir avec PHP.
Merci de ton aide.
-- Linux, c'est simple : ça s'adresse à une machine qui est parfois un peu maraboutée mais qui d'habitude n'a pas d'états d'âme. Sur Usenet y'a plein d'humains et de primates, et ça devient vraiment gore par moment. -+- TP in : Guide du linuxien pervers - "Le linuxien a-t-il une âme ?" -+-
Olivier Miakinen
[ essayer avec system() ]
Essayé mais il faut changer les droits en 777 sur /var/www. C'est aussi l'occasion de voir que top (donc PHP ?) est exécuté par l'utilisateur www-data. Et stderr.txt contient la ligne "TERM environment variable not set"...
Ah, enfin la lumière ! Je ne sais pas pourquoi il a besoin de connaître le nom du terminal courant car je n'ai jamais utilisé cette commande, mais s'il le demande il faut le lui donner. Tu peux choisir par exemple la console s'il y en a une.
Et je ne sais pas ou configurer cette variable.
http://fr3.php.net/manual/fr/function.putenv.php
Donc tu as sans doute raison, on devient quelque peu HC, ça n'a plus grand chose à voir avec PHP.
On est revenus en charte de justesse avec la fonction putenv(). ;-)
[ essayer avec system() ]
Essayé mais il faut changer les droits en 777 sur /var/www.
C'est aussi l'occasion de voir que top (donc PHP ?) est exécuté par
l'utilisateur www-data.
Et stderr.txt contient la ligne "TERM environment variable not set"...
Ah, enfin la lumière ! Je ne sais pas pourquoi il a besoin de connaître
le nom du terminal courant car je n'ai jamais utilisé cette commande,
mais s'il le demande il faut le lui donner. Tu peux choisir par exemple
la console s'il y en a une.
Et je ne sais pas ou configurer cette variable.
http://fr3.php.net/manual/fr/function.putenv.php
Donc tu as sans doute raison, on devient quelque peu HC, ça n'a plus
grand chose à voir avec PHP.
On est revenus en charte de justesse avec la fonction putenv(). ;-)
Essayé mais il faut changer les droits en 777 sur /var/www. C'est aussi l'occasion de voir que top (donc PHP ?) est exécuté par l'utilisateur www-data. Et stderr.txt contient la ligne "TERM environment variable not set"...
Ah, enfin la lumière ! Je ne sais pas pourquoi il a besoin de connaître le nom du terminal courant car je n'ai jamais utilisé cette commande, mais s'il le demande il faut le lui donner. Tu peux choisir par exemple la console s'il y en a une.
Et je ne sais pas ou configurer cette variable.
http://fr3.php.net/manual/fr/function.putenv.php
Donc tu as sans doute raison, on devient quelque peu HC, ça n'a plus grand chose à voir avec PHP.
On est revenus en charte de justesse avec la fonction putenv(). ;-)
Michel Billaud
Olivier Miakinen <om+ writes:
Probleme de redirection de top
Et stderr.txt contient la ligne "TERM environment variable not set"...
Ah, enfin la lumière ! Je ne sais pas pourquoi il a besoin de connaître le nom du terminal courant
Pour savoir combien de lignes et de colonnes comporte le dispositif d'affichage... ?
car je n'ai jamais utilisé cette commande, mais s'il le demande il faut le lui donner. Tu peux choisir par exemple la console s'il y en a une.
Choisir le type "dumb" (si il existe), sinon le résultat risque de contenir des séquences escape-quelque chose qui ne seront pas du meilleur effet.
Et je ne sais pas ou configurer cette variable.
http://fr3.php.net/manual/fr/function.putenv.php
Inutile de se compliquer la vie. Dans une commande (unix) interprétée par un shell on peut precéder le nom du programme à lancer par des affectations de variables
<? passthru("TERM=dumb top -bn1"); ?>
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
Olivier Miakinen <om+news@miakinen.net> writes:
Probleme de redirection de top
Et stderr.txt contient la ligne "TERM environment variable not set"...
Ah, enfin la lumière ! Je ne sais pas pourquoi il a besoin de connaître
le nom du terminal courant
Pour savoir combien de lignes et de colonnes comporte le dispositif
d'affichage... ?
car je n'ai jamais utilisé cette commande,
mais s'il le demande il faut le lui donner. Tu peux choisir par exemple
la console s'il y en a une.
Choisir le type "dumb" (si il existe), sinon le résultat risque de
contenir des séquences escape-quelque chose qui ne seront pas du
meilleur effet.
Et je ne sais pas ou configurer cette variable.
http://fr3.php.net/manual/fr/function.putenv.php
Inutile de se compliquer la vie. Dans une commande (unix) interprétée
par un shell on peut precéder le nom du programme à lancer par des
affectations de variables
<?
passthru("TERM=dumb top -bn1");
?>
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
Et stderr.txt contient la ligne "TERM environment variable not set"...
Ah, enfin la lumière ! Je ne sais pas pourquoi il a besoin de connaître le nom du terminal courant
Pour savoir combien de lignes et de colonnes comporte le dispositif d'affichage... ?
car je n'ai jamais utilisé cette commande, mais s'il le demande il faut le lui donner. Tu peux choisir par exemple la console s'il y en a une.
Choisir le type "dumb" (si il existe), sinon le résultat risque de contenir des séquences escape-quelque chose qui ne seront pas du meilleur effet.
Et je ne sais pas ou configurer cette variable.
http://fr3.php.net/manual/fr/function.putenv.php
Inutile de se compliquer la vie. Dans une commande (unix) interprétée par un shell on peut precéder le nom du programme à lancer par des affectations de variables
<? passthru("TERM=dumb top -bn1"); ?>
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
Olivier Miakinen
http://fr3.php.net/manual/fr/function.putenv.php
Inutile de se compliquer la vie. Dans une commande (unix) interprétée par un shell on peut precéder le nom du programme à lancer par des affectations de variables
<? passthru("TERM=dumb top -bn1"); ?>
[OUI]
http://fr3.php.net/manual/fr/function.putenv.php
Inutile de se compliquer la vie. Dans une commande (unix) interprétée
par un shell on peut precéder le nom du programme à lancer par des
affectations de variables
Inutile de se compliquer la vie. Dans une commande (unix) interprétée par un shell on peut precéder le nom du programme à lancer par des affectations de variables
<? passthru("TERM=dumb top -bn1"); ?>
[OUI]
Hugolino
Le 19 Oct 2006 22:05:24 GMT, Olivier Miakinen a écrit:
http://fr3.php.net/manual/fr/function.putenv.php
Inutile de se compliquer la vie. Dans une commande (unix) interprétée par un shell on peut precéder le nom du programme à lancer par des affectations de variables
<? passthru("TERM=dumb top -bn1"); ?>
[OUI]
Oops!
En relisant le ng, je m'aperçois que j'ai oublié de dire merci.
Donc «Merci, ça marche».
--
je voudrais pirater la fac ou je suis qui est sur réseau sur linux! echo "rpub "w'nv yr cnffjbeq ebbg!"|znvy ebbg" |tr a-mn-z n-za-m|/bin/sh
-+- JD in Guide du linuxien pervers - "J'aime bien rendre service !" -+- Hugo (né il y a 1 341 611 681 secondes)
Le 19 Oct 2006 22:05:24 GMT, Olivier Miakinen a écrit:
http://fr3.php.net/manual/fr/function.putenv.php
Inutile de se compliquer la vie. Dans une commande (unix) interprétée
par un shell on peut precéder le nom du programme à lancer par des
affectations de variables
<?
passthru("TERM=dumb top -bn1");
?>
[OUI]
Oops!
En relisant le ng, je m'aperçois que j'ai oublié de dire merci.
Donc «Merci, ça marche».
--
je voudrais pirater la fac ou je suis qui est sur réseau sur linux!
echo "rpub "w'nv yr cnffjbeq ebbg!"|znvy ebbg" |tr a-mn-z n-za-m|/bin/sh
-+- JD in Guide du linuxien pervers - "J'aime bien rendre service !" -+-
Hugo (né il y a 1 341 611 681 secondes)
Le 19 Oct 2006 22:05:24 GMT, Olivier Miakinen a écrit:
http://fr3.php.net/manual/fr/function.putenv.php
Inutile de se compliquer la vie. Dans une commande (unix) interprétée par un shell on peut precéder le nom du programme à lancer par des affectations de variables
<? passthru("TERM=dumb top -bn1"); ?>
[OUI]
Oops!
En relisant le ng, je m'aperçois que j'ai oublié de dire merci.
Donc «Merci, ça marche».
--
je voudrais pirater la fac ou je suis qui est sur réseau sur linux! echo "rpub "w'nv yr cnffjbeq ebbg!"|znvy ebbg" |tr a-mn-z n-za-m|/bin/sh
-+- JD in Guide du linuxien pervers - "J'aime bien rendre service !" -+- Hugo (né il y a 1 341 611 681 secondes)
