Je l'utilise dans la compilation d'une multitude de fichiers, et donc il est
fastidieux de relire tout ce qui en sort.
Ca m'arrangerait donc beaucoup de récupérer les erreurs éventuelles dans un
fichier, séparément du résultat de compilation.
=> c'est bien plus facile de vérifier à la fin que le fichier est vide.
Je comptais sur les options de ligne de commande et/ou sur les builtins pour
faire ça, mais apparemment cela n'est possible que pour les traces de
debugging.
Extrait du makefile:
m4 -P --error-output=M4ERROR.work $(*F).script.php > ThisFile.work
...avec aussi dans les définitions:
m4_debugfile( M4ERROR.work)
Mais hélas mon fichier M4ERROR.work reste désespérément vide.
Si une erreur de syntaxe est trouvée, elle sort sur la console, et donc il
faut la voir passer.
D'ailleurs c'est bizarre, elle devrait aller dans le fichier
ThisFile.work... stderr n'est donc pas redirigé en même temps que stdout (?)
Est-ce que ce comportement est standard ? Y a-t-il une option pour rediriger
stderr ?
Merci de vos tuyaux.
--
Cordialement.
--
/***************************************\
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
\***************************************/
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
Stephane Chazelas
2006-12-17, 17:43(+01), Patrick 'Zener' Brunet: [...]
Je l'utilise dans la compilation d'une multitude de fichiers, et donc il est fastidieux de relire tout ce qui en sort. Ca m'arrangerait donc beaucoup de récupérer les erreurs éventuelles dans un fichier, séparément du résultat de compilation. => c'est bien plus facile de vérifier à la fin que le fichier est vide.
Je comptais sur les options de ligne de commande et/ou sur les builtins pour faire ça, mais apparemment cela n'est possible que pour les traces de debugging.
Extrait du makefile: m4 -P --error-output=M4ERROR.work $(*F).script.php > ThisFile.work
...avec aussi dans les définitions: m4_debugfile( M4ERROR.work)
Mais hélas mon fichier M4ERROR.work reste désespérément vide. Si une erreur de syntaxe est trouvée, elle sort sur la console, et donc il faut la voir passer. D'ailleurs c'est bizarre, elle devrait aller dans le fichier ThisFile.work... stderr n'est donc pas redirigé en même temps que stdout (?)
Est-ce que ce comportement est standard ? Y a-t-il une option pour rediriger stderr ? [...]
"> fichier" est une forme abregee de 1> fichier. Pour rediriger stderr: "2> fichier", pour rediriger stderr vers la meme chose que ce sur quoi stdout est redirigé: > fichier 2>&1
Rien a voir avec m4 ou make, c'est une fonctionalité des shell de type Bourne (en particulier "sh" quel qu'il soit que make appelle pour lancer des commandes). Les shells de type rc ont ca aussi avec une autre syntaxe. Les shells de type csh ne peuvent rediriger que stdout ou stdout+stderr (avec >& qui reconnaissent aussi certains shells de type Bourne comme zsh ou des version recentes de bash ou ksh93).
-- Stéphane
2006-12-17, 17:43(+01), Patrick 'Zener' Brunet:
[...]
Je l'utilise dans la compilation d'une multitude de fichiers, et donc il est
fastidieux de relire tout ce qui en sort.
Ca m'arrangerait donc beaucoup de récupérer les erreurs éventuelles dans un
fichier, séparément du résultat de compilation.
=> c'est bien plus facile de vérifier à la fin que le fichier est vide.
Je comptais sur les options de ligne de commande et/ou sur les builtins pour
faire ça, mais apparemment cela n'est possible que pour les traces de
debugging.
Extrait du makefile:
m4 -P --error-output=M4ERROR.work $(*F).script.php > ThisFile.work
...avec aussi dans les définitions:
m4_debugfile( M4ERROR.work)
Mais hélas mon fichier M4ERROR.work reste désespérément vide.
Si une erreur de syntaxe est trouvée, elle sort sur la console, et donc il
faut la voir passer.
D'ailleurs c'est bizarre, elle devrait aller dans le fichier
ThisFile.work... stderr n'est donc pas redirigé en même temps que stdout (?)
Est-ce que ce comportement est standard ? Y a-t-il une option pour rediriger
stderr ?
[...]
"> fichier" est une forme abregee de 1> fichier. Pour rediriger
stderr: "2> fichier", pour rediriger stderr vers la meme chose
que ce sur quoi stdout est redirigé: > fichier 2>&1
Rien a voir avec m4 ou make, c'est une fonctionalité des shell
de type Bourne (en particulier "sh" quel qu'il soit que make
appelle pour lancer des commandes). Les shells de type rc ont ca
aussi avec une autre syntaxe. Les shells de type csh ne peuvent
rediriger que stdout ou stdout+stderr (avec >& qui reconnaissent
aussi certains shells de type Bourne comme zsh ou des version
recentes de bash ou ksh93).
2006-12-17, 17:43(+01), Patrick 'Zener' Brunet: [...]
Je l'utilise dans la compilation d'une multitude de fichiers, et donc il est fastidieux de relire tout ce qui en sort. Ca m'arrangerait donc beaucoup de récupérer les erreurs éventuelles dans un fichier, séparément du résultat de compilation. => c'est bien plus facile de vérifier à la fin que le fichier est vide.
Je comptais sur les options de ligne de commande et/ou sur les builtins pour faire ça, mais apparemment cela n'est possible que pour les traces de debugging.
Extrait du makefile: m4 -P --error-output=M4ERROR.work $(*F).script.php > ThisFile.work
...avec aussi dans les définitions: m4_debugfile( M4ERROR.work)
Mais hélas mon fichier M4ERROR.work reste désespérément vide. Si une erreur de syntaxe est trouvée, elle sort sur la console, et donc il faut la voir passer. D'ailleurs c'est bizarre, elle devrait aller dans le fichier ThisFile.work... stderr n'est donc pas redirigé en même temps que stdout (?)
Est-ce que ce comportement est standard ? Y a-t-il une option pour rediriger stderr ? [...]
"> fichier" est une forme abregee de 1> fichier. Pour rediriger stderr: "2> fichier", pour rediriger stderr vers la meme chose que ce sur quoi stdout est redirigé: > fichier 2>&1
Rien a voir avec m4 ou make, c'est une fonctionalité des shell de type Bourne (en particulier "sh" quel qu'il soit que make appelle pour lancer des commandes). Les shells de type rc ont ca aussi avec une autre syntaxe. Les shells de type csh ne peuvent rediriger que stdout ou stdout+stderr (avec >& qui reconnaissent aussi certains shells de type Bourne comme zsh ou des version recentes de bash ou ksh93).
-- Stéphane
Patrick 'Zener' Brunet
"Stephane Chazelas" a écrit dans le message de news:
2006-12-17, 17:43(+01), Patrick 'Zener' Brunet: [...]
Est-ce que ce comportement est standard ? Y a-t-il une option pour rediriger
stderr ? [...]
"> fichier" est une forme abregee de 1> fichier. Pour rediriger stderr: "2> fichier", pour rediriger stderr vers la meme chose que ce sur quoi stdout est redirigé: > fichier 2>&1
Ca m'avait échappé, et ça marche très bien, même dans le portage sur console NT.
Merci beaucoup.
Rien a voir avec m4 ou make, c'est une fonctionalité des shell de type Bourne (en particulier "sh" quel qu'il soit que make appelle pour lancer des commandes). Les shells de type rc ont ca aussi avec une autre syntaxe. Les shells de type csh ne peuvent rediriger que stdout ou stdout+stderr (avec >& qui reconnaissent aussi certains shells de type Bourne comme zsh ou des version recentes de bash ou ksh93).
C'est idéal. Je reste convaincu de l'intérêt des scripts de compilation pour la productivité. Contrairement aux cliquodromes, ils font exactement ce qu'on leur dit de faire.
-- Cordialement. -- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
"Stephane Chazelas" <cette.adresse@est.invalid> a écrit dans le message de
news: slrneob1m7.9na.stephane.chazelas@spam.is.invalid...
2006-12-17, 17:43(+01), Patrick 'Zener' Brunet:
[...]
Est-ce que ce comportement est standard ? Y a-t-il une option pour
rediriger
stderr ?
[...]
"> fichier" est une forme abregee de 1> fichier. Pour rediriger
stderr: "2> fichier", pour rediriger stderr vers la meme chose
que ce sur quoi stdout est redirigé: > fichier 2>&1
Ca m'avait échappé, et ça marche très bien, même dans le portage sur console
NT.
Merci beaucoup.
Rien a voir avec m4 ou make, c'est une fonctionalité des shell
de type Bourne (en particulier "sh" quel qu'il soit que make
appelle pour lancer des commandes). Les shells de type rc ont ca
aussi avec une autre syntaxe. Les shells de type csh ne peuvent
rediriger que stdout ou stdout+stderr (avec >& qui reconnaissent
aussi certains shells de type Bourne comme zsh ou des version
recentes de bash ou ksh93).
C'est idéal. Je reste convaincu de l'intérêt des scripts de compilation pour
la productivité. Contrairement aux cliquodromes, ils font exactement ce
qu'on leur dit de faire.
--
Cordialement.
--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/
"Stephane Chazelas" a écrit dans le message de news:
2006-12-17, 17:43(+01), Patrick 'Zener' Brunet: [...]
Est-ce que ce comportement est standard ? Y a-t-il une option pour rediriger
stderr ? [...]
"> fichier" est une forme abregee de 1> fichier. Pour rediriger stderr: "2> fichier", pour rediriger stderr vers la meme chose que ce sur quoi stdout est redirigé: > fichier 2>&1
Ca m'avait échappé, et ça marche très bien, même dans le portage sur console NT.
Merci beaucoup.
Rien a voir avec m4 ou make, c'est une fonctionalité des shell de type Bourne (en particulier "sh" quel qu'il soit que make appelle pour lancer des commandes). Les shells de type rc ont ca aussi avec une autre syntaxe. Les shells de type csh ne peuvent rediriger que stdout ou stdout+stderr (avec >& qui reconnaissent aussi certains shells de type Bourne comme zsh ou des version recentes de bash ou ksh93).
C'est idéal. Je reste convaincu de l'intérêt des scripts de compilation pour la productivité. Contrairement aux cliquodromes, ils font exactement ce qu'on leur dit de faire.
-- Cordialement. -- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
