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, ? propos de Re: LC_ALL dans un script configure, Benoit Izac ?crivait dans fr.comp.os.unix :
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 ?).
C'est un /bin/sh qui est chez moi un lien vers bash. Sous Solaris, le sh est un vrai sh avec tout ce que ça implique de joyeusetés... et le problème est similaire ;-)
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,
Benoit Izac ?crivait dans fr.comp.os.unix :
Bonjour,
le 10/01/2010 à 13:06, JKB a écrit dans le message
<slrnhkjglq.mka.knatschke@rayleigh.systella.fr> :
| `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 ?).
C'est un /bin/sh qui est chez moi un lien vers bash. Sous Solaris,
le sh est un vrai sh avec tout ce que ça implique de joyeusetés...
et le problème est similaire ;-)
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, Benoit Izac ?crivait dans fr.comp.os.unix :
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 ?).
C'est un /bin/sh qui est chez moi un lien vers bash. Sous Solaris, le sh est un vrai sh avec tout ce que ça implique de joyeusetés... et le problème est similaire ;-)
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.
Benoit Izac
Bonjour,
le 10/01/2010 à 14:16, Nicolas George a écrit dans le message <4b49d332$0$29840$ :
| 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.
Effectivement. Par contre, j'ai du mal à saisir la différence entre
1) VAR=1 program 2) env VAR=1 program 3) VAR=1; export VAR; program
2) n'exporte pas VAR, donc le shell courant et les commandes qui suivent n'en on pas connaissance. Mais pour 1) ?
La seule chose que je peux lire est dans SUS pour env(1) :
| Some have suggested that env is redundant since the same effect is | achieved by: | | name=value ... utility [ argument ... ] | | The example is equivalent to env when an environment variable is being | added to the environment of the command, but not when the environment | is being set to the given value. The env utility also writes out the | current environment if invoked without arguments. There is sufficient | functionality beyond what the example provides to justify inclusion of | env.
Malheureusement je n'arrive pas à reproduire cela : % env VAR=1 dash -c '/usr/bin/printenv VAR' 1 % env VAR=1 dash -c 'VAR=2 /usr/bin/printenv VAR' 2
J'ai essayé aussi en me faisant un petit programme qui regarde extern char **environ de unistd.h mais je ne vois aucune différence.
-- Benoit Izac
Bonjour,
le 10/01/2010 à 14:16, Nicolas George a écrit dans le message
<4b49d332$0$29840$426a74cc@news.free.fr> :
| 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.
Effectivement. Par contre, j'ai du mal à saisir la différence entre
1) VAR=1 program
2) env VAR=1 program
3) VAR=1; export VAR; program
2) n'exporte pas VAR, donc le shell courant et les commandes qui suivent
n'en on pas connaissance. Mais pour 1) ?
La seule chose que je peux lire est dans SUS pour env(1) :
| Some have suggested that env is redundant since the same effect is
| achieved by:
|
| name=value ... utility [ argument ... ]
|
| The example is equivalent to env when an environment variable is being
| added to the environment of the command, but not when the environment
| is being set to the given value. The env utility also writes out the
| current environment if invoked without arguments. There is sufficient
| functionality beyond what the example provides to justify inclusion of
| env.
Malheureusement je n'arrive pas à reproduire cela :
% env VAR=1 dash -c '/usr/bin/printenv VAR'
1
% env VAR=1 dash -c 'VAR=2 /usr/bin/printenv VAR'
2
J'ai essayé aussi en me faisant un petit programme qui regarde
extern char **environ de unistd.h mais je ne vois aucune différence.
le 10/01/2010 à 14:16, Nicolas George a écrit dans le message <4b49d332$0$29840$ :
| 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.
Effectivement. Par contre, j'ai du mal à saisir la différence entre
1) VAR=1 program 2) env VAR=1 program 3) VAR=1; export VAR; program
2) n'exporte pas VAR, donc le shell courant et les commandes qui suivent n'en on pas connaissance. Mais pour 1) ?
La seule chose que je peux lire est dans SUS pour env(1) :
| Some have suggested that env is redundant since the same effect is | achieved by: | | name=value ... utility [ argument ... ] | | The example is equivalent to env when an environment variable is being | added to the environment of the command, but not when the environment | is being set to the given value. The env utility also writes out the | current environment if invoked without arguments. There is sufficient | functionality beyond what the example provides to justify inclusion of | env.
Malheureusement je n'arrive pas à reproduire cela : % env VAR=1 dash -c '/usr/bin/printenv VAR' 1 % env VAR=1 dash -c 'VAR=2 /usr/bin/printenv VAR' 2
J'ai essayé aussi en me faisant un petit programme qui regarde extern char **environ de unistd.h mais je ne vois aucune différence.
-- Benoit Izac
Nicolas George
Benoit Izac wrote in message :
1) VAR=1 program 2) env VAR=1 program 3) VAR=1; export VAR; program
2) n'exporte pas VAR, donc le shell courant et les commandes qui suivent n'en on pas connaissance. Mais pour 1) ?
Il te suffit d'essayer, avec un programme visiblement sensible à une variable d'environnement, comme par exemple :
ssecem ~ $ SSH_AUTH_SOCK=/dev/null ssh-add -l; ssh-add -l Could not open a connection to your authentication agent. 1024 <snip> /home/cigaes/.ssh/id_dsa (DSA)
ssecem ~ $ SSH_AUTH_SOCK=/dev/null; export SSH_AUTH_SOCK; ssh-add -l; ssh-add -l Could not open a connection to your authentication agent. Could not open a connection to your authentication agent.
| The example is equivalent to env when an environment variable is being | added to the environment of the command, but not when the environment | is being set to the given value. The env utility also writes out the | current environment if invoked without arguments. There is sufficient | functionality beyond what the example provides to justify inclusion of | env. Malheureusement je n'arrive pas à reproduire cela : % env VAR=1 dash -c '/usr/bin/printenv VAR' 1 % env VAR=1 dash -c 'VAR=2 /usr/bin/printenv VAR' 2
Je ne vois pas ce que ton exemple essaie de prouver.
Benoit Izac wrote in message <w531vhyromi.fsf@izac.org>:
1) VAR=1 program
2) env VAR=1 program
3) VAR=1; export VAR; program
2) n'exporte pas VAR, donc le shell courant et les commandes qui suivent
n'en on pas connaissance. Mais pour 1) ?
Il te suffit d'essayer, avec un programme visiblement sensible à une
variable d'environnement, comme par exemple :
ssecem ~ $ SSH_AUTH_SOCK=/dev/null ssh-add -l; ssh-add -l
Could not open a connection to your authentication agent.
1024 <snip> /home/cigaes/.ssh/id_dsa (DSA)
ssecem ~ $ SSH_AUTH_SOCK=/dev/null; export SSH_AUTH_SOCK; ssh-add -l; ssh-add -l
Could not open a connection to your authentication agent.
Could not open a connection to your authentication agent.
| The example is equivalent to env when an environment variable is being
| added to the environment of the command, but not when the environment
| is being set to the given value. The env utility also writes out the
| current environment if invoked without arguments. There is sufficient
| functionality beyond what the example provides to justify inclusion of
| env.
Malheureusement je n'arrive pas à reproduire cela :
% env VAR=1 dash -c '/usr/bin/printenv VAR'
1
% env VAR=1 dash -c 'VAR=2 /usr/bin/printenv VAR'
2
Je ne vois pas ce que ton exemple essaie de prouver.
1) VAR=1 program 2) env VAR=1 program 3) VAR=1; export VAR; program
2) n'exporte pas VAR, donc le shell courant et les commandes qui suivent n'en on pas connaissance. Mais pour 1) ?
Il te suffit d'essayer, avec un programme visiblement sensible à une variable d'environnement, comme par exemple :
ssecem ~ $ SSH_AUTH_SOCK=/dev/null ssh-add -l; ssh-add -l Could not open a connection to your authentication agent. 1024 <snip> /home/cigaes/.ssh/id_dsa (DSA)
ssecem ~ $ SSH_AUTH_SOCK=/dev/null; export SSH_AUTH_SOCK; ssh-add -l; ssh-add -l Could not open a connection to your authentication agent. Could not open a connection to your authentication agent.
| The example is equivalent to env when an environment variable is being | added to the environment of the command, but not when the environment | is being set to the given value. The env utility also writes out the | current environment if invoked without arguments. There is sufficient | functionality beyond what the example provides to justify inclusion of | env. Malheureusement je n'arrive pas à reproduire cela : % env VAR=1 dash -c '/usr/bin/printenv VAR' 1 % env VAR=1 dash -c 'VAR=2 /usr/bin/printenv VAR' 2
Je ne vois pas ce que ton exemple essaie de prouver.
Benoit Izac
Bonjour,
le 10/01/2010 à 16:49, Nicolas George a écrit dans le message <4b49f719$0$677$ :
1) VAR=1 program 2) env VAR=1 program 3) VAR=1; export VAR; program
2) n'exporte pas VAR, donc le shell courant et les commandes qui suivent n'en on pas connaissance. Mais pour 1) ?
Il te suffit d'essayer, avec un programme visiblement sensible à une variable d'environnement, comme par exemple :
ssecem ~ $ SSH_AUTH_SOCK=/dev/null ssh-add -l; ssh-add -l Could not open a connection to your authentication agent. 1024 <snip> /home/cigaes/.ssh/id_dsa (DSA)
Donc on n'est bien d'accord que 1) et 2) sont équivalent ?
Mais si je comprend bien ce qui est dit ici (c'est pas bien d'avoir supprimer le début) :
| Some have suggested that env is redundant since the same effect is | achieved by: | | name=value ... utility [ argument ... ] |
| The example is equivalent to env when an environment variable is being | added to the environment of the command, but not when the environment | is being set to the given value. The env utility also writes out the | current environment if invoked without arguments. There is sufficient | functionality beyond what the example provides to justify inclusion of | env. Malheureusement je n'arrive pas à reproduire cela : % env VAR=1 dash -c '/usr/bin/printenv VAR' 1 % env VAR=1 dash -c 'VAR=2 /usr/bin/printenv VAR' 2
Je ne vois pas ce que ton exemple essaie de prouver.
Si je comprends bien, il est dit que c'est équivalent (VAR=1 cmd et env VAR=1 cmd) si l'on ajoute une variable à l'environnement mais pas si l'environnement configuré à la valeur donnée.
J'essaye juste de reproduire ce qui ce passe avec autoconf :
LC_ALL=FR_fr date -> LC_ALL est défini par autoconf à C donc date est en anglais env LC_ALL=FR_fr date -> LC_ALL est modifié, date est en français.
-- Benoit Izac
Bonjour,
le 10/01/2010 à 16:49, Nicolas George a écrit dans le message
<4b49f719$0$677$426a74cc@news.free.fr> :
1) VAR=1 program
2) env VAR=1 program
3) VAR=1; export VAR; program
2) n'exporte pas VAR, donc le shell courant et les commandes qui suivent
n'en on pas connaissance. Mais pour 1) ?
Il te suffit d'essayer, avec un programme visiblement sensible à une
variable d'environnement, comme par exemple :
ssecem ~ $ SSH_AUTH_SOCK=/dev/null ssh-add -l; ssh-add -l
Could not open a connection to your authentication agent.
1024 <snip> /home/cigaes/.ssh/id_dsa (DSA)
Donc on n'est bien d'accord que 1) et 2) sont équivalent ?
Mais si je comprend bien ce qui est dit ici (c'est pas bien d'avoir
supprimer le début) :
| Some have suggested that env is redundant since the same effect is
| achieved by:
|
| name=value ... utility [ argument ... ]
|
| The example is equivalent to env when an environment variable is being
| added to the environment of the command, but not when the environment
| is being set to the given value. The env utility also writes out the
| current environment if invoked without arguments. There is sufficient
| functionality beyond what the example provides to justify inclusion of
| env.
Malheureusement je n'arrive pas à reproduire cela :
% env VAR=1 dash -c '/usr/bin/printenv VAR'
1
% env VAR=1 dash -c 'VAR=2 /usr/bin/printenv VAR'
2
Je ne vois pas ce que ton exemple essaie de prouver.
Si je comprends bien, il est dit que c'est équivalent (VAR=1 cmd et env
VAR=1 cmd) si l'on ajoute une variable à l'environnement mais pas si
l'environnement configuré à la valeur donnée.
J'essaye juste de reproduire ce qui ce passe avec autoconf :
LC_ALL=FR_fr date -> LC_ALL est défini par autoconf à C donc date est
en anglais
env LC_ALL=FR_fr date -> LC_ALL est modifié, date est en français.
le 10/01/2010 à 16:49, Nicolas George a écrit dans le message <4b49f719$0$677$ :
1) VAR=1 program 2) env VAR=1 program 3) VAR=1; export VAR; program
2) n'exporte pas VAR, donc le shell courant et les commandes qui suivent n'en on pas connaissance. Mais pour 1) ?
Il te suffit d'essayer, avec un programme visiblement sensible à une variable d'environnement, comme par exemple :
ssecem ~ $ SSH_AUTH_SOCK=/dev/null ssh-add -l; ssh-add -l Could not open a connection to your authentication agent. 1024 <snip> /home/cigaes/.ssh/id_dsa (DSA)
Donc on n'est bien d'accord que 1) et 2) sont équivalent ?
Mais si je comprend bien ce qui est dit ici (c'est pas bien d'avoir supprimer le début) :
| Some have suggested that env is redundant since the same effect is | achieved by: | | name=value ... utility [ argument ... ] |
| The example is equivalent to env when an environment variable is being | added to the environment of the command, but not when the environment | is being set to the given value. The env utility also writes out the | current environment if invoked without arguments. There is sufficient | functionality beyond what the example provides to justify inclusion of | env. Malheureusement je n'arrive pas à reproduire cela : % env VAR=1 dash -c '/usr/bin/printenv VAR' 1 % env VAR=1 dash -c 'VAR=2 /usr/bin/printenv VAR' 2
Je ne vois pas ce que ton exemple essaie de prouver.
Si je comprends bien, il est dit que c'est équivalent (VAR=1 cmd et env VAR=1 cmd) si l'on ajoute une variable à l'environnement mais pas si l'environnement configuré à la valeur donnée.
J'essaye juste de reproduire ce qui ce passe avec autoconf :
LC_ALL=FR_fr date -> LC_ALL est défini par autoconf à C donc date est en anglais env LC_ALL=FR_fr date -> LC_ALL est modifié, date est en français.
-- Benoit Izac
Stephane CHAZELAS
2010-01-10, 13:34(+00), JKB: [...]
C'est un /bin/sh qui est chez moi un lien vers bash. Sous Solaris, le sh est un vrai sh avec tout ce que ça implique de joyeusetés... et le problème est similaire ;-)
[...]
En l'occurrence, bash est un vrai sh alors que le /bin/sh est un Bourne shell, donc pas un vrai sh (au sens du standard Unix ou POSIX).
Et le Bourne shell ne reconnait pas la syntaxe $(...), BTW. A mon avis, le probleme se trouve ailleurs (ces variables sont redefinies ailleurs, ou "date" est refefini...), lancer le script avec sh -x aiderait peut-etre. VAR=value cmd marche avec tous les shells Bourne-like.
-- Stéphane
2010-01-10, 13:34(+00), JKB:
[...]
C'est un /bin/sh qui est chez moi un lien vers bash. Sous Solaris,
le sh est un vrai sh avec tout ce que ça implique de joyeusetés...
et le problème est similaire ;-)
[...]
En l'occurrence, bash est un vrai sh alors que le /bin/sh est un
Bourne shell, donc pas un vrai sh (au sens du standard Unix ou
POSIX).
Et le Bourne shell ne reconnait pas la syntaxe $(...), BTW. A
mon avis, le probleme se trouve ailleurs (ces variables sont
redefinies ailleurs, ou "date" est refefini...), lancer le
script avec sh -x aiderait peut-etre. VAR=value cmd marche avec
tous les shells Bourne-like.
C'est un /bin/sh qui est chez moi un lien vers bash. Sous Solaris, le sh est un vrai sh avec tout ce que ça implique de joyeusetés... et le problème est similaire ;-)
[...]
En l'occurrence, bash est un vrai sh alors que le /bin/sh est un Bourne shell, donc pas un vrai sh (au sens du standard Unix ou POSIX).
Et le Bourne shell ne reconnait pas la syntaxe $(...), BTW. A mon avis, le probleme se trouve ailleurs (ces variables sont redefinies ailleurs, ou "date" est refefini...), lancer le script avec sh -x aiderait peut-etre. VAR=value cmd marche avec tous les shells Bourne-like.
-- Stéphane
Nicolas George
Benoit Izac wrote in message :
Donc on n'est bien d'accord que 1) et 2) sont équivalent ?
Non. Le 2 invoque le programme env de ton path. Rien ne dit qu'il ne fait pas n'importe quoi. Le 1 est interprété directement par le shell.
Si je comprends bien
... alors tu pourrais commencer par expliquer, parce que ce paragraphe est totalement obscur.
Benoit Izac wrote in message <w53wrzprhuw.fsf@izac.org>:
Donc on n'est bien d'accord que 1) et 2) sont équivalent ?
Non. Le 2 invoque le programme env de ton path. Rien ne dit qu'il ne fait
pas n'importe quoi. Le 1 est interprété directement par le shell.
Si je comprends bien
... alors tu pourrais commencer par expliquer, parce que ce paragraphe est
totalement obscur.
Donc on n'est bien d'accord que 1) et 2) sont équivalent ?
Non. Le 2 invoque le programme env de ton path. Rien ne dit qu'il ne fait pas n'importe quoi. Le 1 est interprété directement par le shell.
Si je comprends bien
... alors tu pourrais commencer par expliquer, parce que ce paragraphe est totalement obscur.
Stephane CHAZELAS
2010-01-10, 18:26(+01), Benoit Izac:
Bonjour,
le 10/01/2010 à 16:49, Nicolas George a écrit dans le message <4b49f719$0$677$ :
1) VAR=1 program 2) env VAR=1 program 3) VAR=1; export VAR; program
2) n'exporte pas VAR, donc le shell courant et les commandes qui suivent n'en on pas connaissance. Mais pour 1) ?
Il te suffit d'essayer, avec un programme visiblement sensible à une variable d'environnement, comme par exemple :
ssecem ~ $ SSH_AUTH_SOCK=/dev/null ssh-add -l; ssh-add -l Could not open a connection to your authentication agent. 1024 <snip> /home/cigaes/.ssh/id_dsa (DSA)
Donc on n'est bien d'accord que 1) et 2) sont équivalent ?
Sont equivalent dans les shells POSIX a part pour les special builtins et dans les autres shells Bourne-like a part pour tous les builtins. Les comportements varient pour les fonctions.
env etant une commande externe, 2 implique un fork donc forcement ca affectera le comportement dans tous les cas pour les built-in.
Avec date, le probleme ne se pose pas toutefois.
-- Stéphane
2010-01-10, 18:26(+01), Benoit Izac:
Bonjour,
le 10/01/2010 à 16:49, Nicolas George a écrit dans le message
<4b49f719$0$677$426a74cc@news.free.fr> :
1) VAR=1 program
2) env VAR=1 program
3) VAR=1; export VAR; program
2) n'exporte pas VAR, donc le shell courant et les commandes qui suivent
n'en on pas connaissance. Mais pour 1) ?
Il te suffit d'essayer, avec un programme visiblement sensible à une
variable d'environnement, comme par exemple :
ssecem ~ $ SSH_AUTH_SOCK=/dev/null ssh-add -l; ssh-add -l
Could not open a connection to your authentication agent.
1024 <snip> /home/cigaes/.ssh/id_dsa (DSA)
Donc on n'est bien d'accord que 1) et 2) sont équivalent ?
Sont equivalent dans les shells POSIX a part pour les special
builtins et dans les autres shells Bourne-like a part pour tous
les builtins. Les comportements varient pour les fonctions.
env etant une commande externe, 2 implique un fork donc
forcement ca affectera le comportement dans tous les cas pour
les built-in.
le 10/01/2010 à 16:49, Nicolas George a écrit dans le message <4b49f719$0$677$ :
1) VAR=1 program 2) env VAR=1 program 3) VAR=1; export VAR; program
2) n'exporte pas VAR, donc le shell courant et les commandes qui suivent n'en on pas connaissance. Mais pour 1) ?
Il te suffit d'essayer, avec un programme visiblement sensible à une variable d'environnement, comme par exemple :
ssecem ~ $ SSH_AUTH_SOCK=/dev/null ssh-add -l; ssh-add -l Could not open a connection to your authentication agent. 1024 <snip> /home/cigaes/.ssh/id_dsa (DSA)
Donc on n'est bien d'accord que 1) et 2) sont équivalent ?
Sont equivalent dans les shells POSIX a part pour les special builtins et dans les autres shells Bourne-like a part pour tous les builtins. Les comportements varient pour les fonctions.
env etant une commande externe, 2 implique un fork donc forcement ca affectera le comportement dans tous les cas pour les built-in.
Avec date, le probleme ne se pose pas toutefois.
-- Stéphane
Benoit Izac
Bonjour,
le 10/01/2010 à 18:42, Nicolas George a écrit dans le message <4b4a1174$0$13104$ :
Donc on n'est bien d'accord que 1) et 2) sont équivalent ?
Non. Le 2 invoque le programme env de ton path. Rien ne dit qu'il ne fait pas n'importe quoi. Le 1 est interprété directement par le shell.
Si tu veux mais en tout cas la sortie de ta commande est la même donc j'en déduis que c'est équivalent. Montre moi un cas où ça ne l'est pas au lieu d'un « non ».
Si je comprends bien
... alors tu pourrais commencer par expliquer, parce que ce paragraphe est totalement obscur.
Je n'ai pas dit le contraire et c'est justement pour cela que j'ai des doutes. Maintenant, c'est pas moi qui l'ai écrit et c'est sensé être la référence pour toute implémentation respectant les standards POSIX.
-- Benoit Izac
Bonjour,
le 10/01/2010 à 18:42, Nicolas George a écrit dans le message
<4b4a1174$0$13104$426a74cc@news.free.fr> :
Donc on n'est bien d'accord que 1) et 2) sont équivalent ?
Non. Le 2 invoque le programme env de ton path. Rien ne dit qu'il ne fait
pas n'importe quoi. Le 1 est interprété directement par le shell.
Si tu veux mais en tout cas la sortie de ta commande est la même donc
j'en déduis que c'est équivalent. Montre moi un cas où ça ne l'est pas
au lieu d'un « non ».
Si je comprends bien
... alors tu pourrais commencer par expliquer, parce que ce paragraphe est
totalement obscur.
Je n'ai pas dit le contraire et c'est justement pour cela que j'ai des
doutes. Maintenant, c'est pas moi qui l'ai écrit et c'est sensé être la
référence pour toute implémentation respectant les standards POSIX.
le 10/01/2010 à 18:42, Nicolas George a écrit dans le message <4b4a1174$0$13104$ :
Donc on n'est bien d'accord que 1) et 2) sont équivalent ?
Non. Le 2 invoque le programme env de ton path. Rien ne dit qu'il ne fait pas n'importe quoi. Le 1 est interprété directement par le shell.
Si tu veux mais en tout cas la sortie de ta commande est la même donc j'en déduis que c'est équivalent. Montre moi un cas où ça ne l'est pas au lieu d'un « non ».
Si je comprends bien
... alors tu pourrais commencer par expliquer, parce que ce paragraphe est totalement obscur.
Je n'ai pas dit le contraire et c'est justement pour cela que j'ai des doutes. Maintenant, c'est pas moi qui l'ai écrit et c'est sensé être la référence pour toute implémentation respectant les standards POSIX.
-- Benoit Izac
Nicolas George
Benoit Izac wrote in message :
Si tu veux mais en tout cas la sortie de ta commande est la même donc j'en déduis que c'est équivalent.
ssecem ~ $ PATH=/bin ssecem ~ $ date Sun Jan 10 19:39:12 CET 2010 ssecem ~ $ LC_TIME=fr_FR date dimanche 10 janvier 2010, 19:39:16 (UTC+0100) ssecem ~ $ env LC_TIME=fr_FR date zsh: command not found: env
Benoit Izac wrote in message <w53skadrgr5.fsf@izac.org>:
Si tu veux mais en tout cas la sortie de ta commande est la même donc
j'en déduis que c'est équivalent.
ssecem ~ $ PATH=/bin
ssecem ~ $ date
Sun Jan 10 19:39:12 CET 2010
ssecem ~ $ LC_TIME=fr_FR date
dimanche 10 janvier 2010, 19:39:16 (UTC+0100)
ssecem ~ $ env LC_TIME=fr_FR date
zsh: command not found: env
Si tu veux mais en tout cas la sortie de ta commande est la même donc j'en déduis que c'est équivalent.
ssecem ~ $ PATH=/bin ssecem ~ $ date Sun Jan 10 19:39:12 CET 2010 ssecem ~ $ LC_TIME=fr_FR date dimanche 10 janvier 2010, 19:39:16 (UTC+0100) ssecem ~ $ env LC_TIME=fr_FR date zsh: command not found: env
Bruno Tréguier
Le 10/01/2010 à 19:39, Nicolas George a écrit :
ssecem ~ $ PATH=/bin ssecem ~ $ date Sun Jan 10 19:39:12 CET 2010 ssecem ~ $ LC_TIME=fr_FR date dimanche 10 janvier 2010, 19:39:16 (UTC+0100) ssecem ~ $ env LC_TIME=fr_FR date zsh: command not found: env
Bonsoir,
Puisqu'on est dans les exemples un peu extrêmes, j'en ai un autre. :-)
$ 123=undeuxtrois perl -e 'print "$ENV{123}n"' 123=undeuxtrois: command not found
Bon, ok, c'est pas courant de trouver des variables d'environnement commençant par un chiffre, c'est interdit par les shells type sh, ksh, bash, etc., mais pas par env, et certains langages peuvent les utiliser (comme perl, ci-dessus)...
Autre utilité de env: il est possible de supprimer des variables par ce biais.
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 ;-) ).
Cordialement,
Bruno
Le 10/01/2010 à 19:39, Nicolas George a écrit :
ssecem ~ $ PATH=/bin
ssecem ~ $ date
Sun Jan 10 19:39:12 CET 2010
ssecem ~ $ LC_TIME=fr_FR date
dimanche 10 janvier 2010, 19:39:16 (UTC+0100)
ssecem ~ $ env LC_TIME=fr_FR date
zsh: command not found: env
Bonsoir,
Puisqu'on est dans les exemples un peu extrêmes, j'en ai un autre. :-)
$ 123=undeuxtrois perl -e 'print "$ENV{123}n"'
123=undeuxtrois: command not found
Bon, ok, c'est pas courant de trouver des variables d'environnement
commençant par un chiffre, c'est interdit par les shells type sh, ksh,
bash, etc., mais pas par env, et certains langages peuvent les utiliser
(comme perl, ci-dessus)...
Autre utilité de env: il est possible de supprimer des variables par ce
biais.
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
;-) ).
ssecem ~ $ PATH=/bin ssecem ~ $ date Sun Jan 10 19:39:12 CET 2010 ssecem ~ $ LC_TIME=fr_FR date dimanche 10 janvier 2010, 19:39:16 (UTC+0100) ssecem ~ $ env LC_TIME=fr_FR date zsh: command not found: env
Bonsoir,
Puisqu'on est dans les exemples un peu extrêmes, j'en ai un autre. :-)
$ 123=undeuxtrois perl -e 'print "$ENV{123}n"' 123=undeuxtrois: command not found
Bon, ok, c'est pas courant de trouver des variables d'environnement commençant par un chiffre, c'est interdit par les shells type sh, ksh, bash, etc., mais pas par env, et certains langages peuvent les utiliser (comme perl, ci-dessus)...
Autre utilité de env: il est possible de supprimer des variables par ce biais.
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 ;-) ).
