Visiblement il y a des trucs à lire à ce sujet dans perlipc, mais je
n'ai pas trouvé à quel endroit, je m'y attaquerai demain (ça a l'air
d'un gros morceau).
Visiblement il y a des trucs à lire à ce sujet dans perlipc, mais je
n'ai pas trouvé à quel endroit, je m'y attaquerai demain (ça a l'air
d'un gros morceau).
Visiblement il y a des trucs à lire à ce sujet dans perlipc, mais je
n'ai pas trouvé à quel endroit, je m'y attaquerai demain (ça a l'air
d'un gros morceau).
Manuel Pégourié-Gonnard scripsit :Visiblement il y a des trucs à lire à ce sujet dans perlipc, mais je
n'ai pas trouvé à quel endroit, je m'y attaquerai demain (ça a l'air
d'un gros morceau).
Finalement j'ai trouvé, mais je n'ai pas l'impression que ça répond à ma
question. D'une part parce que ce qui y est décrit comme "safe pipe
open" correspond à la syntaxe de open à plus de trois argument depuis
Perl 5.8, d'autre part parce que ça semble toujours très centré sur
Unix :
Note that these operations are full Unix forks, which means they may
not be correctly implemented on alien systems.
J'avoue que le "may not" me laisse un peu sur ma faim pour savoir si en
pratique ça marche sur windows ou pas.
J'en appele donc à votre expérience et à votre sagesse... (Et je
prévois une question subsidiaire : s'il n'y a pas moyen de gérer des
pipes sans passer par un shell sous windows, quelles sont les bonnes
pratiques concernant l'utilisation de fichiers temporaires ?)
Manuel Pégourié-Gonnard scripsit :
Visiblement il y a des trucs à lire à ce sujet dans perlipc, mais je
n'ai pas trouvé à quel endroit, je m'y attaquerai demain (ça a l'air
d'un gros morceau).
Finalement j'ai trouvé, mais je n'ai pas l'impression que ça répond à ma
question. D'une part parce que ce qui y est décrit comme "safe pipe
open" correspond à la syntaxe de open à plus de trois argument depuis
Perl 5.8, d'autre part parce que ça semble toujours très centré sur
Unix :
Note that these operations are full Unix forks, which means they may
not be correctly implemented on alien systems.
J'avoue que le "may not" me laisse un peu sur ma faim pour savoir si en
pratique ça marche sur windows ou pas.
J'en appele donc à votre expérience et à votre sagesse... (Et je
prévois une question subsidiaire : s'il n'y a pas moyen de gérer des
pipes sans passer par un shell sous windows, quelles sont les bonnes
pratiques concernant l'utilisation de fichiers temporaires ?)
Manuel Pégourié-Gonnard scripsit :Visiblement il y a des trucs à lire à ce sujet dans perlipc, mais je
n'ai pas trouvé à quel endroit, je m'y attaquerai demain (ça a l'air
d'un gros morceau).
Finalement j'ai trouvé, mais je n'ai pas l'impression que ça répond à ma
question. D'une part parce que ce qui y est décrit comme "safe pipe
open" correspond à la syntaxe de open à plus de trois argument depuis
Perl 5.8, d'autre part parce que ça semble toujours très centré sur
Unix :
Note that these operations are full Unix forks, which means they may
not be correctly implemented on alien systems.
J'avoue que le "may not" me laisse un peu sur ma faim pour savoir si en
pratique ça marche sur windows ou pas.
J'en appele donc à votre expérience et à votre sagesse... (Et je
prévois une question subsidiaire : s'il n'y a pas moyen de gérer des
pipes sans passer par un shell sous windows, quelles sont les bonnes
pratiques concernant l'utilisation de fichiers temporaires ?)
A mon avis, il faut privilegier la securite: donc ecris des trucs qui soient
surs sous Unix... et apres, prevois des solutions de secours pour le reste.
A mon avis, il faut privilegier la securite: donc ecris des trucs qui soient
surs sous Unix... et apres, prevois des solutions de secours pour le reste.
A mon avis, il faut privilegier la securite: donc ecris des trucs qui soient
surs sous Unix... et apres, prevois des solutions de secours pour le reste.
system() existe, si je comprends bien, sous deux formes essentiellement
différentes du point de vue de la sécurité : celle qui fait
potentiellement appel à un shell (l'argument est un scalaire ou une liste
à un élément), et celle qui ne fait jamais appel à un shell (l'argument
est une liste à plus d'un élément, ou il y a un premier argument suivi
sans virgule par un deuxième qui est alors interpété comme une liste).
Lorsqu'on lance une commande externe, et qu'une partie de la ligne de
commande est d'origine mal contrôlée (entrée utilisateur), si l'on veut
être sûr de savoir ce qui se passe, il faut mieux, il me semble,
utiliser la deuxième forme.
Ma question est : y a-t-il la moindre raison de ne pas préférer cette
deuxième forme, dès lors qu'on n'a pas réellement besoin d'appeler un
shell ? Par exemple en matière de portabilité (il s'agit d'un script qui
doit tourner au moins sous Unix, Windows, et Cygwin).
Même question quand il s'agit d'ouvrir une commande avec un pipe vers son
entrée standard ou depuis sa sortie standard : peut-on toujours utiliser
la forme à plus de trois arguments sur les plateformes citées ? Dans
perldoc -f open, je lis :
The last example in each block shows the pipe as "list form",
which is not yet supported on all platforms. A good rule of
thumb is that if your platform has true "fork()" (in other
words, if your platform is UNIX) you can use the list form.
qui m'inquiète un peu, parce qu'il me semble que celà exclut windows.
system() existe, si je comprends bien, sous deux formes essentiellement
différentes du point de vue de la sécurité : celle qui fait
potentiellement appel à un shell (l'argument est un scalaire ou une liste
à un élément), et celle qui ne fait jamais appel à un shell (l'argument
est une liste à plus d'un élément, ou il y a un premier argument suivi
sans virgule par un deuxième qui est alors interpété comme une liste).
Lorsqu'on lance une commande externe, et qu'une partie de la ligne de
commande est d'origine mal contrôlée (entrée utilisateur), si l'on veut
être sûr de savoir ce qui se passe, il faut mieux, il me semble,
utiliser la deuxième forme.
Ma question est : y a-t-il la moindre raison de ne pas préférer cette
deuxième forme, dès lors qu'on n'a pas réellement besoin d'appeler un
shell ? Par exemple en matière de portabilité (il s'agit d'un script qui
doit tourner au moins sous Unix, Windows, et Cygwin).
Même question quand il s'agit d'ouvrir une commande avec un pipe vers son
entrée standard ou depuis sa sortie standard : peut-on toujours utiliser
la forme à plus de trois arguments sur les plateformes citées ? Dans
perldoc -f open, je lis :
The last example in each block shows the pipe as "list form",
which is not yet supported on all platforms. A good rule of
thumb is that if your platform has true "fork()" (in other
words, if your platform is UNIX) you can use the list form.
qui m'inquiète un peu, parce qu'il me semble que celà exclut windows.
system() existe, si je comprends bien, sous deux formes essentiellement
différentes du point de vue de la sécurité : celle qui fait
potentiellement appel à un shell (l'argument est un scalaire ou une liste
à un élément), et celle qui ne fait jamais appel à un shell (l'argument
est une liste à plus d'un élément, ou il y a un premier argument suivi
sans virgule par un deuxième qui est alors interpété comme une liste).
Lorsqu'on lance une commande externe, et qu'une partie de la ligne de
commande est d'origine mal contrôlée (entrée utilisateur), si l'on veut
être sûr de savoir ce qui se passe, il faut mieux, il me semble,
utiliser la deuxième forme.
Ma question est : y a-t-il la moindre raison de ne pas préférer cette
deuxième forme, dès lors qu'on n'a pas réellement besoin d'appeler un
shell ? Par exemple en matière de portabilité (il s'agit d'un script qui
doit tourner au moins sous Unix, Windows, et Cygwin).
Même question quand il s'agit d'ouvrir une commande avec un pipe vers son
entrée standard ou depuis sa sortie standard : peut-on toujours utiliser
la forme à plus de trois arguments sur les plateformes citées ? Dans
perldoc -f open, je lis :
The last example in each block shows the pipe as "list form",
which is not yet supported on all platforms. A good rule of
thumb is that if your platform has true "fork()" (in other
words, if your platform is UNIX) you can use the list form.
qui m'inquiète un peu, parce qu'il me semble que celà exclut windows.
In article <hbemjm$10be$, Marc Espie wrote:A mon avis, il faut privilegier la securite: donc ecris des trucs qui soient
surs sous Unix... et apres, prevois des solutions de secours pour le reste.
Post-scriptum sur la portabilite.
Ton attitude est exactement ce qu'il faut eviter, en fait (mais c'est un
travers extremement frequent).
- la portabilite universelle n'existe pas. Il y aura toujours des systemes
avec des contraintes a la con, sans filesystem, avec des entiers bizarres,
avec pas beaucoup de memoire... faire de la portabilite sur tout et
n'importe quoi, ca ne sert a rien. Donc on se fixe un "perimetre de systemes"
sur lesquels ca doit tourner, et tant pis pour le reste. On pourra
eventuellement revisiter la decision plus tard, d'autant plus facilement
que le code sera clair.
Nan, la bonne facon de faire portable, c'est reellement de mettre les mains
dans le cambouis et de porter son code sur le systeme cible... ou de
s'arreter avant, et de collaborer avec quelqu'un qui bosse sur le systeme
cible, et qui pourra pointer du doigt les vrais soucis. ;-)
In article <hbemjm$10be$1@saria.nerim.net>, Marc Espie <espie@nerim.net> wrote:
A mon avis, il faut privilegier la securite: donc ecris des trucs qui soient
surs sous Unix... et apres, prevois des solutions de secours pour le reste.
Post-scriptum sur la portabilite.
Ton attitude est exactement ce qu'il faut eviter, en fait (mais c'est un
travers extremement frequent).
- la portabilite universelle n'existe pas. Il y aura toujours des systemes
avec des contraintes a la con, sans filesystem, avec des entiers bizarres,
avec pas beaucoup de memoire... faire de la portabilite sur tout et
n'importe quoi, ca ne sert a rien. Donc on se fixe un "perimetre de systemes"
sur lesquels ca doit tourner, et tant pis pour le reste. On pourra
eventuellement revisiter la decision plus tard, d'autant plus facilement
que le code sera clair.
Nan, la bonne facon de faire portable, c'est reellement de mettre les mains
dans le cambouis et de porter son code sur le systeme cible... ou de
s'arreter avant, et de collaborer avec quelqu'un qui bosse sur le systeme
cible, et qui pourra pointer du doigt les vrais soucis. ;-)
In article <hbemjm$10be$, Marc Espie wrote:A mon avis, il faut privilegier la securite: donc ecris des trucs qui soient
surs sous Unix... et apres, prevois des solutions de secours pour le reste.
Post-scriptum sur la portabilite.
Ton attitude est exactement ce qu'il faut eviter, en fait (mais c'est un
travers extremement frequent).
- la portabilite universelle n'existe pas. Il y aura toujours des systemes
avec des contraintes a la con, sans filesystem, avec des entiers bizarres,
avec pas beaucoup de memoire... faire de la portabilite sur tout et
n'importe quoi, ca ne sert a rien. Donc on se fixe un "perimetre de systemes"
sur lesquels ca doit tourner, et tant pis pour le reste. On pourra
eventuellement revisiter la decision plus tard, d'autant plus facilement
que le code sera clair.
Nan, la bonne facon de faire portable, c'est reellement de mettre les mains
dans le cambouis et de porter son code sur le systeme cible... ou de
s'arreter avant, et de collaborer avec quelqu'un qui bosse sur le systeme
cible, et qui pourra pointer du doigt les vrais soucis. ;-)
A mon avis, il faut privilegier la securite: donc ecris des trucs qui
soient surs sous Unix... et apres, prevois des solutions de secours
pour le reste.
(par exemple, tu peux assez facilement resynthetiser le system a 1 argument
a partir du systeme a plusieurs).
Mais oui, effectivement, tout ce qui est fork ne tourne pas sous
windows,
et il faut d'autres solutions, essentiellement a base de
multi-thread pour les machins internes, et a base de "system" simple
pour le reste.
Par exemple, tu peux jeter un oeil a DBI::Proxy, qui contient des options
pour se lancer en multi-threade, explicitement pour que ca serve a quelque
chose sous windows...
Si tu t'interesses reellement a la portabilite de tes scripts, au final, tu
n'as pas le choix, tu vas etre bon pour installer perl sur cette merde de
windows et pour faire des essais...
Concernant les fichiers temporaires, il y a File::Temp, qui contient
entres autres un equivalent de mkstemp, qui est la bonne solution sur
les Unix (creation de temporaire sans race condition) et plein
d'autres cochonneries.
Je t'avouerais que j'aimerais bien que ca soit nettoye un jour (si je trouve
le temps, je ferai un File::Temp::Light), car il y a a boire, a manger, et
a se pisser dessus dans File::Temp. Il n'y a qu'a voir la liste des
dependances qu'il ramene, c'est programme a la physicien, ce truc... au
point que ca m'est deja arrive d'en extraire le seul bout utile (mkstemp)
histoire d'avoir un script qui ne passe pas 3 secondes a charger tous les
trucs qui ne vont pas servir...
A mon avis, il faut privilegier la securite: donc ecris des trucs qui
soient surs sous Unix... et apres, prevois des solutions de secours
pour le reste.
(par exemple, tu peux assez facilement resynthetiser le system a 1 argument
a partir du systeme a plusieurs).
Mais oui, effectivement, tout ce qui est fork ne tourne pas sous
windows,
et il faut d'autres solutions, essentiellement a base de
multi-thread pour les machins internes, et a base de "system" simple
pour le reste.
Par exemple, tu peux jeter un oeil a DBI::Proxy, qui contient des options
pour se lancer en multi-threade, explicitement pour que ca serve a quelque
chose sous windows...
Si tu t'interesses reellement a la portabilite de tes scripts, au final, tu
n'as pas le choix, tu vas etre bon pour installer perl sur cette merde de
windows et pour faire des essais...
Concernant les fichiers temporaires, il y a File::Temp, qui contient
entres autres un equivalent de mkstemp, qui est la bonne solution sur
les Unix (creation de temporaire sans race condition) et plein
d'autres cochonneries.
Je t'avouerais que j'aimerais bien que ca soit nettoye un jour (si je trouve
le temps, je ferai un File::Temp::Light), car il y a a boire, a manger, et
a se pisser dessus dans File::Temp. Il n'y a qu'a voir la liste des
dependances qu'il ramene, c'est programme a la physicien, ce truc... au
point que ca m'est deja arrive d'en extraire le seul bout utile (mkstemp)
histoire d'avoir un script qui ne passe pas 3 secondes a charger tous les
trucs qui ne vont pas servir...
A mon avis, il faut privilegier la securite: donc ecris des trucs qui
soient surs sous Unix... et apres, prevois des solutions de secours
pour le reste.
(par exemple, tu peux assez facilement resynthetiser le system a 1 argument
a partir du systeme a plusieurs).
Mais oui, effectivement, tout ce qui est fork ne tourne pas sous
windows,
et il faut d'autres solutions, essentiellement a base de
multi-thread pour les machins internes, et a base de "system" simple
pour le reste.
Par exemple, tu peux jeter un oeil a DBI::Proxy, qui contient des options
pour se lancer en multi-threade, explicitement pour que ca serve a quelque
chose sous windows...
Si tu t'interesses reellement a la portabilite de tes scripts, au final, tu
n'as pas le choix, tu vas etre bon pour installer perl sur cette merde de
windows et pour faire des essais...
Concernant les fichiers temporaires, il y a File::Temp, qui contient
entres autres un equivalent de mkstemp, qui est la bonne solution sur
les Unix (creation de temporaire sans race condition) et plein
d'autres cochonneries.
Je t'avouerais que j'aimerais bien que ca soit nettoye un jour (si je trouve
le temps, je ferai un File::Temp::Light), car il y a a boire, a manger, et
a se pisser dessus dans File::Temp. Il n'y a qu'a voir la liste des
dependances qu'il ramene, c'est programme a la physicien, ce truc... au
point que ca m'est deja arrive d'en extraire le seul bout utile (mkstemp)
histoire d'avoir un script qui ne passe pas 3 secondes a charger tous les
trucs qui ne vont pas servir...
Post-scriptum sur la portabilite.
Ton attitude est exactement ce qu'il faut eviter, en fait (mais c'est un
travers extremement frequent).
Post-scriptum sur la portabilite.
Ton attitude est exactement ce qu'il faut eviter, en fait (mais c'est un
travers extremement frequent).
Post-scriptum sur la portabilite.
Ton attitude est exactement ce qu'il faut eviter, en fait (mais c'est un
travers extremement frequent).
C'est la dernière syntaxe qu'il faut privilégier (celle avec un
premier élément sans virgule derrière) pour être sûr de ne pas passer
par un shell (ou un pseudo-shell).
Ma question est : y a-t-il la moindre raison de ne pas préférer cette
deuxième forme, dès lors qu'on n'a pas réellement besoin d'appeler un
shell ? Par exemple en matière de portabilité (il s'agit d'un script qui
doit tourner au moins sous Unix, Windows, et Cygwin).
Non.
En fait, sous Windows et d'autres OS, le véritable souci n'est ni
system() ni open() mais fork(). Évidemment, puisque system() et open()
font appel à fork(), on récupère les mêmes soucis qu'avec fork() mais
c'est un effet de bord.
En fait, sous Windows, le fork() est émulé en utilisant du
multi-threading. Pour en savoir plus sur les limitations de cette
émulation, il faut commencer par lire 'perlfork'. Il y a une solution
pour émuler les tubes (pipes).
L'autre solution sous Windows consiste à ne pas utiliser fork() et à
faire appel aux modules Win32 qui permettent de créer de vrais
processus externes. En revanche, la communication entre les processus
ne pourra pas reposer sur des tubes....
C'est la dernière syntaxe qu'il faut privilégier (celle avec un
premier élément sans virgule derrière) pour être sûr de ne pas passer
par un shell (ou un pseudo-shell).
Ma question est : y a-t-il la moindre raison de ne pas préférer cette
deuxième forme, dès lors qu'on n'a pas réellement besoin d'appeler un
shell ? Par exemple en matière de portabilité (il s'agit d'un script qui
doit tourner au moins sous Unix, Windows, et Cygwin).
Non.
En fait, sous Windows et d'autres OS, le véritable souci n'est ni
system() ni open() mais fork(). Évidemment, puisque system() et open()
font appel à fork(), on récupère les mêmes soucis qu'avec fork() mais
c'est un effet de bord.
En fait, sous Windows, le fork() est émulé en utilisant du
multi-threading. Pour en savoir plus sur les limitations de cette
émulation, il faut commencer par lire 'perlfork'. Il y a une solution
pour émuler les tubes (pipes).
L'autre solution sous Windows consiste à ne pas utiliser fork() et à
faire appel aux modules Win32 qui permettent de créer de vrais
processus externes. En revanche, la communication entre les processus
ne pourra pas reposer sur des tubes....
C'est la dernière syntaxe qu'il faut privilégier (celle avec un
premier élément sans virgule derrière) pour être sûr de ne pas passer
par un shell (ou un pseudo-shell).
Ma question est : y a-t-il la moindre raison de ne pas préférer cette
deuxième forme, dès lors qu'on n'a pas réellement besoin d'appeler un
shell ? Par exemple en matière de portabilité (il s'agit d'un script qui
doit tourner au moins sous Unix, Windows, et Cygwin).
Non.
En fait, sous Windows et d'autres OS, le véritable souci n'est ni
system() ni open() mais fork(). Évidemment, puisque system() et open()
font appel à fork(), on récupère les mêmes soucis qu'avec fork() mais
c'est un effet de bord.
En fait, sous Windows, le fork() est émulé en utilisant du
multi-threading. Pour en savoir plus sur les limitations de cette
émulation, il faut commencer par lire 'perlfork'. Il y a une solution
pour émuler les tubes (pipes).
L'autre solution sous Windows consiste à ne pas utiliser fork() et à
faire appel aux modules Win32 qui permettent de créer de vrais
processus externes. En revanche, la communication entre les processus
ne pourra pas reposer sur des tubes....
Noté, mais ça me paraît gênant de ne pas avoir de tubes.
Noté, mais ça me paraît gênant de ne pas avoir de tubes.
Noté, mais ça me paraît gênant de ne pas avoir de tubes.
En fait, sous Windows, le fork() est émulé en utilisant du
multi-threading. Pour en savoir plus sur les limitations de cette
émulation, il faut commencer par lire 'perlfork'. Il y a une solution
pour émuler les tubes (pipes).
En fait, sous Windows, le fork() est émulé en utilisant du
multi-threading. Pour en savoir plus sur les limitations de cette
émulation, il faut commencer par lire 'perlfork'. Il y a une solution
pour émuler les tubes (pipes).
En fait, sous Windows, le fork() est émulé en utilisant du
multi-threading. Pour en savoir plus sur les limitations de cette
émulation, il faut commencer par lire 'perlfork'. Il y a une solution
pour émuler les tubes (pipes).