Parce que tu crées des process fils qui n'ont, par concéquence, pas de portée globale. A la fin du process, les variables d'environnements propre au fils sont détruites.
Bonjour !
Sous windows + Python 2.4, j'ai deux scripts :
1) ess.bat : echo off SET AA=AZERTY echo %AA%
ess.py
SET AA=AZERTY echo %AA%
2) ess.py import os print 't',os.environ['AA'] os.environ['AA']='ABCDE' print 't',os.getenv('AA')
Le lancement de "ess.bat" donne, comme résultat : AZERTY AZERTY ABCDE AZERTY
Avec "os.putenv()", ça ne marche pas mieux.
Question : pourquoi la variable d'environnement "AA" ne résiste-t'elle pas à la fin du script "ess.py" ?
@-salutations
Michel Claveau
Parce que tu crées des process fils qui n'ont, par concéquence, pas de
portée globale. A la fin du process, les variables d'environnements
propre au fils sont détruites.
Bonjour !
Sous windows + Python 2.4, j'ai deux scripts :
1) ess.bat :
echo off
SET AA=AZERTY
echo %AA%
ess.py
SET AA=AZERTY
echo %AA%
2) ess.py
import os
print 't',os.environ['AA']
os.environ['AA']='ABCDE'
print 't',os.getenv('AA')
Le lancement de "ess.bat" donne, comme résultat :
AZERTY
AZERTY
ABCDE
AZERTY
Avec "os.putenv()", ça ne marche pas mieux.
Question : pourquoi la variable d'environnement "AA" ne résiste-t'elle pas à
la fin du script "ess.py" ?
Parce que tu crées des process fils qui n'ont, par concéquence, pas de portée globale. A la fin du process, les variables d'environnements propre au fils sont détruites.
Bonjour !
Sous windows + Python 2.4, j'ai deux scripts :
1) ess.bat : echo off SET AA=AZERTY echo %AA%
ess.py
SET AA=AZERTY echo %AA%
2) ess.py import os print 't',os.environ['AA'] os.environ['AA']='ABCDE' print 't',os.getenv('AA')
Le lancement de "ess.bat" donne, comme résultat : AZERTY AZERTY ABCDE AZERTY
Avec "os.putenv()", ça ne marche pas mieux.
Question : pourquoi la variable d'environnement "AA" ne résiste-t'elle pas à la fin du script "ess.py" ?
@-salutations
Michel Claveau
Tibi
Do Re Mi chel La Si Do wrote:
Question : pourquoi la variable d'environnement "AA" ne résiste-t'elle pas à la fin du script "ess.py" ?
C'est normal, un putenv n'affecte que les sous-processus. Je ne sais pas si il y a un moyen de propager les changements au processus parent, je n'ai jamais vu ça.
Do Re Mi chel La Si Do wrote:
Question : pourquoi la variable d'environnement "AA" ne résiste-t'elle pas
à la fin du script "ess.py" ?
C'est normal, un putenv n'affecte que les sous-processus.
Je ne sais pas si il y a un moyen de propager les changements au processus
parent, je n'ai jamais vu ça.
Question : pourquoi la variable d'environnement "AA" ne résiste-t'elle pas à la fin du script "ess.py" ?
C'est normal, un putenv n'affecte que les sous-processus. Je ne sais pas si il y a un moyen de propager les changements au processus parent, je n'ai jamais vu ça.
kaerbuhez
<snip>
Question : pourquoi la variable d'environnement "AA" ne résiste-t'elle pas à la fin du script "ess.py" ?
Parceque comme le dit la doc du module os: "These functions and data items provide information and operate on the current process and user. " Donc quand tu sors de ton process, plus d'effet.
J'espére avoir (bien ?) répondu à ta question ;-)) Sans blague, difficile d'en dire plus sans savoir ce que tu veux faire.
<snip>
Question : pourquoi la variable d'environnement "AA" ne résiste-t'elle pas à
la fin du script "ess.py" ?
Parceque comme le dit la doc du module os:
"These functions and data items provide information and operate on the
current process and user. " Donc quand tu sors de ton process, plus d'effet.
J'espére avoir (bien ?) répondu à ta question ;-))
Sans blague, difficile d'en dire plus sans savoir ce que tu veux faire.
Question : pourquoi la variable d'environnement "AA" ne résiste-t'elle pas à la fin du script "ess.py" ?
Parceque comme le dit la doc du module os: "These functions and data items provide information and operate on the current process and user. " Donc quand tu sors de ton process, plus d'effet.
J'espére avoir (bien ?) répondu à ta question ;-)) Sans blague, difficile d'en dire plus sans savoir ce que tu veux faire.
Christophe Cavalaria
Do Re Mi chel La Si Do wrote:
Bonjour !
Sous windows + Python 2.4, j'ai deux scripts :
1) ess.bat : echo off SET AA=AZERTY echo %AA%
ess.py
SET AA=AZERTY
Sans cette ligne, ça aura plus de chances de marcher ( pas strictement plus bien sur car ce que tu veux faire est impossible :) )
echo %AA%
[snip]
Avec "os.putenv()", ça ne marche pas mieux.
Question : pourquoi la variable d'environnement "AA" ne résiste-t'elle pas à la fin du script "ess.py" ?
Comme ça a été déjà dit. Les variables d'environement sont passées d'un processus parent à un processus fils par recopie. Il n'existe aucun moyen pour un processus fils de modifier les variables d'environement du processus parent. Sauf bien sur à donner un moyen au processus fils de comuniquer avec le processus parent pour que celui-ci puisse modifier lui même sont environement.
Do Re Mi chel La Si Do wrote:
Bonjour !
Sous windows + Python 2.4, j'ai deux scripts :
1) ess.bat :
echo off
SET AA=AZERTY
echo %AA%
ess.py
SET AA=AZERTY
Sans cette ligne, ça aura plus de chances de marcher ( pas strictement plus
bien sur car ce que tu veux faire est impossible :) )
echo %AA%
[snip]
Avec "os.putenv()", ça ne marche pas mieux.
Question : pourquoi la variable d'environnement "AA" ne résiste-t'elle pas
à la fin du script "ess.py" ?
Comme ça a été déjà dit. Les variables d'environement sont passées d'un
processus parent à un processus fils par recopie. Il n'existe aucun moyen
pour un processus fils de modifier les variables d'environement du
processus parent. Sauf bien sur à donner un moyen au processus fils de
comuniquer avec le processus parent pour que celui-ci puisse modifier lui
même sont environement.
Sans cette ligne, ça aura plus de chances de marcher ( pas strictement plus bien sur car ce que tu veux faire est impossible :) )
echo %AA%
[snip]
Avec "os.putenv()", ça ne marche pas mieux.
Question : pourquoi la variable d'environnement "AA" ne résiste-t'elle pas à la fin du script "ess.py" ?
Comme ça a été déjà dit. Les variables d'environement sont passées d'un processus parent à un processus fils par recopie. Il n'existe aucun moyen pour un processus fils de modifier les variables d'environement du processus parent. Sauf bien sur à donner un moyen au processus fils de comuniquer avec le processus parent pour que celui-ci puisse modifier lui même sont environement.
Do Re Mi chel La Si Do
Re
tu crées des process fils
Je m'en doutais un peu. Mais j'espérais qu'il y aurait moyen de passer au travers, pour ces raisons :
- les CALL permettent d'affecter les variables d'environnement de l'appelant ; j'espérais que Python puisse le faire. - lorsque j'appelle Python depuis Object-Pal, un nouveau processus "python" est bien créé, et pourtant la zone mémoire est commune aux deux langages, puisque je peux lire/écrire dans les variables/objets, octet par octet. Mais, dans ce système, les variables d'environnement sont complètement différenciées, même en lecture. - puisque les variables d'environnement sont lues, au moment du traitement de site.py, pourquoi ne pourraient-elles pas être écrites ?
Donc, tout ça n'est pas si évident. Merci quand même.
Michel Claveau
Re
tu crées des process fils
Je m'en doutais un peu. Mais j'espérais qu'il y aurait moyen de passer au
travers, pour ces raisons :
- les CALL permettent d'affecter les variables d'environnement de
l'appelant ; j'espérais que Python puisse le faire.
- lorsque j'appelle Python depuis Object-Pal, un nouveau processus
"python" est bien créé, et pourtant la zone mémoire est commune aux deux
langages, puisque je peux lire/écrire dans les variables/objets, octet par
octet. Mais, dans ce système, les variables d'environnement sont
complètement différenciées, même en lecture.
- puisque les variables d'environnement sont lues, au moment du
traitement de site.py, pourquoi ne pourraient-elles pas être écrites ?
Donc, tout ça n'est pas si évident. Merci quand même.
Je m'en doutais un peu. Mais j'espérais qu'il y aurait moyen de passer au travers, pour ces raisons :
- les CALL permettent d'affecter les variables d'environnement de l'appelant ; j'espérais que Python puisse le faire. - lorsque j'appelle Python depuis Object-Pal, un nouveau processus "python" est bien créé, et pourtant la zone mémoire est commune aux deux langages, puisque je peux lire/écrire dans les variables/objets, octet par octet. Mais, dans ce système, les variables d'environnement sont complètement différenciées, même en lecture. - puisque les variables d'environnement sont lues, au moment du traitement de site.py, pourquoi ne pourraient-elles pas être écrites ?
Donc, tout ça n'est pas si évident. Merci quand même.
Michel Claveau
Do Re Mi chel La Si Do
Re
Merci. Mais, comme les variables d'environnement sont lues, au moment du traitement de site.py (cd doc du module os), pourquoi Python ne pourrait-il pas écrire ? Il va falloir que je regarde l'intérieur de site.py
@-salutations
Michel Claveau
Re
Merci. Mais, comme les variables d'environnement sont lues, au moment du
traitement de site.py (cd doc du module os), pourquoi Python ne pourrait-il
pas écrire ?
Il va falloir que je regarde l'intérieur de site.py
Merci. Mais, comme les variables d'environnement sont lues, au moment du traitement de site.py (cd doc du module os), pourquoi Python ne pourrait-il pas écrire ? Il va falloir que je regarde l'intérieur de site.py
@-salutations
Michel Claveau
Do Re Mi chel La Si Do
Re
Je te cite aussi la doc d'os :
"This mapping is captured the first time the os module is imported, typically during Python startup as part of processing site.py. Changes to the environment made after this time are not reflected in os.environ, except for changes made by modifying os.environ directly. If the platform supports the putenv() function, this mapping may be used to modify the environment as well as query the environment. putenv() will be called automatically when the mapping is modified. Note: Calling putenv() directly does not change os.environ, so it's better to modify os.environ. If putenv() is not provided, this mapping may be passed to the appropriate process-creation functions to cause child processes to use a modified environment."
En tout cas, ça prouve combien mon anglais est insuffisant, car j'avais cru comprendre qu'il y avait une possibilité.
Pour l'usage, c'est simplement car je voulais utiliser Python pour étendre des commandes batch (.BAT).
Bonne journée
Michel Claveau
Re
Je te cite aussi la doc d'os :
"This mapping is captured the first time the os module is imported,
typically during Python startup as part of processing site.py. Changes to
the environment made after this time are not reflected in os.environ, except
for changes made by modifying os.environ directly.
If the platform supports the putenv() function, this mapping may be used to
modify the environment as well as query the environment. putenv() will be
called automatically when the mapping is modified. Note: Calling putenv()
directly does not change os.environ, so it's better to modify os.environ.
If putenv() is not provided, this mapping may be passed to the appropriate
process-creation functions to cause child processes to use a modified
environment."
En tout cas, ça prouve combien mon anglais est insuffisant, car j'avais cru
comprendre qu'il y avait une possibilité.
Pour l'usage, c'est simplement car je voulais utiliser Python pour étendre
des commandes batch (.BAT).
"This mapping is captured the first time the os module is imported, typically during Python startup as part of processing site.py. Changes to the environment made after this time are not reflected in os.environ, except for changes made by modifying os.environ directly. If the platform supports the putenv() function, this mapping may be used to modify the environment as well as query the environment. putenv() will be called automatically when the mapping is modified. Note: Calling putenv() directly does not change os.environ, so it's better to modify os.environ. If putenv() is not provided, this mapping may be passed to the appropriate process-creation functions to cause child processes to use a modified environment."
En tout cas, ça prouve combien mon anglais est insuffisant, car j'avais cru comprendre qu'il y avait une possibilité.
Pour l'usage, c'est simplement car je voulais utiliser Python pour étendre des commandes batch (.BAT).
Bonne journée
Michel Claveau
Laurent Pointal
Do Re Mi chel La Si Do wrote: ...zip pb de variable d'environnement entre .bat et .py ...
La réponse a déjà été donnée (héritage d'une copie des variables d'environnement par les processus fils, d'où impossibilité de modifier les variables d'environnement du process père).
J'ai été confronté un problème du même genre, et je l'ai résolu en utilisant un fichier .bat supplémentaire appelé via CALL. Ce fichier était créé par un script Python qui permet des manipulations nettement plus avancées que le shell de Microsoft
Adapté à ton exemple, ça donnerais:
1) ess.bat : echo off SET AA=AZERTY echo %AA% ess.py CALL essbis.bat echo %AA%
Note: ça peut aussi se faire avec des 'print >>...', mais faut penser à vider le essbis.bat au début de chaque ess.py.
A+
LP
Do Re Mi chel La Si Do wrote:
...zip pb de variable d'environnement entre .bat et .py ...
La réponse a déjà été donnée (héritage d'une copie des variables
d'environnement par les processus fils, d'où impossibilité de modifier les
variables d'environnement du process père).
J'ai été confronté un problème du même genre, et je l'ai résolu en utilisant
un fichier .bat supplémentaire appelé via CALL. Ce fichier était créé par
un script Python qui permet des manipulations nettement plus avancées que
le shell de Microsoft
Adapté à ton exemple, ça donnerais:
1) ess.bat :
echo off
SET AA=AZERTY
echo %AA%
ess.py
CALL essbis.bat
echo %AA%
Do Re Mi chel La Si Do wrote: ...zip pb de variable d'environnement entre .bat et .py ...
La réponse a déjà été donnée (héritage d'une copie des variables d'environnement par les processus fils, d'où impossibilité de modifier les variables d'environnement du process père).
J'ai été confronté un problème du même genre, et je l'ai résolu en utilisant un fichier .bat supplémentaire appelé via CALL. Ce fichier était créé par un script Python qui permet des manipulations nettement plus avancées que le shell de Microsoft
Adapté à ton exemple, ça donnerais:
1) ess.bat : echo off SET AA=AZERTY echo %AA% ess.py CALL essbis.bat echo %AA%
Note: ça peut aussi se faire avec des 'print >>...', mais faut penser à vider le essbis.bat au début de chaque ess.py.
A+
LP
Do Re Mi chel La Si Do
Bonsoir !
Merci du truc. Pour info, j'étais arrivé au même endroit que toi. Comme quoi, les grands esprits...
Voici la ligne de code Python que j'utilise : open("tempsub.bat","w").write("SET AA«CDErnSET BB345")
Le .write accolé fait gérer le close() par Python, et évite la création d'un objet fichier supplémentaire.
Et, tant qu'à faire, j'écris le script Python dans le fichier.Batch, avec les lignes précédées de ":: ", et find + ">" me permettant de le copier dans temp.py
@-salutations
Michel Claveau
Bonsoir !
Merci du truc. Pour info, j'étais arrivé au même endroit que toi. Comme
quoi, les grands esprits...
Voici la ligne de code Python que j'utilise :
open("tempsub.bat","w").write("SET AA«CDErnSET BB345")
Le .write accolé fait gérer le close() par Python, et évite la création d'un
objet fichier supplémentaire.
Et, tant qu'à faire, j'écris le script Python dans le fichier.Batch, avec
les lignes précédées de ":: ", et find + ">" me permettant de le copier
dans temp.py
Merci du truc. Pour info, j'étais arrivé au même endroit que toi. Comme quoi, les grands esprits...
Voici la ligne de code Python que j'utilise : open("tempsub.bat","w").write("SET AA«CDErnSET BB345")
Le .write accolé fait gérer le close() par Python, et évite la création d'un objet fichier supplémentaire.
Et, tant qu'à faire, j'écris le script Python dans le fichier.Batch, avec les lignes précédées de ":: ", et find + ">" me permettant de le copier dans temp.py
@-salutations
Michel Claveau
tiissa
Do Re Mi chel La Si Do wrote:
Voici la ligne de code Python que j'utilise : open("tempsub.bat","w").write("SET AA«CDErnSET BB345")
Le .write accolé fait gérer le close() par Python, et évite la création d'un objet fichier supplémentaire.
Ah ! ça ça m'intéresse. Je pensais (naïvement) qu'il créait quand même un objet temporaire qui serait disponible pour être recyclé dès la fin de la ligne.
Du coup, je pensais que ce genre d'écriture (que j'utilise parfois aussi) était juste une sorte de raccourci pour :
#### f=open("tempsub.bat","w") f.write("SET AA«CDErnSET BB345") f.close() del f # ferme f aussi mais on est pas a une ligne près ####
Y-a-t'il réellement une différence entre ton écriture sur une ligne et celle d'au dessus comme ton message le laisse à penser ? Ou voulais-tu dire que le close ne libère pas l'objet et que, sans faire de del, il reste à se balader ?
Do Re Mi chel La Si Do wrote:
Voici la ligne de code Python que j'utilise :
open("tempsub.bat","w").write("SET AA«CDErnSET BB345")
Le .write accolé fait gérer le close() par Python, et évite la création d'un
objet fichier supplémentaire.
Ah ! ça ça m'intéresse.
Je pensais (naïvement) qu'il créait quand même un objet temporaire qui
serait disponible pour être recyclé dès la fin de la ligne.
Du coup, je pensais que ce genre d'écriture (que j'utilise parfois
aussi) était juste une sorte de raccourci pour :
####
f=open("tempsub.bat","w")
f.write("SET AA«CDErnSET BB345")
f.close()
del f # ferme f aussi mais on est pas a une ligne près
####
Y-a-t'il réellement une différence entre ton écriture sur une ligne et
celle d'au dessus comme ton message le laisse à penser ?
Ou voulais-tu dire que le close ne libère pas l'objet et que, sans faire
de del, il reste à se balader ?
Voici la ligne de code Python que j'utilise : open("tempsub.bat","w").write("SET AA«CDErnSET BB345")
Le .write accolé fait gérer le close() par Python, et évite la création d'un objet fichier supplémentaire.
Ah ! ça ça m'intéresse. Je pensais (naïvement) qu'il créait quand même un objet temporaire qui serait disponible pour être recyclé dès la fin de la ligne.
Du coup, je pensais que ce genre d'écriture (que j'utilise parfois aussi) était juste une sorte de raccourci pour :
#### f=open("tempsub.bat","w") f.write("SET AA«CDErnSET BB345") f.close() del f # ferme f aussi mais on est pas a une ligne près ####
Y-a-t'il réellement une différence entre ton écriture sur une ligne et celle d'au dessus comme ton message le laisse à penser ? Ou voulais-tu dire que le close ne libère pas l'objet et que, sans faire de del, il reste à se balader ?
