Quelle est la meilleure solution pour emuler une série de pipes Unix sous Windows ?
6 réponses
pioche encore
Bonjour,
Mon probl=E8me est le suivant :
J'=E9tudie actuellement un produit de traitement de gros flux de
donn=E9es qui pos=E8de une impl=E9mentation pour Unix et Windows.
La version Unix est principalement d=E9velopp=E9e en Perl et fait
transiter le dit flux par diff=E9rents filtres au moyen de pipes
syst=E8me (rien que du traditionnel quoi).
La version windows est d=E9velopp=E9e en BZZZZ (peu importe mais c'est
bas=E9 sur l'API WIN32) et fait transiter le flux par des fichiers
temporaires trait=E9s par des appels syst=E8mes aux filtres (des .exe).
Le pb est que l'ouverture et la fermeture s=E9quentielle des fichiers
rend la vesion Windows est plus lente et plus gourmande en espace
de stockage (un r=E9pertoire par phase de traitement).
Or si je veux adapter le processus Unix =E0 la version Windows il me
faut r=E9soudre le probl=E8me de la gestion des pipes qui me semble t'il
n'est pas asynchrone en mode 'commande' (le fichier stdin est lu
int=E9gralement avant de produire sur stdout).
D'ou ma question : est il coh=E9rent d'utiliser les pipes sous un batch
(du type cmd.exe/dos-oui-je-sais-ca-n-existe-plus)
sous Windows comme on le ferait dans un shell Unix ?
Y'a t'il une alternative aux pipes avec Perl sous Windows ?
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
Remi THOMAS
Bonjour, Mon problème est le suivant : J'étudie actuellement un produit de traitement de gros flux de données qui posède une implémentation pour Unix et Windows. La version Unix est principalement développée en Perl et fait transiter le dit flux par différents filtres au moyen de pipes système (rien que du traditionnel quoi). La version windows est développée en BZZZZ (peu importe mais c'est basé sur l'API WIN32) et fait transiter le flux par des fichiers temporaires traités par des appels systèmes aux filtres (des .exe). Le pb est que l'ouverture et la fermeture séquentielle des fichiers rend la vesion Windows est plus lente et plus gourmande en espace de stockage (un répertoire par phase de traitement). Or si je veux adapter le processus Unix à la version Windows il me faut résoudre le problème de la gestion des pipes qui me semble t'il n'est pas asynchrone en mode 'commande' (le fichier stdin est lu intégralement avant de produire sur stdout). D'ou ma question : est il cohérent d'utiliser les pipes sous un batch (du type cmd.exe/dos-oui-je-sais-ca-n-existe-plus) sous Windows comme on le ferait dans un shell Unix ? Y'a t'il une alternative aux pipes avec Perl sous Windows ?
suivi sur fr.comp.lang.perl
Bonjour, Je te propose de jeter un oeil au PowerShell http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
pas mal d'info ici: http://channel9.msdn.com/wiki/default.aspx/Channel9.WindowsPowerShellWiki
Rémi
Bonjour,
Mon problème est le suivant :
J'étudie actuellement un produit de traitement de gros flux de
données qui posède une implémentation pour Unix et Windows.
La version Unix est principalement développée en Perl et fait
transiter le dit flux par différents filtres au moyen de pipes
système (rien que du traditionnel quoi).
La version windows est développée en BZZZZ (peu importe mais c'est
basé sur l'API WIN32) et fait transiter le flux par des fichiers
temporaires traités par des appels systèmes aux filtres (des .exe).
Le pb est que l'ouverture et la fermeture séquentielle des fichiers
rend la vesion Windows est plus lente et plus gourmande en espace
de stockage (un répertoire par phase de traitement).
Or si je veux adapter le processus Unix à la version Windows il me
faut résoudre le problème de la gestion des pipes qui me semble t'il
n'est pas asynchrone en mode 'commande' (le fichier stdin est lu
intégralement avant de produire sur stdout).
D'ou ma question : est il cohérent d'utiliser les pipes sous un batch
(du type cmd.exe/dos-oui-je-sais-ca-n-existe-plus)
sous Windows comme on le ferait dans un shell Unix ?
Y'a t'il une alternative aux pipes avec Perl sous Windows ?
suivi sur fr.comp.lang.perl
Bonjour,
Je te propose de jeter un oeil au PowerShell
http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
pas mal d'info ici:
http://channel9.msdn.com/wiki/default.aspx/Channel9.WindowsPowerShellWiki
Bonjour, Mon problème est le suivant : J'étudie actuellement un produit de traitement de gros flux de données qui posède une implémentation pour Unix et Windows. La version Unix est principalement développée en Perl et fait transiter le dit flux par différents filtres au moyen de pipes système (rien que du traditionnel quoi). La version windows est développée en BZZZZ (peu importe mais c'est basé sur l'API WIN32) et fait transiter le flux par des fichiers temporaires traités par des appels systèmes aux filtres (des .exe). Le pb est que l'ouverture et la fermeture séquentielle des fichiers rend la vesion Windows est plus lente et plus gourmande en espace de stockage (un répertoire par phase de traitement). Or si je veux adapter le processus Unix à la version Windows il me faut résoudre le problème de la gestion des pipes qui me semble t'il n'est pas asynchrone en mode 'commande' (le fichier stdin est lu intégralement avant de produire sur stdout). D'ou ma question : est il cohérent d'utiliser les pipes sous un batch (du type cmd.exe/dos-oui-je-sais-ca-n-existe-plus) sous Windows comme on le ferait dans un shell Unix ? Y'a t'il une alternative aux pipes avec Perl sous Windows ?
suivi sur fr.comp.lang.perl
Bonjour, Je te propose de jeter un oeil au PowerShell http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
pas mal d'info ici: http://channel9.msdn.com/wiki/default.aspx/Channel9.WindowsPowerShellWiki
Rémi
pioche encore
Bonjour, Mon problème est le suivant : J'étudie actuellement un produit de traitement de gros flux de données qui posède une implémentation pour Unix et Windows. La version Unix est principalement développée en Perl et fait transiter le dit flux par différents filtres au moyen de pipes système (rien que du traditionnel quoi). La version windows est développée en BZZZZ (peu importe mais c'est basé sur l'API WIN32) et fait transiter le flux par des fichiers temporaires traités par des appels systèmes aux filtres (des .exe). Le pb est que l'ouverture et la fermeture séquentielle des fichiers rend la vesion Windows est plus lente et plus gourmande en espace de stockage (un répertoire par phase de traitement). Or si je veux adapter le processus Unix à la version Windows il me faut résoudre le problème de la gestion des pipes qui me semble t' il n'est pas asynchrone en mode 'commande' (le fichier stdin est lu intégralement avant de produire sur stdout). D'ou ma question : est il cohérent d'utiliser les pipes sous un batch (du type cmd.exe/dos-oui-je-sais-ca-n-existe-plus) sous Windows comme on le ferait dans un shell Unix ? Y'a t'il une alternative aux pipes avec Perl sous Windows ?
suivi sur fr.comp.lang.perl
Bonjour, Je te propose de jeter un oeil au PowerShell http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
pas mal d'info ici: http://channel9.msdn.com/wiki/default.aspx/Channel9.WindowsPowerShellWiki
Merci Rémi, très intéressant ... mais le pré-requis c'est Perl. Techniquement je ne pense pas que PowerShell soit portable sur Unix ou alors j'ai pas tout compris c'est possible. Mais quand bien même il le serait je ne me vois pas ré écrire quelques milliers de lignes de code pour régler le problème. En attendant je mets ça dans mes favoris pour plus tard.
A+ P.
Bonjour,
Mon problème est le suivant :
J'étudie actuellement un produit de traitement de gros flux de
données qui posède une implémentation pour Unix et Windows.
La version Unix est principalement développée en Perl et fait
transiter le dit flux par différents filtres au moyen de pipes
système (rien que du traditionnel quoi).
La version windows est développée en BZZZZ (peu importe mais c'est
basé sur l'API WIN32) et fait transiter le flux par des fichiers
temporaires traités par des appels systèmes aux filtres (des .exe).
Le pb est que l'ouverture et la fermeture séquentielle des fichiers
rend la vesion Windows est plus lente et plus gourmande en espace
de stockage (un répertoire par phase de traitement).
Or si je veux adapter le processus Unix à la version Windows il me
faut résoudre le problème de la gestion des pipes qui me semble t' il
n'est pas asynchrone en mode 'commande' (le fichier stdin est lu
intégralement avant de produire sur stdout).
D'ou ma question : est il cohérent d'utiliser les pipes sous un batch
(du type cmd.exe/dos-oui-je-sais-ca-n-existe-plus)
sous Windows comme on le ferait dans un shell Unix ?
Y'a t'il une alternative aux pipes avec Perl sous Windows ?
suivi sur fr.comp.lang.perl
Bonjour,
Je te propose de jeter un oeil au PowerShell
http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
pas mal d'info ici:
http://channel9.msdn.com/wiki/default.aspx/Channel9.WindowsPowerShellWiki
Merci Rémi, très intéressant ...
mais le pré-requis c'est Perl. Techniquement je ne pense pas que
PowerShell soit portable sur Unix ou alors j'ai pas tout compris c'est
possible. Mais quand bien même il le serait je ne me vois pas ré
écrire quelques milliers de lignes de code pour régler le problème.
En attendant je mets ça dans mes favoris pour plus tard.
Bonjour, Mon problème est le suivant : J'étudie actuellement un produit de traitement de gros flux de données qui posède une implémentation pour Unix et Windows. La version Unix est principalement développée en Perl et fait transiter le dit flux par différents filtres au moyen de pipes système (rien que du traditionnel quoi). La version windows est développée en BZZZZ (peu importe mais c'est basé sur l'API WIN32) et fait transiter le flux par des fichiers temporaires traités par des appels systèmes aux filtres (des .exe). Le pb est que l'ouverture et la fermeture séquentielle des fichiers rend la vesion Windows est plus lente et plus gourmande en espace de stockage (un répertoire par phase de traitement). Or si je veux adapter le processus Unix à la version Windows il me faut résoudre le problème de la gestion des pipes qui me semble t' il n'est pas asynchrone en mode 'commande' (le fichier stdin est lu intégralement avant de produire sur stdout). D'ou ma question : est il cohérent d'utiliser les pipes sous un batch (du type cmd.exe/dos-oui-je-sais-ca-n-existe-plus) sous Windows comme on le ferait dans un shell Unix ? Y'a t'il une alternative aux pipes avec Perl sous Windows ?
suivi sur fr.comp.lang.perl
Bonjour, Je te propose de jeter un oeil au PowerShell http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
pas mal d'info ici: http://channel9.msdn.com/wiki/default.aspx/Channel9.WindowsPowerShellWiki
Merci Rémi, très intéressant ... mais le pré-requis c'est Perl. Techniquement je ne pense pas que PowerShell soit portable sur Unix ou alors j'ai pas tout compris c'est possible. Mais quand bien même il le serait je ne me vois pas ré écrire quelques milliers de lignes de code pour régler le problème. En attendant je mets ça dans mes favoris pour plus tard.
A+ P.
pioche encore
Bonjour, Mon problème est le suivant : J'étudie actuellement un produit de traitement de gros flux de données qui posède une implémentation pour Unix et Windows. La version Unix est principalement développée en Perl et fait transiter le dit flux par différents filtres au moyen de pipes système (rien que du traditionnel quoi). La version windows est développée en BZZZZ (peu importe mais c'est basé sur l'API WIN32) et fait transiter le flux par des fichiers temporaires traités par des appels systèmes aux filtres (des .exe). Le pb est que l'ouverture et la fermeture séquentielle des fichiers rend la vesion Windows est plus lente et plus gourmande en espace de stockage (un répertoire par phase de traitement). Or si je veux adapter le processus Unix à la version Windows il me faut résoudre le problème de la gestion des pipes qui me semble t' il n'est pas asynchrone en mode 'commande' (le fichier stdin est lu intégralement avant de produire sur stdout). D'ou ma question : est il cohérent d'utiliser les pipes sous un batch (du type cmd.exe/dos-oui-je-sais-ca-n-existe-plus) sous Windows comme on le ferait dans un shell Unix ? Y'a t'il une alternative aux pipes avec Perl sous Windows ?
suivi sur fr.comp.lang.perl
Bonjour, Je te propose de jeter un oeil au PowerShell http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
pas mal d'info ici: http://channel9.msdn.com/wiki/default.aspx/Channel9.WindowsPowerShellWiki
Merci Rémi, très intéressant ... mais le pré-requis c'est Perl. Techniquement je ne pense pas que PowerShell soit portable sur Unix ou alors j'ai pas tout compris c'est possible. Mais quand bien même il le serait je ne me vois pas ré écrire quelques milliers de lignes de code pour régler le problème. En attendant je mets ça dans mes favoris pour plus tard.
A+ P.
Bonjour,
Mon problème est le suivant :
J'étudie actuellement un produit de traitement de gros flux de
données qui posède une implémentation pour Unix et Windows.
La version Unix est principalement développée en Perl et fait
transiter le dit flux par différents filtres au moyen de pipes
système (rien que du traditionnel quoi).
La version windows est développée en BZZZZ (peu importe mais c'est
basé sur l'API WIN32) et fait transiter le flux par des fichiers
temporaires traités par des appels systèmes aux filtres (des .exe).
Le pb est que l'ouverture et la fermeture séquentielle des fichiers
rend la vesion Windows est plus lente et plus gourmande en espace
de stockage (un répertoire par phase de traitement).
Or si je veux adapter le processus Unix à la version Windows il me
faut résoudre le problème de la gestion des pipes qui me semble t' il
n'est pas asynchrone en mode 'commande' (le fichier stdin est lu
intégralement avant de produire sur stdout).
D'ou ma question : est il cohérent d'utiliser les pipes sous un batch
(du type cmd.exe/dos-oui-je-sais-ca-n-existe-plus)
sous Windows comme on le ferait dans un shell Unix ?
Y'a t'il une alternative aux pipes avec Perl sous Windows ?
suivi sur fr.comp.lang.perl
Bonjour,
Je te propose de jeter un oeil au PowerShell
http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
pas mal d'info ici:
http://channel9.msdn.com/wiki/default.aspx/Channel9.WindowsPowerShellWiki
Merci Rémi, très intéressant ...
mais le pré-requis c'est Perl. Techniquement je ne pense pas que
PowerShell soit portable sur Unix ou alors j'ai pas tout compris c'est
possible. Mais quand bien même il le serait je ne me vois pas ré
écrire quelques milliers de lignes de code pour régler le problème.
En attendant je mets ça dans mes favoris pour plus tard.
Bonjour, Mon problème est le suivant : J'étudie actuellement un produit de traitement de gros flux de données qui posède une implémentation pour Unix et Windows. La version Unix est principalement développée en Perl et fait transiter le dit flux par différents filtres au moyen de pipes système (rien que du traditionnel quoi). La version windows est développée en BZZZZ (peu importe mais c'est basé sur l'API WIN32) et fait transiter le flux par des fichiers temporaires traités par des appels systèmes aux filtres (des .exe). Le pb est que l'ouverture et la fermeture séquentielle des fichiers rend la vesion Windows est plus lente et plus gourmande en espace de stockage (un répertoire par phase de traitement). Or si je veux adapter le processus Unix à la version Windows il me faut résoudre le problème de la gestion des pipes qui me semble t' il n'est pas asynchrone en mode 'commande' (le fichier stdin est lu intégralement avant de produire sur stdout). D'ou ma question : est il cohérent d'utiliser les pipes sous un batch (du type cmd.exe/dos-oui-je-sais-ca-n-existe-plus) sous Windows comme on le ferait dans un shell Unix ? Y'a t'il une alternative aux pipes avec Perl sous Windows ?
suivi sur fr.comp.lang.perl
Bonjour, Je te propose de jeter un oeil au PowerShell http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
pas mal d'info ici: http://channel9.msdn.com/wiki/default.aspx/Channel9.WindowsPowerShellWiki
Merci Rémi, très intéressant ... mais le pré-requis c'est Perl. Techniquement je ne pense pas que PowerShell soit portable sur Unix ou alors j'ai pas tout compris c'est possible. Mais quand bien même il le serait je ne me vois pas ré écrire quelques milliers de lignes de code pour régler le problème. En attendant je mets ça dans mes favoris pour plus tard.
A+ P.
Emmanuel Florac
Le Wed, 03 Jan 2007 08:25:23 -0800, pioche encore a écrit :
Y'a t'il une alternative aux pipes avec Perl sous Windows ?
peut-être utiliser un environnement Unix pour Windows, comme Microsoft SFU , Cygwin ou MinGW? En plus ça te permettrait d'utiliser aussi les outils Unix standards comme tr, cat, grep, uniq, sort etc.
-- A thing of beauty is a joy forever. J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert! Marcel Bénabou.
Le Wed, 03 Jan 2007 08:25:23 -0800, pioche encore a écrit :
Y'a t'il une alternative aux pipes avec Perl sous Windows ?
peut-être utiliser un environnement Unix pour Windows, comme Microsoft
SFU , Cygwin ou MinGW? En plus ça te permettrait d'utiliser aussi les
outils Unix standards comme tr, cat, grep, uniq, sort etc.
--
A thing of beauty is a joy forever.
J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert!
Marcel Bénabou.
Le Wed, 03 Jan 2007 08:25:23 -0800, pioche encore a écrit :
Y'a t'il une alternative aux pipes avec Perl sous Windows ?
peut-être utiliser un environnement Unix pour Windows, comme Microsoft SFU , Cygwin ou MinGW? En plus ça te permettrait d'utiliser aussi les outils Unix standards comme tr, cat, grep, uniq, sort etc.
-- A thing of beauty is a joy forever. J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert! Marcel Bénabou.
pioche encore
Y'a t'il une alternative aux pipes avec Perl sous Windows ?
peut-être utiliser un environnement Unix pour Windows, comme Microsoft SFU , Cygwin ou MinGW? En plus ça te permettrait d'utiliser aussi les outils Unix standards comme tr, cat, grep, uniq, sort etc.
Ouiménon. J'aime bien l'environnement Cygwin c'est impressionant quand on voit tout ce que cet émulateur peu faire. Mais je ne peux pas imposer ça aux clients. Finalement je crois que la solution qui a éte proposée plus haut de gérer ça avec une véritable gestion de processus avec threads ipc ou sockets asynchrone etc. C'est pas gagné mais bon il faut le faire.
Y'a t'il une alternative aux pipes avec Perl sous Windows ?
peut-être utiliser un environnement Unix pour Windows, comme Microsoft
SFU , Cygwin ou MinGW? En plus ça te permettrait d'utiliser aussi les
outils Unix standards comme tr, cat, grep, uniq, sort etc.
Ouiménon.
J'aime bien l'environnement Cygwin c'est impressionant quand on voit
tout ce que cet émulateur peu faire. Mais je ne peux pas imposer ça
aux clients.
Finalement je crois que la solution qui a éte proposée plus haut de
gérer ça avec une véritable gestion de processus avec threads ipc ou
sockets asynchrone etc. C'est pas gagné mais bon il faut le faire.
Y'a t'il une alternative aux pipes avec Perl sous Windows ?
peut-être utiliser un environnement Unix pour Windows, comme Microsoft SFU , Cygwin ou MinGW? En plus ça te permettrait d'utiliser aussi les outils Unix standards comme tr, cat, grep, uniq, sort etc.
Ouiménon. J'aime bien l'environnement Cygwin c'est impressionant quand on voit tout ce que cet émulateur peu faire. Mais je ne peux pas imposer ça aux clients. Finalement je crois que la solution qui a éte proposée plus haut de gérer ça avec une véritable gestion de processus avec threads ipc ou sockets asynchrone etc. C'est pas gagné mais bon il faut le faire.
Emmanuel Florac
Le Thu, 04 Jan 2007 06:52:39 -0800, pioche encore a écrit :
J'aime bien l'environnement Cygwin c'est impressionant quand on voit tout ce que cet émulateur peu faire. Mais je ne peux pas imposer ça aux clients.
mingw ne fait qu'une poignée de Mo si tu ne veux pas installer Cygwin.
-- Le commissaire : Comment vous appelez-vous? Garance : Moi je ne m'appelle jamais, je suis toujours là. J'ai pas besoin de m'appeler. Mais les autres m'appellent Garance, si ça peut vous intéresser. Prévert,"les enfants du Paradis".
Le Thu, 04 Jan 2007 06:52:39 -0800, pioche encore a écrit :
J'aime bien l'environnement Cygwin c'est impressionant quand on voit
tout ce que cet émulateur peu faire. Mais je ne peux pas imposer ça
aux clients.
mingw ne fait qu'une poignée de Mo si tu ne veux pas installer Cygwin.
--
Le commissaire : Comment vous appelez-vous?
Garance : Moi je ne m'appelle jamais, je suis toujours là. J'ai pas
besoin de m'appeler. Mais les autres m'appellent Garance, si ça peut
vous intéresser.
Prévert,"les enfants du Paradis".
Le Thu, 04 Jan 2007 06:52:39 -0800, pioche encore a écrit :
J'aime bien l'environnement Cygwin c'est impressionant quand on voit tout ce que cet émulateur peu faire. Mais je ne peux pas imposer ça aux clients.
mingw ne fait qu'une poignée de Mo si tu ne veux pas installer Cygwin.
-- Le commissaire : Comment vous appelez-vous? Garance : Moi je ne m'appelle jamais, je suis toujours là. J'ai pas besoin de m'appeler. Mais les autres m'appellent Garance, si ça peut vous intéresser. Prévert,"les enfants du Paradis".
