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
\***************************************/
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 ?
:-)
J'ai une machine sur laquelle j'installe un Linux, dans le but de mener des développements portables.
Mais sur une plate-forme donnée, j'essaie de limiter l'exogamie au strict nécessaire.
Là je me tape déjà sed, make et m4, en local dans le répertoire, mais le but n'est pas de changer la triperie complète du système.
Tout fonctionne à ce stade, je suis seulement en train de me prendre la tête avec un problème de méta-définition en m4 (definir une macro qui fait du ifdef-append-else-define), l'imbrication des quotes n'est pas triste :-)
Parce que les shells en général, c'est très puissant du point de vue productivité, mais bonjour l'ergonomie quand on commence à faire des trucs un peu complexes ;-)
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 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 ?
:-)
J'ai une machine sur laquelle j'installe un Linux, dans le but de mener des
développements portables.
Mais sur une plate-forme donnée, j'essaie de limiter l'exogamie au strict
nécessaire.
Là je me tape déjà sed, make et m4, en local dans le répertoire, mais le but
n'est pas de changer la triperie complète du système.
Tout fonctionne à ce stade, je suis seulement en train de me prendre la tête
avec un problème de méta-définition en m4 (definir une macro qui fait du
ifdef-append-else-define), l'imbrication des quotes n'est pas triste :-)
Parce que les shells en général, c'est très puissant du point de vue
productivité, mais bonjour l'ergonomie quand on commence à faire des trucs
un peu complexes ;-)
Cordialement,
--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/
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 ?
:-)
J'ai une machine sur laquelle j'installe un Linux, dans le but de mener des développements portables.
Mais sur une plate-forme donnée, j'essaie de limiter l'exogamie au strict nécessaire.
Là je me tape déjà sed, make et m4, en local dans le répertoire, mais le but n'est pas de changer la triperie complète du système.
Tout fonctionne à ce stade, je suis seulement en train de me prendre la tête avec un problème de méta-définition en m4 (definir une macro qui fait du ifdef-append-else-define), l'imbrication des quotes n'est pas triste :-)
Parce que les shells en général, c'est très puissant du point de vue productivité, mais bonjour l'ergonomie quand on commence à faire des trucs un peu complexes ;-)
Cordialement,
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
ebe_spam__spam
On 2006-10-29, Patrick 'Zener' Brunet wrote:
Parce que les shells en général, c'est très puissant du point de vue productivité, mais bonjour l'ergonomie quand on commence à faire des trucs un peu complexes ;-)
Peut-etre pourriez-vous essayer python ou perl?
-- ebe
On 2006-10-29, Patrick 'Zener' Brunet <use.link.in.signature@ddress.invalid> wrote:
Parce que les shells en général, c'est très puissant du point de vue
productivité, mais bonjour l'ergonomie quand on commence à faire des trucs
un peu complexes ;-)
Parce que les shells en général, c'est très puissant du point de vue productivité, mais bonjour l'ergonomie quand on commence à faire des trucs un peu complexes ;-)
Peut-etre pourriez-vous essayer python ou perl?
-- ebe
Patrick 'Zener' Brunet
Bonjour.
Je réponds à
On 2006-10-29, Patrick 'Zener' Brunet wrote:
Parce que les shells en général, c'est très puissant du point de vue productivité, mais bonjour l'ergonomie quand on commence à faire des trucs un peu complexes ;-)
Peut-etre pourriez-vous essayer python ou perl?
Mouais... J'ai vu des mix avec même du Lisp... Faudrait quand même pas que l'outil commence à usurper le rôle de but de la manip.
Là je suis en train d'essayer d'obtenir de m4 un bête saut de ligne, et apparemment ça ne figure pas dans les builtin ??? :-@
A vrai dire, quand ce genre de problème commence à sérieusement me les brouter, je me développe un utilitaire sur mesure en bon vieux C++, et généralement ça marche mieux et plus vite :o)
Cordialement,
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Bonjour.
Je réponds à ebe_spam__spam@free.fr.invalid <ebe_spam__spam@free.fr.invalid>
On 2006-10-29, Patrick 'Zener' Brunet
<use.link.in.signature@ddress.invalid> wrote:
Parce que les shells en général, c'est très puissant du point de vue
productivité, mais bonjour l'ergonomie quand on commence à faire des
trucs un peu complexes ;-)
Peut-etre pourriez-vous essayer python ou perl?
Mouais... J'ai vu des mix avec même du Lisp...
Faudrait quand même pas que l'outil commence à usurper le rôle de but de la
manip.
Là je suis en train d'essayer d'obtenir de m4 un bête saut de ligne, et
apparemment ça ne figure pas dans les builtin ??? :-@
A vrai dire, quand ce genre de problème commence à sérieusement me les
brouter, je me développe un utilitaire sur mesure en bon vieux C++, et
généralement ça marche mieux et plus vite :o)
Cordialement,
--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/
Parce que les shells en général, c'est très puissant du point de vue productivité, mais bonjour l'ergonomie quand on commence à faire des trucs un peu complexes ;-)
Peut-etre pourriez-vous essayer python ou perl?
Mouais... J'ai vu des mix avec même du Lisp... Faudrait quand même pas que l'outil commence à usurper le rôle de but de la manip.
Là je suis en train d'essayer d'obtenir de m4 un bête saut de ligne, et apparemment ça ne figure pas dans les builtin ??? :-@
A vrai dire, quand ce genre de problème commence à sérieusement me les brouter, je me développe un utilitaire sur mesure en bon vieux C++, et généralement ça marche mieux et plus vite :o)
Cordialement,
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Stan
"Patrick 'Zener' Brunet" a écrit dans le message de news: ei39e4$poo$
A vrai dire, quand ce genre de problème commence à sérieusement me les brouter, je me développe un utilitaire sur mesure en bon vieux C++, et généralement ça marche mieux et plus vite :o)
Pouvez-vous me rappelez en quoi consitent vos traitements ? Je ne suis pas sûr qu'une appli en C++ soit fiable et facile à mettre en oeuvre...
-- -Stan
"Patrick 'Zener' Brunet" <use.link.in.signature@ddress.invalid> a écrit dans
le message de news: ei39e4$poo$1@shakotay.alphanet.ch...
A vrai dire, quand ce genre de problème commence à sérieusement me les
brouter, je me développe un utilitaire sur mesure en bon vieux C++, et
généralement ça marche mieux et plus vite :o)
Pouvez-vous me rappelez en quoi consitent vos traitements ?
Je ne suis pas sûr qu'une appli en C++ soit fiable et facile à
mettre en oeuvre...
"Patrick 'Zener' Brunet" a écrit dans le message de news: ei39e4$poo$
A vrai dire, quand ce genre de problème commence à sérieusement me les brouter, je me développe un utilitaire sur mesure en bon vieux C++, et généralement ça marche mieux et plus vite :o)
Pouvez-vous me rappelez en quoi consitent vos traitements ? Je ne suis pas sûr qu'une appli en C++ soit fiable et facile à mettre en oeuvre...
-- -Stan
Patrick 'Zener' Brunet
Bonjour.
Je réponds à Stan
"Patrick 'Zener' Brunet" a écrit dans le message de news: ei39e4$poo$
A vrai dire, quand ce genre de problème commence à sérieusement me les brouter, je me développe un utilitaire sur mesure en bon vieux C++, et généralement ça marche mieux et plus vite :o)
Pouvez-vous me rappelez en quoi consitent vos traitements ? Je ne suis pas sûr qu'une appli en C++ soit fiable et facile à mettre en oeuvre...
Il s'agit de substitution globale "bête et méchante" de patterns. Pas de numérotation, permutation ou autre complexité.
Il arrive quelquefois que ces patterns soient un peu "souples", c'est à dire avec un sous-pattern de début + un de fin et n'importe quoi entre les deux, ou bien un sous-pattern répétable tel qu'une classe de caractères.
Mais la plupart du temps, c'est du pattern fixe, sans ambiguïté, à substituer par un autre ou à supprimer (ce qui est équivalent).
J'ai déjà écrit un tel outil, qui traite des macros délimitées fournies par un script annexe, et avec un traitement récursif. Presque m4 donc.
Si j'utilise plus volontiers des macros délimitées (je force les préfixes avec m4), c'est pour ne pas me poser trop souvent des problèmes de collisions avec les textes traités. Mais donc dans le cas présent, traiter des patterns non balisés ne serait pas plus difficile...
Donc pour traiter ainsi ponctuellement des lignes dans de petites listes stéréotypées, SED convient très bien, à condition bien sûr que je ne passe pas des heures à essayer de deviner pourquoi ça ne marche pas d'une manière ou d'une autre... Et c'est valable aussi pour m4. L'outil n'est pas le but.
Cordialement,
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Bonjour.
Je réponds à Stan <none@none.fr>
"Patrick 'Zener' Brunet" <use.link.in.signature@ddress.invalid> a
écrit dans le message de news: ei39e4$poo$1@shakotay.alphanet.ch...
A vrai dire, quand ce genre de problème commence à sérieusement me
les brouter, je me développe un utilitaire sur mesure en bon vieux
C++, et généralement ça marche mieux et plus vite :o)
Pouvez-vous me rappelez en quoi consitent vos traitements ?
Je ne suis pas sûr qu'une appli en C++ soit fiable et facile à
mettre en oeuvre...
Il s'agit de substitution globale "bête et méchante" de patterns. Pas de
numérotation, permutation ou autre complexité.
Il arrive quelquefois que ces patterns soient un peu "souples", c'est à dire
avec un sous-pattern de début + un de fin et n'importe quoi entre les deux,
ou bien un sous-pattern répétable tel qu'une classe de caractères.
Mais la plupart du temps, c'est du pattern fixe, sans ambiguïté, à
substituer par un autre ou à supprimer (ce qui est équivalent).
J'ai déjà écrit un tel outil, qui traite des macros délimitées fournies par
un script annexe, et avec un traitement récursif. Presque m4 donc.
Si j'utilise plus volontiers des macros délimitées (je force les préfixes
avec m4), c'est pour ne pas me poser trop souvent des problèmes de
collisions avec les textes traités.
Mais donc dans le cas présent, traiter des patterns non balisés ne serait
pas plus difficile...
Donc pour traiter ainsi ponctuellement des lignes dans de petites listes
stéréotypées, SED convient très bien, à condition bien sûr que je ne passe
pas des heures à essayer de deviner pourquoi ça ne marche pas d'une manière
ou d'une autre... Et c'est valable aussi pour m4. L'outil n'est pas le but.
Cordialement,
--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/
"Patrick 'Zener' Brunet" a écrit dans le message de news: ei39e4$poo$
A vrai dire, quand ce genre de problème commence à sérieusement me les brouter, je me développe un utilitaire sur mesure en bon vieux C++, et généralement ça marche mieux et plus vite :o)
Pouvez-vous me rappelez en quoi consitent vos traitements ? Je ne suis pas sûr qu'une appli en C++ soit fiable et facile à mettre en oeuvre...
Il s'agit de substitution globale "bête et méchante" de patterns. Pas de numérotation, permutation ou autre complexité.
Il arrive quelquefois que ces patterns soient un peu "souples", c'est à dire avec un sous-pattern de début + un de fin et n'importe quoi entre les deux, ou bien un sous-pattern répétable tel qu'une classe de caractères.
Mais la plupart du temps, c'est du pattern fixe, sans ambiguïté, à substituer par un autre ou à supprimer (ce qui est équivalent).
J'ai déjà écrit un tel outil, qui traite des macros délimitées fournies par un script annexe, et avec un traitement récursif. Presque m4 donc.
Si j'utilise plus volontiers des macros délimitées (je force les préfixes avec m4), c'est pour ne pas me poser trop souvent des problèmes de collisions avec les textes traités. Mais donc dans le cas présent, traiter des patterns non balisés ne serait pas plus difficile...
Donc pour traiter ainsi ponctuellement des lignes dans de petites listes stéréotypées, SED convient très bien, à condition bien sûr que je ne passe pas des heures à essayer de deviner pourquoi ça ne marche pas d'une manière ou d'une autre... Et c'est valable aussi pour m4. L'outil n'est pas le but.
Cordialement,
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
