Je viens de me rendre compte d'un petit truc bizarre. Dans un script
configure.in, j'ai écrit :
DATE_FR=$(LC_ALL=fr_FR date +'%A %x, %X %Z')
DATE=$(LC_ALL=C date +'%A %x, %X %Z')
et les deux variables sont remplies avec la version anglaise de la
date, comme si la variable LC_ALL n'avait aucune incidence.
Pourtant, en ligne de commande, j'ai bien :
cauchy:[~] > LC_ALL=fr_FR date +'%A %x, %X %Z'
samedi 09/01/2010, 14:17:50 CET
cauchy:[~] > LC_ALL=C date +'%A %x, %X %Z'
Saturday 01/09/10, 14:17:54 CET
J'ai dû rater quelque chose, mais je ne vois pas quoi et google ne
semble pas être mon ami sur ce coup :-(
À noter que je tente cette modification pour soustraire une verrue à
coups de sed d'un makefile et que la même variable définie dans un
makefile ne pose strictement aucun problème.
Une idée ?
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
le 10/01/2010 à 21:09, Bruno Tréguier a écrit dans le message <hidc5k$t8s$ :
Cela étant dit, dans le cas d'utilisation dont il est question ici, les comportements devraient être identiques (tant que env est dans le PATH ;-) ).
On est bien d'accord. Je cherche juste à comprendre comment il peut en être autrement avec autoconf. Que se soit avec « env » ou avec « export » (et dans ce cas c'est un builtin donc exit l'exemple bidon du $PATH).
-- Benoit Izac
Bonjour,
le 10/01/2010 à 21:09, Bruno Tréguier a écrit dans le message
<hidc5k$t8s$2@typhon.shom.fr> :
Cela étant dit, dans le cas d'utilisation dont il est question ici,
les comportements devraient être identiques (tant que env est dans le
PATH ;-) ).
On est bien d'accord. Je cherche juste à comprendre comment il peut en
être autrement avec autoconf. Que se soit avec « env » ou avec
« export » (et dans ce cas c'est un builtin donc exit l'exemple bidon du
$PATH).
le 10/01/2010 à 21:09, Bruno Tréguier a écrit dans le message <hidc5k$t8s$ :
Cela étant dit, dans le cas d'utilisation dont il est question ici, les comportements devraient être identiques (tant que env est dans le PATH ;-) ).
On est bien d'accord. Je cherche juste à comprendre comment il peut en être autrement avec autoconf. Que se soit avec « env » ou avec « export » (et dans ce cas c'est un builtin donc exit l'exemple bidon du $PATH).
-- Benoit Izac
JKB
Le 10-01-2010, ? propos de Re: LC_ALL dans un script configure, Bruno Tréguier ?crivait dans fr.comp.os.unix :
Le 10/01/2010 à 21:21, Benoit Izac a écrit :
Cela étant dit, dans le cas d'utilisation dont il est question ici, les comportements devraient être identiques (tant que env est dans le PATH ;-) ).
On est bien d'accord. Je cherche juste à comprendre comment il peut en être autrement avec autoconf. Que se soit avec « env » ou avec « export » (et dans ce cas c'est un builtin donc exit l'exemple bidon du $PATH).
J'en reviens à ce que j'ai dit hier (bien que n'étant pas spécialiste de autoconf): le fichier "configure.in" n'a pas l'air d'être interprété directement par un shell. C'est un fichier qui contient des macros M4. Le traitement qu'il subit n'est peut-être pas pour rien dans ce comportement ?
La ligne est recopiée presque telle quelle dans le configure : DATE=$(env LC_ALL=C date +'%A %x, %X %Z') qui est interprété par /bin/sh.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 10-01-2010, ? propos de
Re: LC_ALL dans un script configure,
Bruno Tréguier ?crivait dans fr.comp.os.unix :
Le 10/01/2010 à 21:21, Benoit Izac a écrit :
Cela étant dit, dans le cas d'utilisation dont il est question ici,
les comportements devraient être identiques (tant que env est dans le
PATH ;-) ).
On est bien d'accord. Je cherche juste à comprendre comment il peut en
être autrement avec autoconf. Que se soit avec « env » ou avec
« export » (et dans ce cas c'est un builtin donc exit l'exemple bidon du
$PATH).
J'en reviens à ce que j'ai dit hier (bien que n'étant pas spécialiste de
autoconf): le fichier "configure.in" n'a pas l'air d'être interprété
directement par un shell. C'est un fichier qui contient des macros M4.
Le traitement qu'il subit n'est peut-être pas pour rien dans ce
comportement ?
La ligne est recopiée presque telle quelle dans le configure :
DATE=$(env LC_ALL=C date +'%A %x, %X %Z')
qui est interprété par /bin/sh.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 10-01-2010, ? propos de Re: LC_ALL dans un script configure, Bruno Tréguier ?crivait dans fr.comp.os.unix :
Le 10/01/2010 à 21:21, Benoit Izac a écrit :
Cela étant dit, dans le cas d'utilisation dont il est question ici, les comportements devraient être identiques (tant que env est dans le PATH ;-) ).
On est bien d'accord. Je cherche juste à comprendre comment il peut en être autrement avec autoconf. Que se soit avec « env » ou avec « export » (et dans ce cas c'est un builtin donc exit l'exemple bidon du $PATH).
J'en reviens à ce que j'ai dit hier (bien que n'étant pas spécialiste de autoconf): le fichier "configure.in" n'a pas l'air d'être interprété directement par un shell. C'est un fichier qui contient des macros M4. Le traitement qu'il subit n'est peut-être pas pour rien dans ce comportement ?
La ligne est recopiée presque telle quelle dans le configure : DATE=$(env LC_ALL=C date +'%A %x, %X %Z') qui est interprété par /bin/sh.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Bruno Tréguier
Le 10/01/2010 à 21:52, JKB a écrit :
La ligne est recopiée presque telle quelle dans le configure : DATE=$(env LC_ALL=C date +'%A %x, %X %Z') qui est interprété par /bin/sh.
Dans ce cas, pouvez-vous faire un test avec un "pseudo" configure contenant uniquement les lignes problématiques ?
$ chmod +x configure $ ./configure dimanche 10.01.2010, 22:55:37 MET $ sh configure dimanche 10.01.2010, 22:55:40 MET
Si cela fonctionne aussi chez vous, il faudrait chercher dans les instructions qui précèdent ces lignes dans votre "vrai" configure. Peut-être que dans un tel cas, un appel à un truc du genre "sh -x configure" pourrait aider ?
Cordialement,
Bruno
Le 10/01/2010 à 21:52, JKB a écrit :
La ligne est recopiée presque telle quelle dans le configure :
DATE=$(env LC_ALL=C date +'%A %x, %X %Z')
qui est interprété par /bin/sh.
Dans ce cas, pouvez-vous faire un test avec un "pseudo" configure
contenant uniquement les lignes problématiques ?
$ chmod +x configure
$ ./configure
dimanche 10.01.2010, 22:55:37 MET
$ sh configure
dimanche 10.01.2010, 22:55:40 MET
Si cela fonctionne aussi chez vous, il faudrait chercher dans les
instructions qui précèdent ces lignes dans votre "vrai" configure.
Peut-être que dans un tel cas, un appel à un truc du genre "sh -x
configure" pourrait aider ?
$ chmod +x configure $ ./configure dimanche 10.01.2010, 22:55:37 MET $ sh configure dimanche 10.01.2010, 22:55:40 MET
Si cela fonctionne aussi chez vous, il faudrait chercher dans les instructions qui précèdent ces lignes dans votre "vrai" configure. Peut-être que dans un tel cas, un appel à un truc du genre "sh -x configure" pourrait aider ?
Cordialement,
Bruno
JKB
Le 10-01-2010, ? propos de Re: LC_ALL dans un script configure, Bruno Tréguier ?crivait dans fr.comp.os.unix :
Le 10/01/2010 à 21:52, JKB a écrit :
La ligne est recopiée presque telle quelle dans le configure : DATE=$(env LC_ALL=C date +'%A %x, %X %Z') qui est interprété par /bin/sh.
Dans ce cas, pouvez-vous faire un test avec un "pseudo" configure contenant uniquement les lignes problématiques ?
$ chmod +x configure $ ./configure dimanche 10.01.2010, 22:55:37 MET $ sh configure dimanche 10.01.2010, 22:55:40 MET
Si cela fonctionne aussi chez vous, il faudrait chercher dans les instructions qui précèdent ces lignes dans votre "vrai" configure. Peut-être que dans un tel cas, un appel à un truc du genre "sh -x configure" pourrait aider ?
M'étonnerait ça ;-) Il y a 6000 lignes de script avant. Autant chercher une aiguille dans une botte de foin...
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 10-01-2010, ? propos de
Re: LC_ALL dans un script configure,
Bruno Tréguier ?crivait dans fr.comp.os.unix :
Le 10/01/2010 à 21:52, JKB a écrit :
La ligne est recopiée presque telle quelle dans le configure :
DATE=$(env LC_ALL=C date +'%A %x, %X %Z')
qui est interprété par /bin/sh.
Dans ce cas, pouvez-vous faire un test avec un "pseudo" configure
contenant uniquement les lignes problématiques ?
$ chmod +x configure
$ ./configure
dimanche 10.01.2010, 22:55:37 MET
$ sh configure
dimanche 10.01.2010, 22:55:40 MET
Si cela fonctionne aussi chez vous, il faudrait chercher dans les
instructions qui précèdent ces lignes dans votre "vrai" configure.
Peut-être que dans un tel cas, un appel à un truc du genre "sh -x
configure" pourrait aider ?
M'étonnerait ça ;-) Il y a 6000 lignes de script avant. Autant
chercher une aiguille dans une botte de foin...
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
$ chmod +x configure $ ./configure dimanche 10.01.2010, 22:55:37 MET $ sh configure dimanche 10.01.2010, 22:55:40 MET
Si cela fonctionne aussi chez vous, il faudrait chercher dans les instructions qui précèdent ces lignes dans votre "vrai" configure. Peut-être que dans un tel cas, un appel à un truc du genre "sh -x configure" pourrait aider ?
M'étonnerait ça ;-) Il y a 6000 lignes de script avant. Autant chercher une aiguille dans une botte de foin...
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
$ chmod +x configure $ ./configure dimanche 10.01.2010, 22:55:37 MET $ sh configure dimanche 10.01.2010, 22:55:40 MET
Si cela fonctionne aussi chez vous, il faudrait chercher dans les instructions qui précèdent ces lignes dans votre "vrai" configure. Peut-être que dans un tel cas, un appel à un truc du genre "sh -x configure" pourrait aider ?
M'étonnerait ça ;-) Il y a 6000 lignes de script avant. Autant chercher une aiguille dans une botte de foin...
Bon... Par dichotomie, alors, en déplaçant les lignes en question à différents endroits du fichier ? Même avec 6000 lignes, en une dizaine d'essais, on doit pouvoir cerner l'endroit du fichier qui modifie le comportement, non ?
Enfin personnellement c'est comme ça que je procéderais. C'est un peu bourrin, mais ça devrait être efficace...
$ chmod +x configure
$ ./configure
dimanche 10.01.2010, 22:55:37 MET
$ sh configure
dimanche 10.01.2010, 22:55:40 MET
Si cela fonctionne aussi chez vous, il faudrait chercher dans les
instructions qui précèdent ces lignes dans votre "vrai" configure.
Peut-être que dans un tel cas, un appel à un truc du genre "sh -x
configure" pourrait aider ?
M'étonnerait ça ;-) Il y a 6000 lignes de script avant. Autant
chercher une aiguille dans une botte de foin...
Bon... Par dichotomie, alors, en déplaçant les lignes en question à
différents endroits du fichier ? Même avec 6000 lignes, en une dizaine
d'essais, on doit pouvoir cerner l'endroit du fichier qui modifie le
comportement, non ?
Enfin personnellement c'est comme ça que je procéderais. C'est un peu
bourrin, mais ça devrait être efficace...
$ chmod +x configure $ ./configure dimanche 10.01.2010, 22:55:37 MET $ sh configure dimanche 10.01.2010, 22:55:40 MET
Si cela fonctionne aussi chez vous, il faudrait chercher dans les instructions qui précèdent ces lignes dans votre "vrai" configure. Peut-être que dans un tel cas, un appel à un truc du genre "sh -x configure" pourrait aider ?
M'étonnerait ça ;-) Il y a 6000 lignes de script avant. Autant chercher une aiguille dans une botte de foin...
Bon... Par dichotomie, alors, en déplaçant les lignes en question à différents endroits du fichier ? Même avec 6000 lignes, en une dizaine d'essais, on doit pouvoir cerner l'endroit du fichier qui modifie le comportement, non ?
Enfin personnellement c'est comme ça que je procéderais. C'est un peu bourrin, mais ça devrait être efficace...
Cordialement,
Bruno
JKB
Le 10-01-2010, ? propos de Re: LC_ALL dans un script configure, Bruno Tréguier ?crivait dans fr.comp.os.unix :
$ chmod +x configure $ ./configure dimanche 10.01.2010, 22:55:37 MET $ sh configure dimanche 10.01.2010, 22:55:40 MET
Si cela fonctionne aussi chez vous, il faudrait chercher dans les instructions qui précèdent ces lignes dans votre "vrai" configure. Peut-être que dans un tel cas, un appel à un truc du genre "sh -x configure" pourrait aider ?
M'étonnerait ça ;-) Il y a 6000 lignes de script avant. Autant chercher une aiguille dans une botte de foin...
Bon... Par dichotomie, alors, en déplaçant les lignes en question à différents endroits du fichier ? Même avec 6000 lignes, en une dizaine d'essais, on doit pouvoir cerner l'endroit du fichier qui modifie le comportement, non ?
Enfin personnellement c'est comme ça que je procéderais. C'est un peu bourrin, mais ça devrait être efficace...
Moi aussi, mais il me faut mettre ça dans ma TODO list. Tout de suite, j'ai autre chose à faire :-(
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 10-01-2010, ? propos de
Re: LC_ALL dans un script configure,
Bruno Tréguier ?crivait dans fr.comp.os.unix :
$ chmod +x configure
$ ./configure
dimanche 10.01.2010, 22:55:37 MET
$ sh configure
dimanche 10.01.2010, 22:55:40 MET
Si cela fonctionne aussi chez vous, il faudrait chercher dans les
instructions qui précèdent ces lignes dans votre "vrai" configure.
Peut-être que dans un tel cas, un appel à un truc du genre "sh -x
configure" pourrait aider ?
M'étonnerait ça ;-) Il y a 6000 lignes de script avant. Autant
chercher une aiguille dans une botte de foin...
Bon... Par dichotomie, alors, en déplaçant les lignes en question à
différents endroits du fichier ? Même avec 6000 lignes, en une dizaine
d'essais, on doit pouvoir cerner l'endroit du fichier qui modifie le
comportement, non ?
Enfin personnellement c'est comme ça que je procéderais. C'est un peu
bourrin, mais ça devrait être efficace...
Moi aussi, mais il me faut mettre ça dans ma TODO list. Tout de
suite, j'ai autre chose à faire :-(
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
$ chmod +x configure $ ./configure dimanche 10.01.2010, 22:55:37 MET $ sh configure dimanche 10.01.2010, 22:55:40 MET
Si cela fonctionne aussi chez vous, il faudrait chercher dans les instructions qui précèdent ces lignes dans votre "vrai" configure. Peut-être que dans un tel cas, un appel à un truc du genre "sh -x configure" pourrait aider ?
M'étonnerait ça ;-) Il y a 6000 lignes de script avant. Autant chercher une aiguille dans une botte de foin...
Bon... Par dichotomie, alors, en déplaçant les lignes en question à différents endroits du fichier ? Même avec 6000 lignes, en une dizaine d'essais, on doit pouvoir cerner l'endroit du fichier qui modifie le comportement, non ?
Enfin personnellement c'est comme ça que je procéderais. C'est un peu bourrin, mais ça devrait être efficace...
Moi aussi, mais il me faut mettre ça dans ma TODO list. Tout de suite, j'ai autre chose à faire :-(
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Bruno Tréguier
JKB wrote:
Enfin personnellement c'est comme ça que je procéderais. C'est un peu bourrin, mais ça devrait être efficace...
Moi aussi, mais il me faut mettre ça dans ma TODO list. Tout de suite, j'ai autre chose à faire :-(
Pas de souci, j'arriverai à dormir quand-même (enfin je pense). ;-) Mais c'est vrai que le résultat des courses m'intéresse...
A l'occasion, donc.
Bonne journée !
Cordialement,
Bruno
JKB wrote:
Enfin personnellement c'est comme ça que je procéderais. C'est un peu
bourrin, mais ça devrait être efficace...
Moi aussi, mais il me faut mettre ça dans ma TODO list. Tout de
suite, j'ai autre chose à faire :-(
Pas de souci, j'arriverai à dormir quand-même (enfin je pense). ;-)
Mais c'est vrai que le résultat des courses m'intéresse...
