Directive #! /usr/bin/python3 ignorée

[Mips]

Oui évidement, j’étais distrait en proposant ça…

[olive]

@jpty @Salvialf @Mips

Bon vous m’avez empêché de dormir

Mais c’est pas grave …

En faite le plugin n’est pas si mal écrit que ça c’est plutôt sa documentation qui aide pas dans cette affaire.

Si l’on regarde bien le code de la classe sur la partie case ‹ script ›.

case 'script':
if($this->getType() == 'info' && isset(script::$_requet_cache[$request])){
$result = script::$_requet_cache[$request];
}else{
if (strpos($request, '.php') !== false) {
$request_shell = new com_shell('php ' . $request . ' 2>&1');
} elseif (strpos($request, '.rb') !== false) {
$request_shell = new com_shell('ruby ' . $request . ' 2>&1');
} elseif (strpos($request, '.py') !== false) {
$request_shell = new com_shell('python ' . $request . ' 2>&1');
} elseif (strpos($request, '.pl') !== false) {
$request_shell = new com_shell('perl ' . $request . ' 2>&1');
} 

else {$request_shell = new com_shell($request . ' 2>&1');}

Après avoir tester tout un tas d’extension possible le else final tente simplement d’exécuter le fichier.

Il est donc très simple d’enlever l’extention .py au script pour qu’il soit executer

un détail, ne pas oublier la directive en première ligne du script

#!/usr/bin/env python3

qui dans cet exemple exécutera du python3.

Faut t’il qu’il soit exécutable … 3 solutions.

1 passer par l’éditeur du plugin-script au moment de la sauvegarde des droits d’exécution sont donnés
2 attendre ou lancer une sauvegarde
3 utiliser chmod chown

Bon je vous laisse le PHP et retourne finir ma nuit avec mon python

PS : Faudrait faire une correction de la documentation pour spécifier cette possibilité.

[jpty]

Bonjour @olive

Oui sans extension, ça va fonctionner.
Toutefois je ne suis pas fan des fichiers sans extension qu’il faut ouvrir pour voir ce qu’ils contiennent.
Un double-clic dessus suffit pour l’éditer.
( J’utilise l’explo de Windows qui ne se base que sur l’extension pour déterminer le type de fichier. )

Pour les chmod, chown, il y a sur la page http://jeedom/index.php?v=d&p=administration#ostab
qui fait des chmod 775
Le plus complet est le shell script health.sh accessible sur la même page par:

qui fait les chown et chmod

Je préfére une solution de ce type qui conserve l’extension .py, qui reste compatible avec l’existant puisqu’elle vérifie si c’est exécutable et si le shebang est présent dans le fichier:

       elseif (($posPy=strpos($request, '.py')) !== false) {
          // suppression des arguments de la commande (apres .py)
          $file = trim(substr($request,0,$posPy)) .'.py';
          if(is_executable($file)) {
            $f = file($file);
            // recherche si la 1ere ligne contient #!
            if($f !== false && strpos($f[0],'#!') !== false) {
              $request_shell = new com_shell($request . ' 2>&1');
            }
            else {
              $request_shell = new com_shell('python ' . $request . ' 2>&1');
            }
          }
          else { // non executable lancement comme avant modif
            $request_shell = new com_shell('python ' . $request . ' 2>&1');
          }
        }

J’espère ne pas t’avoir réveillé trop tôt.

[olive]

Rien ne t’empêche de mettre une extension qui ne soit pas dans la liste.
fichier.python3 par exemple …

[jpty]

Déjà réveillé !

Mauvais exemple, il y a .py dans l’extension que tu proposes.
Avec une extension kivabien, ça fonctionne.
Le mieux est l’extension .PY (en majuscules)

[olive]

Bien mais ta solution nécessite la modification du fichier classe de script.
Et avant que ça arrive l’eau va encore couler sous les ponts …
donc restons simple. et si ton windaube veut des extensions il y a pleins de choix possible …

Toute cette sélection par extensions n’apporte rien que des problème il n’y aurait que moi je serait pour la suppression puisque a la sortie de l’éditeur du script tout sera de toute façon executable.

[Arno70]

Bonjour à tous.

Voici donc qui répond à la question que je me pose (et qui me tenait en échec) depuis longtemps : pourquoi mes scripts fonctionnent lorsqu’ils sont lancés en direct sur la console et non avec le plugin script ? Parce qu’ils sont écrits en Python 3 !

Comme dit, plus haut, il est en effet temps d’y remédier car Python 2.x va devenir obsolète. Je suis bien incapable de m’y pencher mais je ne doute pas que les développeurs du plugin se pencheront sur le sujet tôt au tard.

@olive : tu évoquais une solution de contournement ?

D’autres idées ?

Merci pour votre aide.

[olive]

Oui ne pas mettre d’extension a ton script et ne pas oublier la directive :

#!/usr/bin/env python3

[Arno70]

Oui, j’ai essayé aussi. Mais le script appelle des modules qui sont un peu partout dans le dossier. Alors certes il se lance, mais il s’arrête très vite…
Tu parlais d’une commande shell ?

[olive]

ben positionne tes modules dans le même répertoire que ton script …
le shell reviens au même (c’est ce que fait plugin-script) sauf que si il y a « .py » quelque part il te lance du pyhthon2 donc la soluce est de ne pas avoir une occurrence reconnue

.pxy si tu veut