Ma "maîtrise" de SED avance bien, et ouvre des tas de solutions
intéressantes...
Je reviens avec un nouveau demi-problème, survenu en traitant des listes de
fichiers. Demi parce que ça fonctionne, mais lourdement...
Donc le contexte est la transformation de listes de fichiers en règles pour
un makefile, dans une session MS-DOS sous Win2000, avec la version
appropriée de SED.
Donc au shell près, c'est du pur SED.
J'ai ces deux opérations pour filtrer la liste:
...
type List0.work | sed.exe -e '/.src$/d' > List1.work
type List1.work | sed.exe -e '/\\--/d' > List2.work
...
La première élimine donc les lignes avec fichiers en *.src, la seconde
celles avec fichiers préfixés par deux tirets (le backslash servant ici de
séparateur de répertoires, comme vous le savez).
Ces deux règles opèrent sur la même liste d'une dizaine de lignes. Or si la
première est instantanée, la seconde met 5 à 6 secondes à s'exécuter.
J'ai pu vérifier que c'est la combinaison \\- qui provoque le phénomène, pas
l'absence d'ancrage dans la seconde règle.
Avez vous une explication liée aux mécanismes internes de SED ? Je n'ai rien
trouvé dans les tutos et bonnes et mauvaises pratiques... à part
l'utilisation du DOS, je sais :o)
Merci, cordialement,
--
/***************************************\
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
\***************************************/
Ma "maîtrise" de SED avance bien, et ouvre des tas de solutions intéressantes...
Je reviens avec un nouveau demi-problème, survenu en traitant des listes de fichiers. Demi parce que ça fonctionne, mais lourdement...
Donc le contexte est la transformation de listes de fichiers en règles pour un makefile, dans une session MS-DOS sous Win2000, avec la version appropriée de SED. Donc au shell près, c'est du pur SED.
Du "pur" sed ? sous Windows ?
Patrick 'Zener' Brunet wrote:
Bonjour.
Ma "maîtrise" de SED avance bien, et ouvre des tas de solutions
intéressantes...
Je reviens avec un nouveau demi-problème, survenu en traitant des listes de
fichiers. Demi parce que ça fonctionne, mais lourdement...
Donc le contexte est la transformation de listes de fichiers en règles pour
un makefile, dans une session MS-DOS sous Win2000, avec la version
appropriée de SED.
Donc au shell près, c'est du pur SED.
Ma "maîtrise" de SED avance bien, et ouvre des tas de solutions intéressantes...
Je reviens avec un nouveau demi-problème, survenu en traitant des listes de fichiers. Demi parce que ça fonctionne, mais lourdement...
Donc le contexte est la transformation de listes de fichiers en règles pour un makefile, dans une session MS-DOS sous Win2000, avec la version appropriée de SED. Donc au shell près, c'est du pur SED.
Du "pur" sed ? sous Windows ?
JustMe
Jean-Louis Liagre a écrit
Patrick 'Zener' Brunet wrote:
Bonjour.
Ma "maîtrise" de SED avance bien, et ouvre des tas de solutions intéressantes...
Je reviens avec un nouveau demi-problème, survenu en traitant des listes de fichiers. Demi parce que ça fonctionne, mais lourdement...
Donc le contexte est la transformation de listes de fichiers en règles pour un makefile, dans une session MS-DOS sous Win2000, avec la version appropriée de SED. Donc au shell près, c'est du pur SED.
Du "pur" sed ? sous Windows ?
Cygwin rulez :-D
Jean-Louis Liagre a écrit
Patrick 'Zener' Brunet wrote:
Bonjour.
Ma "maîtrise" de SED avance bien, et ouvre des tas de solutions
intéressantes...
Je reviens avec un nouveau demi-problème, survenu en traitant des listes de
fichiers. Demi parce que ça fonctionne, mais lourdement...
Donc le contexte est la transformation de listes de fichiers en règles pour
un makefile, dans une session MS-DOS sous Win2000, avec la version
appropriée de SED.
Donc au shell près, c'est du pur SED.
Ma "maîtrise" de SED avance bien, et ouvre des tas de solutions intéressantes...
Je reviens avec un nouveau demi-problème, survenu en traitant des listes de fichiers. Demi parce que ça fonctionne, mais lourdement...
Donc le contexte est la transformation de listes de fichiers en règles pour un makefile, dans une session MS-DOS sous Win2000, avec la version appropriée de SED. Donc au shell près, c'est du pur SED.
Du "pur" sed ? sous Windows ?
Cygwin rulez :-D
Patrick 'Zener' Brunet
Bonjour.
Je réponds à Jean-Louis Liagre
Patrick 'Zener' Brunet wrote:
[...] Donc le contexte est la transformation de listes de fichiers en règles pour un makefile, dans une session MS-DOS sous Win2000, avec la version appropriée de SED. Donc au shell près, c'est du pur SED.
Du "pur" sed ? sous Windows ?
Il s'agit en principe d'une recompilation des outils GNU sur les librairies C de Windows, donc préservant l'intégralité du fonctionnement standard selon le manuel de SED.
J'en ai d'autres comme ça: j'utilise le GNU make et c'est d'ailleurs pour ça que je SEDe avant pour convertir les backslashes en slashes, par exemple.
La raison de l'ensemble se passe sous Windows, d'où ce choix.
Pour ma part, je ne fais aucun jugement de valeur, je traite un problème sur le système où il se trouve, en utilisant les outils fonctionnellement les mieux adaptés.
Donc dans ce cas, tout fonctionne. C'est seulement étrangement lent dans cette règle spécifique. D'où ma question aux experts.
Merci, Cordialement,
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Bonjour.
Je réponds à Jean-Louis Liagre <root@localhost>
Patrick 'Zener' Brunet wrote:
[...]
Donc le contexte est la transformation de listes de fichiers en
règles pour un makefile, dans une session MS-DOS sous Win2000, avec
la version appropriée de SED.
Donc au shell près, c'est du pur SED.
Du "pur" sed ? sous Windows ?
Il s'agit en principe d'une recompilation des outils GNU sur les librairies
C de Windows, donc préservant l'intégralité du fonctionnement standard selon
le manuel de SED.
J'en ai d'autres comme ça: j'utilise le GNU make et c'est d'ailleurs pour ça
que je SEDe avant pour convertir les backslashes en slashes, par exemple.
La raison de l'ensemble se passe sous Windows, d'où ce choix.
Pour ma part, je ne fais aucun jugement de valeur, je traite un problème sur
le système où il se trouve, en utilisant les outils fonctionnellement les
mieux adaptés.
Donc dans ce cas, tout fonctionne. C'est seulement étrangement lent dans
cette règle spécifique.
D'où ma question aux experts.
Merci, Cordialement,
--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/
[...] Donc le contexte est la transformation de listes de fichiers en règles pour un makefile, dans une session MS-DOS sous Win2000, avec la version appropriée de SED. Donc au shell près, c'est du pur SED.
Du "pur" sed ? sous Windows ?
Il s'agit en principe d'une recompilation des outils GNU sur les librairies C de Windows, donc préservant l'intégralité du fonctionnement standard selon le manuel de SED.
J'en ai d'autres comme ça: j'utilise le GNU make et c'est d'ailleurs pour ça que je SEDe avant pour convertir les backslashes en slashes, par exemple.
La raison de l'ensemble se passe sous Windows, d'où ce choix.
Pour ma part, je ne fais aucun jugement de valeur, je traite un problème sur le système où il se trouve, en utilisant les outils fonctionnellement les mieux adaptés.
Donc dans ce cas, tout fonctionne. C'est seulement étrangement lent dans cette règle spécifique. D'où ma question aux experts.
Merci, Cordialement,
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
JustMe
Patrick 'Zener' Brunet a écrit
Bonjour.
Ma "maîtrise" de SED avance bien, et ouvre des tas de solutions intéressantes...
Je reviens avec un nouveau demi-problème, survenu en traitant des listes de fichiers. Demi parce que ça fonctionne, mais lourdement...
Donc le contexte est la transformation de listes de fichiers en règles pour un makefile, dans une session MS-DOS sous Win2000, avec la version appropriée de SED. Donc au shell près, c'est du pur SED.
J'ai ces deux opérations pour filtrer la liste: ... type List0.work | sed.exe -e '/.src$/d' > List1.work type List1.work | sed.exe -e '/--/d' > List2.work ...
La première élimine donc les lignes avec fichiers en *.src, la seconde celles avec fichiers préfixés par deux tirets (le backslash servant ici de séparateur de répertoires, comme vous le savez).
Non pour ca il faudrait ecrire :
type List1.work | sed.exe -e '/^--/d' > List2.work
Votre expression enleve aussi un fichier toto--tutu
Ces deux règles opèrent sur la même liste d'une dizaine de lignes. Or si la première est instantanée, la seconde met 5 à 6 secondes à s'exécuter. J'ai pu vérifier que c'est la combinaison - qui provoque le phénomène, pas l'absence d'ancrage dans la seconde règle.
Avez vous une explication liée aux mécanismes internes de SED ? Je n'ai rien trouvé dans les tutos et bonnes et mauvaises pratiques... à part l'utilisation du DOS, je sais :o)
Merci, cordialement,
Patrick 'Zener' Brunet a écrit
Bonjour.
Ma "maîtrise" de SED avance bien, et ouvre des tas de solutions
intéressantes...
Je reviens avec un nouveau demi-problème, survenu en traitant des listes de
fichiers. Demi parce que ça fonctionne, mais lourdement...
Donc le contexte est la transformation de listes de fichiers en règles pour
un makefile, dans une session MS-DOS sous Win2000, avec la version
appropriée de SED.
Donc au shell près, c'est du pur SED.
J'ai ces deux opérations pour filtrer la liste:
...
type List0.work | sed.exe -e '/.src$/d' > List1.work
type List1.work | sed.exe -e '/\--/d' > List2.work
...
La première élimine donc les lignes avec fichiers en *.src, la seconde
celles avec fichiers préfixés par deux tirets (le backslash servant ici de
séparateur de répertoires, comme vous le savez).
Non pour ca il faudrait ecrire :
type List1.work | sed.exe -e '/^\--/d' > List2.work
Votre expression enleve aussi un fichier toto--tutu
Ces deux règles opèrent sur la même liste d'une dizaine de lignes. Or si la
première est instantanée, la seconde met 5 à 6 secondes à s'exécuter.
J'ai pu vérifier que c'est la combinaison \- qui provoque le phénomène, pas
l'absence d'ancrage dans la seconde règle.
Avez vous une explication liée aux mécanismes internes de SED ? Je n'ai rien
trouvé dans les tutos et bonnes et mauvaises pratiques... à part
l'utilisation du DOS, je sais :o)
Ma "maîtrise" de SED avance bien, et ouvre des tas de solutions intéressantes...
Je reviens avec un nouveau demi-problème, survenu en traitant des listes de fichiers. Demi parce que ça fonctionne, mais lourdement...
Donc le contexte est la transformation de listes de fichiers en règles pour un makefile, dans une session MS-DOS sous Win2000, avec la version appropriée de SED. Donc au shell près, c'est du pur SED.
J'ai ces deux opérations pour filtrer la liste: ... type List0.work | sed.exe -e '/.src$/d' > List1.work type List1.work | sed.exe -e '/--/d' > List2.work ...
La première élimine donc les lignes avec fichiers en *.src, la seconde celles avec fichiers préfixés par deux tirets (le backslash servant ici de séparateur de répertoires, comme vous le savez).
Non pour ca il faudrait ecrire :
type List1.work | sed.exe -e '/^--/d' > List2.work
Votre expression enleve aussi un fichier toto--tutu
Ces deux règles opèrent sur la même liste d'une dizaine de lignes. Or si la première est instantanée, la seconde met 5 à 6 secondes à s'exécuter. J'ai pu vérifier que c'est la combinaison - qui provoque le phénomène, pas l'absence d'ancrage dans la seconde règle.
Avez vous une explication liée aux mécanismes internes de SED ? Je n'ai rien trouvé dans les tutos et bonnes et mauvaises pratiques... à part l'utilisation du DOS, je sais :o)
Merci, cordialement,
Patrick 'Zener' Brunet
Bonjour.
Je réponds à Patrick 'Zener' Brunet
[...]
J'ai ces deux opérations pour filtrer la liste: ... type List0.work | sed.exe -e '/.src$/d' > List1.work type List1.work | sed.exe -e '/--/d' > List2.work ...
La première élimine donc les lignes avec fichiers en *.src, la seconde celles avec fichiers préfixés par deux tirets (le backslash servant ici de séparateur de répertoires, comme vous le savez).
Et je viens d'en rajouter une troisième pour les fichiers off-*.*:
type List2.work | sed.exe -e '/off-/d' > List3.work
Ces deux règles opèrent sur la même liste d'une dizaine de lignes. Or si la première est instantanée, la seconde met 5 à 6 secondes à s'exécuter.
Et la nouvelle règle est instantanée aussi, ce qui confirme ceci:
J'ai pu vérifier que c'est la combinaison - qui provoque le phénomène, pas l'absence d'ancrage dans la seconde règle.
Voici la liste de fichiers en question (liste test bien sûr):
Donc les lignes 1, 2, 3, 5, 8, 11 et 12 sont à éliminer. La règle lente élimine seulement la ligne 3.
Pas de quoi ramer plusieurs secondes, non ?
Merci, cordialement,
Toujours.
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Bonjour.
Je réponds à Patrick 'Zener' Brunet <use.link.in.signature@ddress.invalid>
[...]
J'ai ces deux opérations pour filtrer la liste:
...
type List0.work | sed.exe -e '/.src$/d' > List1.work
type List1.work | sed.exe -e '/\--/d' > List2.work
...
La première élimine donc les lignes avec fichiers en *.src, la seconde
celles avec fichiers préfixés par deux tirets (le backslash servant
ici de séparateur de répertoires, comme vous le savez).
Et je viens d'en rajouter une troisième pour les fichiers off-*.*:
type List2.work | sed.exe -e '/\off-/d' > List3.work
Ces deux règles opèrent sur la même liste d'une dizaine de lignes. Or
si la première est instantanée, la seconde met 5 à 6 secondes à
s'exécuter.
Et la nouvelle règle est instantanée aussi, ce qui confirme ceci:
J'ai pu vérifier que c'est la combinaison \- qui provoque le
phénomène, pas l'absence d'ancrage dans la seconde règle.
Voici la liste de fichiers en question (liste test bien sûr):
J'ai ces deux opérations pour filtrer la liste: ... type List0.work | sed.exe -e '/.src$/d' > List1.work type List1.work | sed.exe -e '/--/d' > List2.work ...
La première élimine donc les lignes avec fichiers en *.src, la seconde celles avec fichiers préfixés par deux tirets (le backslash servant ici de séparateur de répertoires, comme vous le savez).
Et je viens d'en rajouter une troisième pour les fichiers off-*.*:
type List2.work | sed.exe -e '/off-/d' > List3.work
Ces deux règles opèrent sur la même liste d'une dizaine de lignes. Or si la première est instantanée, la seconde met 5 à 6 secondes à s'exécuter.
Et la nouvelle règle est instantanée aussi, ce qui confirme ceci:
J'ai pu vérifier que c'est la combinaison - qui provoque le phénomène, pas l'absence d'ancrage dans la seconde règle.
Voici la liste de fichiers en question (liste test bien sûr):
Donc les lignes 1, 2, 3, 5, 8, 11 et 12 sont à éliminer. La règle lente élimine seulement la ligne 3.
Pas de quoi ramer plusieurs secondes, non ?
Merci, cordialement,
Toujours.
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Patrick 'Zener' Brunet
Bonjour.
Je réponds à JustMe
Patrick 'Zener' Brunet a écrit
[...] J'ai ces deux opérations pour filtrer la liste: ... type List0.work | sed.exe -e '/.src$/d' > List1.work type List1.work | sed.exe -e '/--/d' > List2.work ...
La première élimine donc les lignes avec fichiers en *.src, la seconde celles avec fichiers préfixés par deux tirets (le backslash servant ici de séparateur de répertoires, comme vous le savez).
Non pour ca il faudrait ecrire :
type List1.work | sed.exe -e '/^--/d' > List2.work
Votre expression enleve aussi un fichier toto--tutu
Négatif, j'ai vérifié, toto--tutu survit (et d'ailleurs j'ai des fichiers à garder contenant un double tiret *au milieu* de leur nom). Je veux éliminer les fichiers ou répertoires préfixés par deux tirets, mais pas forcément placés à la racine de la sous-arborescence de départ. D'où l'absence de l'ancre ^ et la présence du séparateur de répertoires (sous Windows).
Je confirme que le fonctionnement est correct. Mon problème est de comprendre pourquoi cette règle particulière est si lente.
Voyez la liste de fichiers et la différence avec /off-/ dans mon post suivant, même niveau de réponse.
Merci, Cordialement,
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Bonjour.
Je réponds à JustMe <pasdespam@merci.beaucoup.con>
Patrick 'Zener' Brunet a écrit
[...]
J'ai ces deux opérations pour filtrer la liste:
...
type List0.work | sed.exe -e '/.src$/d' > List1.work
type List1.work | sed.exe -e '/\--/d' > List2.work
...
La première élimine donc les lignes avec fichiers en *.src, la
seconde celles avec fichiers préfixés par deux tirets (le backslash
servant ici de séparateur de répertoires, comme vous le savez).
Non pour ca il faudrait ecrire :
type List1.work | sed.exe -e '/^\--/d' > List2.work
Votre expression enleve aussi un fichier toto--tutu
Négatif, j'ai vérifié, toto--tutu survit (et d'ailleurs j'ai des fichiers à
garder contenant un double tiret *au milieu* de leur nom).
Je veux éliminer les fichiers ou répertoires préfixés par deux tirets, mais
pas forcément placés à la racine de la sous-arborescence de départ.
D'où l'absence de l'ancre ^ et la présence du séparateur de répertoires
(sous Windows).
Je confirme que le fonctionnement est correct. Mon problème est de
comprendre pourquoi cette règle particulière est si lente.
Voyez la liste de fichiers et la différence avec /\off-/ dans mon post
suivant, même niveau de réponse.
Merci,
Cordialement,
--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/
[...] J'ai ces deux opérations pour filtrer la liste: ... type List0.work | sed.exe -e '/.src$/d' > List1.work type List1.work | sed.exe -e '/--/d' > List2.work ...
La première élimine donc les lignes avec fichiers en *.src, la seconde celles avec fichiers préfixés par deux tirets (le backslash servant ici de séparateur de répertoires, comme vous le savez).
Non pour ca il faudrait ecrire :
type List1.work | sed.exe -e '/^--/d' > List2.work
Votre expression enleve aussi un fichier toto--tutu
Négatif, j'ai vérifié, toto--tutu survit (et d'ailleurs j'ai des fichiers à garder contenant un double tiret *au milieu* de leur nom). Je veux éliminer les fichiers ou répertoires préfixés par deux tirets, mais pas forcément placés à la racine de la sous-arborescence de départ. D'où l'absence de l'ancre ^ et la présence du séparateur de répertoires (sous Windows).
Je confirme que le fonctionnement est correct. Mon problème est de comprendre pourquoi cette règle particulière est si lente.
Voyez la liste de fichiers et la différence avec /off-/ dans mon post suivant, même niveau de réponse.
Merci, Cordialement,
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
JustMe
Patrick 'Zener' Brunet a écrit
Bonjour.
Je réponds à JustMe
Patrick 'Zener' Brunet a écrit
[...] J'ai ces deux opérations pour filtrer la liste: ... type List0.work | sed.exe -e '/.src$/d' > List1.work type List1.work | sed.exe -e '/--/d' > List2.work ...
La première élimine donc les lignes avec fichiers en *.src, la seconde celles avec fichiers préfixés par deux tirets (le backslash servant ici de séparateur de répertoires, comme vous le savez).
Non pour ca il faudrait ecrire :
type List1.work | sed.exe -e '/^--/d' > List2.work
Votre expression enleve aussi un fichier toto--tutu
Négatif, j'ai vérifié, toto--tutu survit (et d'ailleurs j'ai des fichiers à garder contenant un double tiret *au milieu* de leur nom).
oui, lu trop vite pardon y'a le avant
Patrick 'Zener' Brunet a écrit
Bonjour.
Je réponds à JustMe <pasdespam@merci.beaucoup.con>
Patrick 'Zener' Brunet a écrit
[...]
J'ai ces deux opérations pour filtrer la liste:
...
type List0.work | sed.exe -e '/.src$/d' > List1.work
type List1.work | sed.exe -e '/\--/d' > List2.work
...
La première élimine donc les lignes avec fichiers en *.src, la
seconde celles avec fichiers préfixés par deux tirets (le backslash
servant ici de séparateur de répertoires, comme vous le savez).
Non pour ca il faudrait ecrire :
type List1.work | sed.exe -e '/^\--/d' > List2.work
Votre expression enleve aussi un fichier toto--tutu
Négatif, j'ai vérifié, toto--tutu survit (et d'ailleurs j'ai des fichiers à
garder contenant un double tiret *au milieu* de leur nom).
[...] J'ai ces deux opérations pour filtrer la liste: ... type List0.work | sed.exe -e '/.src$/d' > List1.work type List1.work | sed.exe -e '/--/d' > List2.work ...
La première élimine donc les lignes avec fichiers en *.src, la seconde celles avec fichiers préfixés par deux tirets (le backslash servant ici de séparateur de répertoires, comme vous le savez).
Non pour ca il faudrait ecrire :
type List1.work | sed.exe -e '/^--/d' > List2.work
Votre expression enleve aussi un fichier toto--tutu
Négatif, j'ai vérifié, toto--tutu survit (et d'ailleurs j'ai des fichiers à garder contenant un double tiret *au milieu* de leur nom).
oui, lu trop vite pardon y'a le avant
Jean-Louis Liagre
Patrick 'Zener' Brunet wrote:
Bonjour.
Je réponds à Jean-Louis Liagre
Patrick 'Zener' Brunet wrote:
[...] Donc le contexte est la transformation de listes de fichiers en règles pour un makefile, dans une session MS-DOS sous Win2000, avec la version appropriée de SED. Donc au shell près, c'est du pur SED. Du "pur" sed ? sous Windows ?
Il s'agit en principe d'une recompilation des outils GNU sur les librairies C de Windows, donc préservant l'intégralité du fonctionnement standard selon le manuel de SED.
Ok, je n'appelerais pas gnu sed du "pur sed". Le sed "pur" est le code présent dans les distributions basées sur le code Unix original. Les outils gnu en sont juste une re-implémentation.
Quel est le contenu du fichier List0.work ?
Je pense qu'il s'agit d'un problème spécifique à windows ou a cygwin, mais pas à sed ou gnu sed.
Il y a quelques opérations inutiles (les deux type et le deuxième sed), combien de temps prend la commande equivalente suivante ?
[...]
Donc le contexte est la transformation de listes de fichiers en
règles pour un makefile, dans une session MS-DOS sous Win2000, avec
la version appropriée de SED.
Donc au shell près, c'est du pur SED.
Du "pur" sed ? sous Windows ?
Il s'agit en principe d'une recompilation des outils GNU sur les librairies
C de Windows, donc préservant l'intégralité du fonctionnement standard selon
le manuel de SED.
Ok, je n'appelerais pas gnu sed du "pur sed". Le sed "pur" est le code
présent dans les distributions basées sur le code Unix original.
Les outils gnu en sont juste une re-implémentation.
Quel est le contenu du fichier List0.work ?
Je pense qu'il s'agit d'un problème spécifique à windows ou a cygwin,
mais pas à sed ou gnu sed.
Il y a quelques opérations inutiles (les deux type et le deuxième sed),
combien de temps prend la commande equivalente suivante ?
[...] Donc le contexte est la transformation de listes de fichiers en règles pour un makefile, dans une session MS-DOS sous Win2000, avec la version appropriée de SED. Donc au shell près, c'est du pur SED. Du "pur" sed ? sous Windows ?
Il s'agit en principe d'une recompilation des outils GNU sur les librairies C de Windows, donc préservant l'intégralité du fonctionnement standard selon le manuel de SED.
Ok, je n'appelerais pas gnu sed du "pur sed". Le sed "pur" est le code présent dans les distributions basées sur le code Unix original. Les outils gnu en sont juste une re-implémentation.
Quel est le contenu du fichier List0.work ?
Je pense qu'il s'agit d'un problème spécifique à windows ou a cygwin, mais pas à sed ou gnu sed.
Il y a quelques opérations inutiles (les deux type et le deuxième sed), combien de temps prend la commande equivalente suivante ?
[...] Donc le contexte est la transformation de listes de fichiers en règles pour un makefile, dans une session MS-DOS sous Win2000, avec la version appropriée de SED. Donc au shell près, c'est du pur SED. Du "pur" sed ? sous Windows ?
Il s'agit en principe d'une recompilation des outils GNU sur les librairies C de Windows, donc préservant l'intégralité du fonctionnement standard selon le manuel de SED.
Ok, je n'appelerais pas gnu sed du "pur sed". Le sed "pur" est le code présent dans les distributions basées sur le code Unix original. Les outils gnu en sont juste une re-implémentation.
Quel est le contenu du fichier List0.work ?
Voir mon post en fin de thread. J'ai aussi rajouté des règles depuis.
Je pense qu'il s'agit d'un problème spécifique à windows ou a cygwin, mais pas à sed ou gnu sed.
Oui, moi aussi, mais je ne comprends pas lequel. J'ai reporté les directives en l'état dans un sedscript, et l'ensemble passe instantanément.
Je me demande si ce n'est pas un truc tordu dans le genre tentative d'accès réseau quand le shell voit le double backslash :o) Il m'a déjà bien embêté au début en interprétant le ^ notamment (bug incompréhensible) !!! Bref les regexp dans un shell, c'est un peu du masochisme.
Il y a quelques opérations inutiles (les deux type et le deuxième sed), combien de temps prend la commande equivalente suivante ?
Equivalent pour le chaînage des regexp. En fait je l'avais écrit comme ça au début, j'ai étagé ensuite pour récupérer des résultats intermédiaires (avec lesquels je faisais d'autres conversions). Par contre ça devient vite lourd.
Pour le stream d'entrée, en shell NT-DOS ça se passe mal comme ça: le fichier de sortie reste verrouillé, ce qui doit être un bug. Et le start /wait sed.exe n'y change rien. Idem avec la forme sed.exe < in > out. Comme type est une commande builtin du shell, avec le pipe ça passe correctement.
Donc pour conclure, je vous remercie de vos conseils. J'ai finalisé le truc avec le sedscript maintenant. En fait je craignais que ça rame en vraie grandeur, mais les 200 fichiers passent très vite comme ça, et le temps de conversion est négligeable devant la compilation qui suit (le tout dure environ 6mn).
Cordialement,
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Bonjour.
Je réponds à Jean-Louis Liagre <root@localhost>
Patrick 'Zener' Brunet wrote:
Je réponds à Jean-Louis Liagre <root@localhost>
Patrick 'Zener' Brunet wrote:
[...]
Donc le contexte est la transformation de listes de fichiers en
règles pour un makefile, dans une session MS-DOS sous Win2000, avec
la version appropriée de SED.
Donc au shell près, c'est du pur SED.
Du "pur" sed ? sous Windows ?
Il s'agit en principe d'une recompilation des outils GNU sur les
librairies C de Windows, donc préservant l'intégralité du
fonctionnement standard selon le manuel de SED.
Ok, je n'appelerais pas gnu sed du "pur sed". Le sed "pur" est le code
présent dans les distributions basées sur le code Unix original.
Les outils gnu en sont juste une re-implémentation.
Quel est le contenu du fichier List0.work ?
Voir mon post en fin de thread. J'ai aussi rajouté des règles depuis.
Je pense qu'il s'agit d'un problème spécifique à windows ou a cygwin,
mais pas à sed ou gnu sed.
Oui, moi aussi, mais je ne comprends pas lequel.
J'ai reporté les directives en l'état dans un sedscript, et l'ensemble passe
instantanément.
Je me demande si ce n'est pas un truc tordu dans le genre tentative d'accès
réseau quand le shell voit le double backslash :o)
Il m'a déjà bien embêté au début en interprétant le ^ notamment (bug
incompréhensible) !!!
Bref les regexp dans un shell, c'est un peu du masochisme.
Il y a quelques opérations inutiles (les deux type et le deuxième
sed), combien de temps prend la commande equivalente suivante ?
Equivalent pour le chaînage des regexp. En fait je l'avais écrit comme ça au
début, j'ai étagé ensuite pour récupérer des résultats intermédiaires (avec
lesquels je faisais d'autres conversions). Par contre ça devient vite lourd.
Pour le stream d'entrée, en shell NT-DOS ça se passe mal comme ça: le
fichier de sortie reste verrouillé, ce qui doit être un bug. Et le start
/wait sed.exe n'y change rien.
Idem avec la forme sed.exe < in > out. Comme type est une commande builtin
du shell, avec le pipe ça passe correctement.
Donc pour conclure, je vous remercie de vos conseils.
J'ai finalisé le truc avec le sedscript maintenant.
En fait je craignais que ça rame en vraie grandeur, mais les 200 fichiers
passent très vite comme ça, et le temps de conversion est négligeable devant
la compilation qui suit (le tout dure environ 6mn).
Cordialement,
--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/
[...] Donc le contexte est la transformation de listes de fichiers en règles pour un makefile, dans une session MS-DOS sous Win2000, avec la version appropriée de SED. Donc au shell près, c'est du pur SED. Du "pur" sed ? sous Windows ?
Il s'agit en principe d'une recompilation des outils GNU sur les librairies C de Windows, donc préservant l'intégralité du fonctionnement standard selon le manuel de SED.
Ok, je n'appelerais pas gnu sed du "pur sed". Le sed "pur" est le code présent dans les distributions basées sur le code Unix original. Les outils gnu en sont juste une re-implémentation.
Quel est le contenu du fichier List0.work ?
Voir mon post en fin de thread. J'ai aussi rajouté des règles depuis.
Je pense qu'il s'agit d'un problème spécifique à windows ou a cygwin, mais pas à sed ou gnu sed.
Oui, moi aussi, mais je ne comprends pas lequel. J'ai reporté les directives en l'état dans un sedscript, et l'ensemble passe instantanément.
Je me demande si ce n'est pas un truc tordu dans le genre tentative d'accès réseau quand le shell voit le double backslash :o) Il m'a déjà bien embêté au début en interprétant le ^ notamment (bug incompréhensible) !!! Bref les regexp dans un shell, c'est un peu du masochisme.
Il y a quelques opérations inutiles (les deux type et le deuxième sed), combien de temps prend la commande equivalente suivante ?
Equivalent pour le chaînage des regexp. En fait je l'avais écrit comme ça au début, j'ai étagé ensuite pour récupérer des résultats intermédiaires (avec lesquels je faisais d'autres conversions). Par contre ça devient vite lourd.
Pour le stream d'entrée, en shell NT-DOS ça se passe mal comme ça: le fichier de sortie reste verrouillé, ce qui doit être un bug. Et le start /wait sed.exe n'y change rien. Idem avec la forme sed.exe < in > out. Comme type est une commande builtin du shell, avec le pipe ça passe correctement.
Donc pour conclure, je vous remercie de vos conseils. J'ai finalisé le truc avec le sedscript maintenant. En fait je craignais que ça rame en vraie grandeur, mais les 200 fichiers passent très vite comme ça, et le temps de conversion est négligeable devant la compilation qui suit (le tout dure environ 6mn).
Cordialement,
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Jean-Louis Liagre
Patrick 'Zener' Brunet wrote:
[...]
Je pense qu'il s'agit d'un problème spécifique à windows ou a cygwin, mais pas à sed ou gnu sed.
Oui, moi aussi, mais je ne comprends pas lequel. J'ai reporté les directives en l'état dans un sedscript, et l'ensemble passe instantanément.
Je me demande si ce n'est pas un truc tordu dans le genre tentative d'accès réseau quand le shell voit le double backslash :o) Il m'a déjà bien embêté au début en interprétant le ^ notamment (bug incompréhensible) !!! Bref les regexp dans un shell, c'est un peu du masochisme.
Non, ça ne pose pas de problème, en revanche utiliser Windows, ça c'est un peu du masochisme ;)
Pour le stream d'entrée, en shell NT-DOS ça se passe mal comme ça: le fichier de sortie reste verrouillé, ce qui doit être un bug. Et le start /wait sed.exe n'y change rien. Idem avec la forme sed.exe < in > out. Comme type est une commande builtin du shell, avec le pipe ça passe correctement.
Pour quoi utiliser "type" et cmd.exe et pas "cat" sous un shell de cygwin ?
Patrick 'Zener' Brunet wrote:
[...]
Je pense qu'il s'agit d'un problème spécifique à windows ou a cygwin,
mais pas à sed ou gnu sed.
Oui, moi aussi, mais je ne comprends pas lequel.
J'ai reporté les directives en l'état dans un sedscript, et l'ensemble passe
instantanément.
Je me demande si ce n'est pas un truc tordu dans le genre tentative d'accès
réseau quand le shell voit le double backslash :o)
Il m'a déjà bien embêté au début en interprétant le ^ notamment (bug
incompréhensible) !!!
Bref les regexp dans un shell, c'est un peu du masochisme.
Non, ça ne pose pas de problème, en revanche utiliser Windows, ça c'est
un peu du masochisme ;)
Pour le stream d'entrée, en shell NT-DOS ça se passe mal comme ça: le
fichier de sortie reste verrouillé, ce qui doit être un bug. Et le start
/wait sed.exe n'y change rien.
Idem avec la forme sed.exe < in > out. Comme type est une commande builtin
du shell, avec le pipe ça passe correctement.
Pour quoi utiliser "type" et cmd.exe et pas "cat" sous un shell de cygwin ?
Je pense qu'il s'agit d'un problème spécifique à windows ou a cygwin, mais pas à sed ou gnu sed.
Oui, moi aussi, mais je ne comprends pas lequel. J'ai reporté les directives en l'état dans un sedscript, et l'ensemble passe instantanément.
Je me demande si ce n'est pas un truc tordu dans le genre tentative d'accès réseau quand le shell voit le double backslash :o) Il m'a déjà bien embêté au début en interprétant le ^ notamment (bug incompréhensible) !!! Bref les regexp dans un shell, c'est un peu du masochisme.
Non, ça ne pose pas de problème, en revanche utiliser Windows, ça c'est un peu du masochisme ;)
Pour le stream d'entrée, en shell NT-DOS ça se passe mal comme ça: le fichier de sortie reste verrouillé, ce qui doit être un bug. Et le start /wait sed.exe n'y change rien. Idem avec la forme sed.exe < in > out. Comme type est une commande builtin du shell, avec le pipe ça passe correctement.
Pour quoi utiliser "type" et cmd.exe et pas "cat" sous un shell de cygwin ?
