Un programme en C peut placer avec setenv placer une variable
d'environnement avec un "-" dedans. Si depuis ce programme, on invoque
un shell, la commande env montre que cette variable est bien
présente. Toutefois, il ne semble pas possible de la récupérer (même
avec ${...}).
A-t-on le droit de placer un "-" dans une variable d'environnement ?
Cela semble casser certains programmes qui dumpent l'environnement et
s'attendent à pouvoir relire le résultat :
http://bugs.gentoo.org/show_bug.cgi?id=210580
Il me semble que le programme aura de toute façon d'autres soucis avec
les espaces et caractères spéciaux contenus dans les valeurs. La sortie
de env ne me semble pas pouvoir être sourcée sans précautions, non ?
--
I AM NOT A DENTIST
I AM NOT A DENTIST
I AM NOT A DENTIST
-+- Bart Simpson on chalkboard in episode 7F24
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
2008-06-29, 15:49(+02), Vincent Bernat:
Coucou !
Un programme en C peut placer avec setenv placer une variable d'environnement avec un "-" dedans. Si depuis ce programme, on invoque un shell, la commande env montre que cette variable est bien présente. Toutefois, il ne semble pas possible de la récupérer (même avec ${...}).
A-t-on le droit de placer un "-" dans une variable d'environnement ?
L'environnement est une liste de zero-terminated strings exactement comme la liste des arguments. argv et envp sont similaire.
C'est seulement par convention qu'on met en general un "=" dans ces strings.
Les shells, a l'initialisation, pour chacune de ces strings pour lesquelles ce qui est a gauche du premier "=" est compatible, creent une variable shell de ce nom.
Dans l'environment, on peut tres bien avoir "=foo", "n*=xxx"...
Certains shells enlevent de l'environnement (c'est a dire ne le passeront pas dans l'envp des commandes qu'ils executent) les chaines qu'ils ne peuvent pas transformer en variables.
On recommende de ne mettre dans l'environnement que de xxx=yyy où xxx peut etre une variable shell standard (alphanumerique, underscore, ne commencant pas par un chiffre) et de preference qui ne correspondent pas a une variable speciale des shell communs (IFS, SECONDS, TMOUT, path...)
Cela semble casser certains programmes qui dumpent l'environnement et s'attendent à pouvoir relire le résultat : http://bugs.gentoo.org/show_bug.cgi?id!0580
Il me semble que le programme aura de toute façon d'autres soucis avec les espaces et caractères spéciaux contenus dans les valeurs. La sortie de env ne me semble pas pouvoir être sourcée sans précautions, non ?
Non, completement pas. Exemple typique: la variable TERMCAP dont la valeur contient plusieurs lignes quand elle est definie.
La sortie de export -p est censee l'etre, mais voir:
http://groups.google.com/group/gnu.bash.bug/browse_thread/thread/22e185aff9bed206 et http://bugs.debian.org/480371
-- Stéphane
2008-06-29, 15:49(+02), Vincent Bernat:
Coucou !
Un programme en C peut placer avec setenv placer une variable
d'environnement avec un "-" dedans. Si depuis ce programme, on invoque
un shell, la commande env montre que cette variable est bien
présente. Toutefois, il ne semble pas possible de la récupérer (même
avec ${...}).
A-t-on le droit de placer un "-" dans une variable d'environnement ?
L'environnement est une liste de zero-terminated strings
exactement comme la liste des arguments. argv et envp sont
similaire.
C'est seulement par convention qu'on met en general un "=" dans
ces strings.
Les shells, a l'initialisation, pour chacune de ces strings pour
lesquelles ce qui est a gauche du premier "=" est compatible,
creent une variable shell de ce nom.
Dans l'environment, on peut tres bien avoir "=foo", "n*=xxx"...
Certains shells enlevent de l'environnement (c'est a dire ne le
passeront pas dans l'envp des commandes qu'ils executent) les
chaines qu'ils ne peuvent pas transformer en variables.
On recommende de ne mettre dans l'environnement que de xxx=yyy
où xxx peut etre une variable shell standard (alphanumerique,
underscore, ne commencant pas par un chiffre) et de preference
qui ne correspondent pas a une variable speciale des shell
communs (IFS, SECONDS, TMOUT, path...)
Cela semble casser certains programmes qui dumpent l'environnement et
s'attendent à pouvoir relire le résultat :
http://bugs.gentoo.org/show_bug.cgi?id!0580
Il me semble que le programme aura de toute façon d'autres soucis avec
les espaces et caractères spéciaux contenus dans les valeurs. La sortie
de env ne me semble pas pouvoir être sourcée sans précautions, non ?
Non, completement pas. Exemple typique: la variable TERMCAP
dont la valeur contient plusieurs lignes quand elle est definie.
La sortie de export -p est censee l'etre, mais voir:
http://groups.google.com/group/gnu.bash.bug/browse_thread/thread/22e185aff9bed206
et
http://bugs.debian.org/480371
Un programme en C peut placer avec setenv placer une variable d'environnement avec un "-" dedans. Si depuis ce programme, on invoque un shell, la commande env montre que cette variable est bien présente. Toutefois, il ne semble pas possible de la récupérer (même avec ${...}).
A-t-on le droit de placer un "-" dans une variable d'environnement ?
L'environnement est une liste de zero-terminated strings exactement comme la liste des arguments. argv et envp sont similaire.
C'est seulement par convention qu'on met en general un "=" dans ces strings.
Les shells, a l'initialisation, pour chacune de ces strings pour lesquelles ce qui est a gauche du premier "=" est compatible, creent une variable shell de ce nom.
Dans l'environment, on peut tres bien avoir "=foo", "n*=xxx"...
Certains shells enlevent de l'environnement (c'est a dire ne le passeront pas dans l'envp des commandes qu'ils executent) les chaines qu'ils ne peuvent pas transformer en variables.
On recommende de ne mettre dans l'environnement que de xxx=yyy où xxx peut etre une variable shell standard (alphanumerique, underscore, ne commencant pas par un chiffre) et de preference qui ne correspondent pas a une variable speciale des shell communs (IFS, SECONDS, TMOUT, path...)
Cela semble casser certains programmes qui dumpent l'environnement et s'attendent à pouvoir relire le résultat : http://bugs.gentoo.org/show_bug.cgi?id!0580
Il me semble que le programme aura de toute façon d'autres soucis avec les espaces et caractères spéciaux contenus dans les valeurs. La sortie de env ne me semble pas pouvoir être sourcée sans précautions, non ?
Non, completement pas. Exemple typique: la variable TERMCAP dont la valeur contient plusieurs lignes quand elle est definie.
La sortie de export -p est censee l'etre, mais voir:
http://groups.google.com/group/gnu.bash.bug/browse_thread/thread/22e185aff9bed206 et http://bugs.debian.org/480371
-- Stéphane
Vincent Bernat
OoO Lors de la soirée naissante du dimanche 29 juin 2008, vers 17:55, Stephane CHAZELAS disait :
La sortie de export -p est censee l'etre, mais voir:
http://groups.google.com/group/gnu.bash.bug/browse_thread/thread/22e185aff9bed206 et http://bugs.debian.org/480371
Merci pour tous ces renseignements. Effectivement, export -p n'affiche pas les variables non conformes. -- BOFH excuse #360: Your parity check is overdrawn and you're out of cache.
OoO Lors de la soirée naissante du dimanche 29 juin 2008, vers 17:55,
Stephane CHAZELAS <stephane_chazelas@yahoo.fr> disait :
La sortie de export -p est censee l'etre, mais voir:
http://groups.google.com/group/gnu.bash.bug/browse_thread/thread/22e185aff9bed206
et
http://bugs.debian.org/480371
Merci pour tous ces renseignements. Effectivement, export -p n'affiche
pas les variables non conformes.
--
BOFH excuse #360:
Your parity check is overdrawn and you're out of cache.
OoO Lors de la soirée naissante du dimanche 29 juin 2008, vers 17:55, Stephane CHAZELAS disait :
La sortie de export -p est censee l'etre, mais voir:
http://groups.google.com/group/gnu.bash.bug/browse_thread/thread/22e185aff9bed206 et http://bugs.debian.org/480371
Merci pour tous ces renseignements. Effectivement, export -p n'affiche pas les variables non conformes. -- BOFH excuse #360: Your parity check is overdrawn and you're out of cache.
