Je rencontre un problème avec la commande os.system, et je ne sais
comment la résoudre...
Tout d'abord, le cadre :
création d'une appli pour windows, avec wxpython (intégration Flash)
J'ai besoin d'une commande me permettant d'ouvrir un répertoire sur le
disque : os.system( 'explorer.exe ' + path )
J'ai besoin d'une commande me permettant de lancer un exécutable sur le
disque : os.system( path + "monExecutable.exe" )
Enfin, j'ai besoin d'une commande me permettant de lancer un exécutable
en lui passant des paramètres : os.system( pathExe + "myExe execute "
+inputFile + " " + outputFile );
Bon, j'ai fait mon application sur un chemin sans espace
(e:\projects\python\myproject\build\, ayant l'habitude de le faire de
cette manière. Et bien sur, lorsque mon client l'a testée, il a placé ça
sur le bureau, donc "/Documents and Settings/", un chemin contenant des
espaces.
Et là, tout est foireux... Les commandes python fonctionnent très bien
(genre copyFile ou copyTree) mais os.system me fait des misères en me
spécifiant que 'c:\Documents' n'est pas reconnu en tant que commande
interne ou externe valide, blablabla...
J'ai essayé de passer les chemins entre guillemets, mais le problème reste.
Est-ce qu'il existe une solution pour continuer à utiliser os.system ?
ou alors une ou plusieurs autres commandes qui me permettent de faire
les mêmes actions sans être confronté à ce genre de problèmes ??
J'ai essayé de passer les chemins entre guillemets, mais le problème reste.
Tu as essayé avec le module os.path ?
% cat bla.py import os.path
print os.path.dirname('Document And Settings/bla.txt') print os.path.basename('Document And Settings/bla.txt') % python bla.py Document And Settings bla.txt
-- Éric Jacoboni, né il y a 1422892377 secondes
Titouille <titi2027@DELETEME-netplus.ch> writes:
J'ai essayé de passer les chemins entre guillemets, mais le problème reste.
Tu as essayé avec le module os.path ?
% cat bla.py
import os.path
print os.path.dirname('Document And Settings/bla.txt')
print os.path.basename('Document And Settings/bla.txt')
% python bla.py
Document And Settings
bla.txt
J'ai essayé de passer les chemins entre guillemets, mais le problème reste.
Tu as essayé avec le module os.path ?
% cat bla.py import os.path
print os.path.dirname('Document And Settings/bla.txt') print os.path.basename('Document And Settings/bla.txt') % python bla.py Document And Settings bla.txt
-- Éric Jacoboni, né il y a 1422892377 secondes
Titouille
Titouille writes:
J'ai essayé de passer les chemins entre guillemets, mais le problème reste.
Tu as essayé avec le module os.path ?
% cat bla.py import os.path
print os.path.dirname('Document And Settings/bla.txt') print os.path.basename('Document And Settings/bla.txt') % python bla.py Document And Settings bla.txt
Hello !!
Oui, chaque chemin est créé avec os.path d'abord, donc ce n'est pas un problème de chemin, car comme je l'ai dit, toutes les interactions python fonctionnent, même avec des chemins contenant des espaces... C'est juste la commande os.system qui est foireuse...
Titouille <titi2027@DELETEME-netplus.ch> writes:
J'ai essayé de passer les chemins entre guillemets, mais le problème reste.
Tu as essayé avec le module os.path ?
% cat bla.py
import os.path
print os.path.dirname('Document And Settings/bla.txt')
print os.path.basename('Document And Settings/bla.txt')
% python bla.py
Document And Settings
bla.txt
Hello !!
Oui, chaque chemin est créé avec os.path d'abord, donc ce n'est pas un
problème de chemin, car comme je l'ai dit, toutes les interactions
python fonctionnent, même avec des chemins contenant des espaces...
C'est juste la commande os.system qui est foireuse...
J'ai essayé de passer les chemins entre guillemets, mais le problème reste.
Tu as essayé avec le module os.path ?
% cat bla.py import os.path
print os.path.dirname('Document And Settings/bla.txt') print os.path.basename('Document And Settings/bla.txt') % python bla.py Document And Settings bla.txt
Hello !!
Oui, chaque chemin est créé avec os.path d'abord, donc ce n'est pas un problème de chemin, car comme je l'ai dit, toutes les interactions python fonctionnent, même avec des chemins contenant des espaces... C'est juste la commande os.system qui est foireuse...
Eric Jacoboni
Titouille writes:
C'est juste la commande os.system qui est foireuse...
C'est pas dit. os.system, comme son nom l'indique, ne fait que transmettre la commande au système sous-jacent.
Tu as vérifié que ton système (Windows, j'imagine) acceptait la ligne de commande telle que tu la passes à os.system ?
Je ne peux pas t'aider plus que ça... je n'utilise pas Windows. -- Éric Jacoboni, né il y a 1422896923 secondes
Titouille <titi2027@DELETEME-netplus.ch> writes:
C'est juste la commande os.system qui est foireuse...
C'est pas dit. os.system, comme son nom l'indique, ne fait que
transmettre la commande au système sous-jacent.
Tu as vérifié que ton système (Windows, j'imagine) acceptait la ligne
de commande telle que tu la passes à os.system ?
Je ne peux pas t'aider plus que ça... je n'utilise pas Windows.
--
Éric Jacoboni, né il y a 1422896923 secondes
C'est juste la commande os.system qui est foireuse...
C'est pas dit. os.system, comme son nom l'indique, ne fait que transmettre la commande au système sous-jacent.
Tu as vérifié que ton système (Windows, j'imagine) acceptait la ligne de commande telle que tu la passes à os.system ?
Je ne peux pas t'aider plus que ça... je n'utilise pas Windows. -- Éric Jacoboni, né il y a 1422896923 secondes
Vincent Bernat
OoO En ce début d'après-midi ensoleillé du mercredi 22 juin 2005, vers 15:43, Titouille disait:
Bon, j'ai fait mon application sur un chemin sans espace (e:projectspythonmyprojectbuild, ayant l'habitude de le faire de cette manière. Et bien sur, lorsque mon client l'a testée, il a placé ça sur le bureau, donc "/Documents and Settings/", un chemin contenant des espaces.
Et là, tout est foireux... Les commandes python fonctionnent très bien (genre copyFile ou copyTree) mais os.system me fait des misères en me spécifiant que 'c:Documents' n'est pas reconnu en tant que commande interne ou externe valide, blablabla...
Entoure tous les chemins potentiels d'une paire de guillemets. -- panic ("No CPUs found. System halted.n"); 2.4.3 linux/arch/parisc/kernel/setup.c
OoO En ce début d'après-midi ensoleillé du mercredi 22 juin 2005, vers
15:43, Titouille <titi2027@DELETEME-netplus.ch> disait:
Bon, j'ai fait mon application sur un chemin sans espace
(e:projectspythonmyprojectbuild, ayant l'habitude de le faire de
cette manière. Et bien sur, lorsque mon client l'a testée, il a placé ça
sur le bureau, donc "/Documents and Settings/", un chemin contenant des
espaces.
Et là, tout est foireux... Les commandes python fonctionnent très bien
(genre copyFile ou copyTree) mais os.system me fait des misères en me
spécifiant que 'c:Documents' n'est pas reconnu en tant que commande
interne ou externe valide, blablabla...
Entoure tous les chemins potentiels d'une paire de guillemets.
--
panic ("No CPUs found. System halted.n");
2.4.3 linux/arch/parisc/kernel/setup.c
OoO En ce début d'après-midi ensoleillé du mercredi 22 juin 2005, vers 15:43, Titouille disait:
Bon, j'ai fait mon application sur un chemin sans espace (e:projectspythonmyprojectbuild, ayant l'habitude de le faire de cette manière. Et bien sur, lorsque mon client l'a testée, il a placé ça sur le bureau, donc "/Documents and Settings/", un chemin contenant des espaces.
Et là, tout est foireux... Les commandes python fonctionnent très bien (genre copyFile ou copyTree) mais os.system me fait des misères en me spécifiant que 'c:Documents' n'est pas reconnu en tant que commande interne ou externe valide, blablabla...
Entoure tous les chemins potentiels d'une paire de guillemets. -- panic ("No CPUs found. System halted.n"); 2.4.3 linux/arch/parisc/kernel/setup.c
Titouille
OoO En ce début d'après-midi ensoleillé du mercredi 22 juin 2005, vers 15:43, Titouille disait:
Bon, j'ai fait mon application sur un chemin sans espace (e:projectspythonmyprojectbuild, ayant l'habitude de le faire de cette manière. Et bien sur, lorsque mon client l'a testée, il a placé ça sur le bureau, donc "/Documents and Settings/", un chemin contenant des espaces.
Et là, tout est foireux... Les commandes python fonctionnent très bien (genre copyFile ou copyTree) mais os.system me fait des misères en me spécifiant que 'c:Documents' n'est pas reconnu en tant que commande interne ou externe valide, blablabla...
Entoure tous les chemins potentiels d'une paire de guillemets.
Je reprend ici, mais je répond également à Eric par la même occasion.
car je sais que c'est important sur les commandes windows, mais ça ne change rien, il continue à planter sur l'espace... peut-être que je m'y prend mal ??
En tout cas, merci d'essayer de m'aider :)
Cordialement Thierry
OoO En ce début d'après-midi ensoleillé du mercredi 22 juin 2005, vers
15:43, Titouille <titi2027@DELETEME-netplus.ch> disait:
Bon, j'ai fait mon application sur un chemin sans espace
(e:projectspythonmyprojectbuild, ayant l'habitude de le faire de
cette manière. Et bien sur, lorsque mon client l'a testée, il a placé ça
sur le bureau, donc "/Documents and Settings/", un chemin contenant des
espaces.
Et là, tout est foireux... Les commandes python fonctionnent très bien
(genre copyFile ou copyTree) mais os.system me fait des misères en me
spécifiant que 'c:Documents' n'est pas reconnu en tant que commande
interne ou externe valide, blablabla...
Entoure tous les chemins potentiels d'une paire de guillemets.
Je reprend ici, mais je répond également à Eric par la même occasion.
car je sais que c'est important sur les commandes windows, mais ça ne
change rien, il continue à planter sur l'espace... peut-être que je m'y
prend mal ??
OoO En ce début d'après-midi ensoleillé du mercredi 22 juin 2005, vers 15:43, Titouille disait:
Bon, j'ai fait mon application sur un chemin sans espace (e:projectspythonmyprojectbuild, ayant l'habitude de le faire de cette manière. Et bien sur, lorsque mon client l'a testée, il a placé ça sur le bureau, donc "/Documents and Settings/", un chemin contenant des espaces.
Et là, tout est foireux... Les commandes python fonctionnent très bien (genre copyFile ou copyTree) mais os.system me fait des misères en me spécifiant que 'c:Documents' n'est pas reconnu en tant que commande interne ou externe valide, blablabla...
Entoure tous les chemins potentiels d'une paire de guillemets.
Je reprend ici, mais je répond également à Eric par la même occasion.
car je sais que c'est important sur les commandes windows, mais ça ne change rien, il continue à planter sur l'espace... peut-être que je m'y prend mal ??
Bravo, mais vous reculez pour mieux sauter, car le problème vient réellement du fait que os.system() balance la commande à l'interpréteur de commande cmd.exe ou command.com. Or windows est un peu faible du côté de la ligne de commandes et donc ce qui est appelé 'shell' sous unix est appelé 'interpréteur de commandes' sous Windows, et ce que Billou appelle 'shell' c'est un truc du genre 'explorer.exe' ou iexplore ou autre machin.
Ceci étant, tout n'est pas perdu, car Python 2.4 contient un module subprocess pour faire tout ce que le préopinant avait demandé.
import tempfile import subprocess
import os import os.path
def mini_which(fnexec): """retourne une liste des chemins contenant fnexec """ paths = os.environ['PATH'].split(os.pathsep) possible = [ os.path.join(path, fnexec) for path in paths ] return filter(os.path.exists, possible)
# dans une fonction, je veux lancer windiff (si dans PATH) where = mini_which('windiff.exe') if not where: return path = where[0]
# les paramètres sont les noms de deux fichiers fn1 et fn2 qui se # trouvent dans le répertoire temporaire (avec espaces Documents and # settings.... tdir = tempfile.gettempdir() child = subprocess.Popen(('windiff', fn1, fn2), executable=path, cwd=tdir ) rc = child.wait() print rc
Les avantages de subprocess : n'utilise pas le shell, mais directement CreateProcess() accepte les paramètres sous la forme de chaînes Python (la commande est donnée sous la forme d'une séquence de string) : pas de problème avec des espaces inclus ou d'autres caractères parasites. permet de préciser le répertoire dans lequel l'exécution aura lieu si vous voulez être rigoureux et donner le nom de l'exécutable, il faut donner le chemin complet dans executable=xxx. La fonction mini_which() ci-dessus (que j'ai écrite aujourd'hui même) est très pratique.
manager's summary: subprocess c'est bien, os.sytem() ça eut allé.
Ok...
C'est pas des trucs de tordus, non...
Je ne vous le fais pas dire :-)
import os
il faut avoir au final un double "guillemet double" en entrée.
Bravo, mais vous reculez pour mieux sauter, car le problème
vient réellement du fait que os.system() balance la commande à
l'interpréteur de commande cmd.exe ou command.com. Or windows est un peu
faible du côté de la ligne de commandes et donc ce qui est appelé
'shell' sous unix est appelé 'interpréteur de commandes' sous Windows,
et ce que Billou appelle 'shell' c'est un truc du genre 'explorer.exe'
ou iexplore ou autre machin.
Ceci étant, tout n'est pas perdu, car Python 2.4 contient un module
subprocess pour faire tout ce que le préopinant avait demandé.
import tempfile
import subprocess
import os
import os.path
def mini_which(fnexec):
"""retourne une liste des chemins contenant fnexec
"""
paths = os.environ['PATH'].split(os.pathsep)
possible = [ os.path.join(path, fnexec) for path in paths ]
return filter(os.path.exists, possible)
# dans une fonction, je veux lancer windiff (si dans PATH)
where = mini_which('windiff.exe')
if not where:
return
path = where[0]
# les paramètres sont les noms de deux fichiers fn1 et fn2 qui se
# trouvent dans le répertoire temporaire (avec espaces Documents and
# settings....
tdir = tempfile.gettempdir()
child = subprocess.Popen(('windiff', fn1, fn2), executable=path,
cwd=tdir )
rc = child.wait()
print rc
Les avantages de subprocess :
n'utilise pas le shell, mais directement CreateProcess()
accepte les paramètres sous la forme de chaînes Python (la commande
est donnée sous la forme d'une séquence de string) : pas de problème
avec des espaces inclus ou d'autres caractères parasites.
permet de préciser le répertoire dans lequel l'exécution aura lieu
si vous voulez être rigoureux et donner le nom de l'exécutable, il
faut donner le chemin complet dans executable=xxx. La fonction
mini_which() ci-dessus (que j'ai écrite aujourd'hui même) est très
pratique.
manager's summary: subprocess c'est bien, os.sytem() ça eut allé.
Bravo, mais vous reculez pour mieux sauter, car le problème vient réellement du fait que os.system() balance la commande à l'interpréteur de commande cmd.exe ou command.com. Or windows est un peu faible du côté de la ligne de commandes et donc ce qui est appelé 'shell' sous unix est appelé 'interpréteur de commandes' sous Windows, et ce que Billou appelle 'shell' c'est un truc du genre 'explorer.exe' ou iexplore ou autre machin.
Ceci étant, tout n'est pas perdu, car Python 2.4 contient un module subprocess pour faire tout ce que le préopinant avait demandé.
import tempfile import subprocess
import os import os.path
def mini_which(fnexec): """retourne une liste des chemins contenant fnexec """ paths = os.environ['PATH'].split(os.pathsep) possible = [ os.path.join(path, fnexec) for path in paths ] return filter(os.path.exists, possible)
# dans une fonction, je veux lancer windiff (si dans PATH) where = mini_which('windiff.exe') if not where: return path = where[0]
# les paramètres sont les noms de deux fichiers fn1 et fn2 qui se # trouvent dans le répertoire temporaire (avec espaces Documents and # settings.... tdir = tempfile.gettempdir() child = subprocess.Popen(('windiff', fn1, fn2), executable=path, cwd=tdir ) rc = child.wait() print rc
Les avantages de subprocess : n'utilise pas le shell, mais directement CreateProcess() accepte les paramètres sous la forme de chaînes Python (la commande est donnée sous la forme d'une séquence de string) : pas de problème avec des espaces inclus ou d'autres caractères parasites. permet de préciser le répertoire dans lequel l'exécution aura lieu si vous voulez être rigoureux et donner le nom de l'exécutable, il faut donner le chemin complet dans executable=xxx. La fonction mini_which() ci-dessus (que j'ai écrite aujourd'hui même) est très pratique.
manager's summary: subprocess c'est bien, os.sytem() ça eut allé.
Do Re Mi chel La Si Do
Bonsoir !
Hou ! la ! la ! Que de guillemets. Tu as eu un prix de gros ?
En fait les guillemets ne sont obligatoires que pour la partie contenant un espace.
Exemple : import os cde = 'copy' inF = r'C:"mon test"test.xml' outF = r'C:"mon test"test.sw' os.system(cde+' '+inF+ ' '+outF)
Plus intéressant : import os cde = 'copy' inF = r'C:mon" "testtest.xml' outF = r'C:mon" "testtest.sw' os.system(cde+' '+inF+ ' '+outF)
(on peut gérer ça avec un "replace" au bon endroit)
Bonsoir
Michel Claveau
Bonsoir !
Hou ! la ! la ! Que de guillemets. Tu as eu un prix de gros ?
En fait les guillemets ne sont obligatoires que pour la partie contenant un
espace.
Exemple :
import os
cde = 'copy'
inF = r'C:"mon test"test.xml'
outF = r'C:"mon test"test.sw'
os.system(cde+' '+inF+ ' '+outF)
Plus intéressant :
import os
cde = 'copy'
inF = r'C:mon" "testtest.xml'
outF = r'C:mon" "testtest.sw'
os.system(cde+' '+inF+ ' '+outF)
(on peut gérer ça avec un "replace" au bon endroit)
Hou ! la ! la ! Que de guillemets. Tu as eu un prix de gros ?
En fait les guillemets ne sont obligatoires que pour la partie contenant un espace.
Exemple : import os cde = 'copy' inF = r'C:"mon test"test.xml' outF = r'C:"mon test"test.sw' os.system(cde+' '+inF+ ' '+outF)
Plus intéressant : import os cde = 'copy' inF = r'C:mon" "testtest.xml' outF = r'C:mon" "testtest.sw' os.system(cde+' '+inF+ ' '+outF)
(on peut gérer ça avec un "replace" au bon endroit)
Bonsoir
Michel Claveau
Amaury
Est-ce qu'il existe une solution pour continuer à utiliser os.system ? ou alors une ou plusieurs autres commandes qui me permettent de faire les mêmes actions sans être confronté à ce genre de problèmes ??
Depuis python 2.4, il y a le module subprocess qui a été conçu pour éviter ces problèmes.
Amaury.
Est-ce qu'il existe une solution pour continuer à utiliser os.system ?
ou alors une ou plusieurs autres commandes qui me permettent de faire
les mêmes actions sans être confronté à ce genre de problèmes ??
Depuis python 2.4, il y a le module subprocess qui a été conçu pour
éviter ces problèmes.
Est-ce qu'il existe une solution pour continuer à utiliser os.system ? ou alors une ou plusieurs autres commandes qui me permettent de faire les mêmes actions sans être confronté à ce genre de problèmes ??
Depuis python 2.4, il y a le module subprocess qui a été conçu pour éviter ces problèmes.
Amaury.
Titouille
Est-ce qu'il existe une solution pour continuer à utiliser os.system ? ou alors une ou plusieurs autres commandes qui me permettent de faire les mêmes actions sans être confronté à ce genre de problèmes ??
Depuis python 2.4, il y a le module subprocess qui a été conçu pour éviter ces problèmes.
Amaury.
Merci à vous tous, particulièrement à F. Petitjean qui a pondu un joli code et de très bonne explications sur subprocess.
Michel, en voyant tes exemples, la syntaxe de python m'étonnera toujours :)
Pour le module subprocess, malheureusement, je ne peux pas l'utiliser, car je suis cantonné à faire du code avec python 2.3. Le module shockwave Flash de python 2.4 est buggé, il ne prend qu'un seul fichier (la base), mais pas les fichiers inclus dans la base (via loadMovie). Donc ça limite beaucoup l'utilisation... Et comme j'utilise bcp python pour faire des interactions système avec Flash, je vais en rester là pour le moment. Mais je me souviendrai de subprocess, merci ;)
Cordialement Thierry
Est-ce qu'il existe une solution pour continuer à utiliser os.system ?
ou alors une ou plusieurs autres commandes qui me permettent de faire
les mêmes actions sans être confronté à ce genre de problèmes ??
Depuis python 2.4, il y a le module subprocess qui a été conçu pour
éviter ces problèmes.
Amaury.
Merci à vous tous, particulièrement à F. Petitjean qui a pondu un joli
code et de très bonne explications sur subprocess.
Michel, en voyant tes exemples, la syntaxe de python m'étonnera toujours :)
Pour le module subprocess, malheureusement, je ne peux pas l'utiliser,
car je suis cantonné à faire du code avec python 2.3. Le module
shockwave Flash de python 2.4 est buggé, il ne prend qu'un seul fichier
(la base), mais pas les fichiers inclus dans la base (via loadMovie).
Donc ça limite beaucoup l'utilisation...
Et comme j'utilise bcp python pour faire des interactions système avec
Flash, je vais en rester là pour le moment. Mais je me souviendrai de
subprocess, merci ;)
Est-ce qu'il existe une solution pour continuer à utiliser os.system ? ou alors une ou plusieurs autres commandes qui me permettent de faire les mêmes actions sans être confronté à ce genre de problèmes ??
Depuis python 2.4, il y a le module subprocess qui a été conçu pour éviter ces problèmes.
Amaury.
Merci à vous tous, particulièrement à F. Petitjean qui a pondu un joli code et de très bonne explications sur subprocess.
Michel, en voyant tes exemples, la syntaxe de python m'étonnera toujours :)
Pour le module subprocess, malheureusement, je ne peux pas l'utiliser, car je suis cantonné à faire du code avec python 2.3. Le module shockwave Flash de python 2.4 est buggé, il ne prend qu'un seul fichier (la base), mais pas les fichiers inclus dans la base (via loadMovie). Donc ça limite beaucoup l'utilisation... Et comme j'utilise bcp python pour faire des interactions système avec Flash, je vais en rester là pour le moment. Mais je me souviendrai de subprocess, merci ;)
