Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

LC_ALL dans un script configure

27 réponses
Avatar
JKB
Bonjour à tous,

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.

10 réponses

1 2 3
Avatar
Benoit Izac
Bonjour,

le 09/01/2010 à 14:19, JKB a écrit dans le message
:

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.



En rajoutant « env », ça change quelque chose ?
env LC_TIME=fr_FR date +'%A %x, %X %Z'

--
Benoit Izac
Avatar
Bruno Tréguier
Le 09/01/2010 à 14:19, JKB a écrit :
Bonjour à tous,

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 :-(



Bonjour,

C'est effectivement assez bizarre, comme comportement. Quand vous lancez
les 2 premiers tests en ligne de commande, hors du script configure.in,
ça donne quoi ?

Quand je le fais ici, je n'ai pas de souci particulier:

$ DATE_FR=$(LC_ALL=fr_FR date +'%A %x, %X %Z')
$ echo $DATE_FR
samedi 09/01/10, 14:46:38 MET

$ DATE=$(LC_ALL=C date +'%A %x, %X %Z')
$ echo $DATE
Saturday 01/09/10, 14:47:40 MET

J'ai fait le test sur 3 machines différentes: 1 Debian Lenny, 1 Kubuntu
Karmic, 1 Solaris 10. Seule particularité, sur la Kubuntu, la variable
doit être positionnée à fr_FR.UTF-8 et non fr_FR tout court (cette
dernière n'est pas reonnue, et du coup la date renvoyée est en anglais,
mais pour tous les cas, même en ligne de commande).

Que donne la commande "locale" chez vous, et quel est le système ? C'est
le même dans tous les cas ?

Cordialement,

Bruno
Avatar
Benoit Izac
Dans le message , le09/01/2010 à 14:45, j'ai
écrit :

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.



En rajoutant « env », ça change quelque chose ?
env LC_TIME=fr_FR date +'%A %x, %X %Z'



Ou peut-être
DATE_FR=$(LC_ALL=fr_FR; export LC_ALL; date +'%A %x, %X %Z')

--
Benoit Izac
Avatar
JKB
Le 09-01-2010, ? propos de
Re: LC_ALL dans un script configure,
Bruno Tréguier ?crivait dans fr.comp.os.unix :
Le 09/01/2010 à 14:19, JKB a écrit :
Bonjour à tous,

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 :-(



Bonjour,

C'est effectivement assez bizarre, comme comportement. Quand vous lancez
les 2 premiers tests en ligne de commande, hors du script configure.in,
ça donne quoi ?

Quand je le fais ici, je n'ai pas de souci particulier:

$ DATE_FR=$(LC_ALL=fr_FR date +'%A %x, %X %Z')
$ echo $DATE_FR
samedi 09/01/10, 14:46:38 MET

$ DATE=$(LC_ALL=C date +'%A %x, %X %Z')
$ echo $DATE
Saturday 01/09/10, 14:47:40 MET

J'ai fait le test sur 3 machines différentes: 1 Debian Lenny, 1 Kubuntu
Karmic, 1 Solaris 10. Seule particularité, sur la Kubuntu, la variable
doit être positionnée à fr_FR.UTF-8 et non fr_FR tout court (cette
dernière n'est pas reonnue, et du coup la date renvoyée est en anglais,
mais pour tous les cas, même en ligne de commande).



En ligne de commande, ça fonctionne parfaitement :

cauchy:[~] > DATE_FR=$(LC_ALL=fr_FR date +'%A %x, %X %Z')
cauchy:[~] > echo $DATE_FR
samedi 09/01/2010, 18:40:28 CET
cauchy:[~] > DATE=$(LC_ALL=C date +'%A %x, %X %Z')
cauchy:[~] > echo $DATE
Saturday 01/09/10, 18:40:38 CET
cauchy:[~] >

Que donne la commande "locale" chez vous, et quel est le système ? C'est
le même dans tous les cas ?



Le système est un Linux Debian/testing à jour. J'ai un Solaris 9 sous
la main qui renvoie la même chose. Idem pour Solaris 10. Je n'ai pas
l'impression que ce problème soit un problème d'OS, mais plus une
bizarrerie d'autoconf. Ce que je ne saisi pas, c'est que le script
configure comporte bien

DATE_FR=$(LC_ALL=fr_FR date +'%A %x, %X %Z')
DATE=$(LC_ALL=C date +'%A %x, %X %Z')

ce qui correspond bien à ce que j'ai écrit dans mon configure.in...

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.
Avatar
JKB
Le 09-01-2010, ? propos de
Re: LC_ALL dans un script configure,
Benoit Izac ?crivait dans fr.comp.os.unix :
Bonjour,

le 09/01/2010 à 14:19, JKB a écrit dans le message
:

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.



En rajoutant « env », ça change quelque chose ?
env LC_TIME=fr_FR date +'%A %x, %X %Z'



Tiens, avec env, ça fonctionne. Je ne chercherai pas à savoir ce
soir pourquoi... En tout cas, merci pour tout.

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.
Avatar
Bruno Tréguier
Le 09/01/2010 à 19:02, JKB a écrit :

À 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.


En rajoutant « env », ça change quelque chose ?
env LC_TIME=fr_FR date +'%A %x, %X %Z'



Tiens, avec env, ça fonctionne. Je ne chercherai pas à savoir ce
soir pourquoi... En tout cas, merci pour tout.



Le fichier configure.in n'est peut-être pas interprété directement par
bash ? Je ne suis pas un spécialiste de autoconf, mais il semble y avoir
des macros M4 là-dedans... Cela dit je suis aussi perplexe que vous
concernant la solution avec "env"...

Benoît, vous avez une explication ? ;-)

Cordialement,

Bruno
Avatar
Benoit Izac
Bonjour,

le 09/01/2010 à 20:26, Bruno Tréguier a écrit dans le message
<hial8j$qnq$ :

À 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.


En rajoutant « env », ça change quelque chose ?
env LC_TIME=fr_FR date +'%A %x, %X %Z'



Tiens, avec env, ça fonctionne. Je ne chercherai pas à savoir ce
soir pourquoi... En tout cas, merci pour tout.



Le fichier configure.in n'est peut-être pas interprété directement par
bash ? Je ne suis pas un spécialiste de autoconf, mais il semble y
avoir des macros M4 là-dedans... Cela dit je suis aussi perplexe que
vous concernant la solution avec "env"...

Benoît, vous avez une explication ? ;-)



Pas vraiment, autoconf est trop complexe pour moi néanmoins, dans la
documentation au format info on peut lire :

| 11.10 Special Shell Variables
| ============================ | [...]
| `LANG'
| `LC_ALL'
| `LC_COLLATE'
| `LC_CTYPE'
| `LC_MESSAGES'
| `LC_MONETARY'
| `LC_NUMERIC'
| `LC_TIME'
| You should set all these variables to `C' because so much
| configuration code assumes the C locale and Posix requires that
| locale environment variables be set to `C' if the C locale is
| desired; `configure' scripts and M4sh do that for you. Export
| these variables after setting them.

C'est pourquoi j'aurais bien aimé savoir si l'instruction suivante
fonctionne :
DATE_FR=$(LC_ALL=fr_FR; export LC_ALL; date +'%A %x, %X %Z')

Au passage, LC_TIME suffit dans le cas de la commande « date ».

--
Benoit Izac
Avatar
JKB
Le 09-01-2010, ? propos de
Re: LC_ALL dans un script configure,
Benoit Izac ?crivait dans fr.comp.os.unix :
Bonjour,

le 09/01/2010 à 20:26, Bruno Tréguier a écrit dans le message
<hial8j$qnq$ :

À 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.


En rajoutant « env », ça change quelque chose ?
env LC_TIME=fr_FR date +'%A %x, %X %Z'



Tiens, avec env, ça fonctionne. Je ne chercherai pas à savoir ce
soir pourquoi... En tout cas, merci pour tout.



Le fichier configure.in n'est peut-être pas interprété directement par
bash ? Je ne suis pas un spécialiste de autoconf, mais il semble y
avoir des macros M4 là-dedans... Cela dit je suis aussi perplexe que
vous concernant la solution avec "env"...

Benoît, vous avez une explication ? ;-)



Pas vraiment, autoconf est trop complexe pour moi néanmoins, dans la
documentation au format info on peut lire :

| 11.10 Special Shell Variables
| ============================ >| [...]
| `LANG'
| `LC_ALL'
| `LC_COLLATE'
| `LC_CTYPE'
| `LC_MESSAGES'
| `LC_MONETARY'
| `LC_NUMERIC'
| `LC_TIME'
| You should set all these variables to `C' because so much
| configuration code assumes the C locale and Posix requires that
| locale environment variables be set to `C' if the C locale is
| desired; `configure' scripts and M4sh do that for you. Export
| these variables after setting them.

C'est pourquoi j'aurais bien aimé savoir si l'instruction suivante
fonctionne :
DATE_FR=$(LC_ALL=fr_FR; export LC_ALL; date +'%A %x, %X %Z')



Cette version fonctionne aussi.

Au passage, LC_TIME suffit dans le cas de la commande « date ».



Exact, mais en l'occurrence, je n'ai pas fait dans le détail parce
qu'il y avait d'autres trucs plus importants à corriger...

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.
Avatar
Benoit Izac
Bonjour,

le 10/01/2010 à 13:06, JKB a écrit dans le message
:

| `LC_TIME'
| You should set all these variables to `C' because so much
| configuration code assumes the C locale and Posix requires that
| locale environment variables be set to `C' if the C locale is
| desired; `configure' scripts and M4sh do that for you. Export
| these variables after setting them.

C'est pourquoi j'aurais bien aimé savoir si l'instruction suivante
fonctionne :
DATE_FR=$(LC_ALL=fr_FR; export LC_ALL; date +'%A %x, %X %Z')



Cette version fonctionne aussi.



Je pense donc que l'explication est là. Dans la doc (que j'ai parcouru
plus que transversalement), on trouve aussi :

| 11.7 Assignments
| =============== | [...]
| Don't rely on the following to find `subdir/program':
|
| PATH=subdir$PATH_SEPARATOR$PATH program
|
| as this does not work with Zsh 3.0.6. Use something like this instead:
|
| (PATH=subdir$PATH_SEPARATOR$PATH; export PATH; exec program)

Après je ne sais pas quel shell est utilisé pour l'exécution des
instructions (/bin/sh ?).

--
Benoit Izac
Avatar
Nicolas George
Benoit Izac wrote in message :
| Don't rely on the following to find `subdir/program':
| PATH=subdir$PATH_SEPARATOR$PATH program



Ce n'est pas la même chose. La syntaxe « VAR=value program » définit VAR
dans l'environnement de program, mais pas dans celui du shell ambiant. Or
justement, ce n'est pas program qui utilise $PATH mais le shell ambiant.
1 2 3