Discussion :

[Invité]

Bonjour,

Je souhaiterais avoir accès à une variable d'environnement personnelle (VCCTL_HOME) à partir d'une classe Java.

La version de Java que j'utilise est soit la 1.5, soit la 1.6 (je développe et teste sur plusieurs machines), System.getenv() est donc dispo.

Lorsque j'utilise System.getenv(), j'ai bien accès aux différentes variables d'environnement telles que JAVA_HOME, PATH, SHELL etc. mais la mienne n'apparaît pas dans la liste.

Je précise que ma variable est définie dans mon .profile et que lorsque je fais un echo $VCCTL_HOME elle apparaît bien.

Donc comment se fait-ce qu'elle n'apparaisse pas avec System.getenv()?



Question subsidiaire: donc apparemment pas de moyen simple d'accéder aux variables d'environnement persos avec Java 1.4 si on ne les connaît pas à l'avance?


Complément: le pourquoi du comment.

Pourquoi utilise-je cette variable? Car c'est l'installeur que nous utilisons qui place un répertoire dont je me sers (il contient entre autres choses des exécutables écrits en C que je lance à l'aide de Java) où l'utilisateur le spécifie.
Je ne sais pas à l'avance où se trouve se répertoire car l'utilisateur peut l'installer où il veut sur sa machine. C'est pour cela que je stocke le chemin d'accès dans ma variable d'environnement JAVA_HOME

Merci d'avance!

[Edit]J'ai oublié de préciser: tout ça c'est sous Tomcat

PS: je suis sous Mac OS 10.4 et l'appli tourne également sous Linux et Windows

[Invité]

Personne?

[adiGuba]

Salut,

Je précise que ma variable est définie dans mon .profile et que lorsque je fais un echo $VCCTL_HOME elle apparaît bien.

Il faut l'exporter, si je ne me trompe pas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

export VCCTL_HOME

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

export VCCTL_HOME=ton_chemin

Sinon les variables sont utilisables seulement au niveau du shell (c'est une spécificité des shell unix il me semble).


a++

[Invité]

Pardon, je me suis mal exprimé: je voulais dire que ma variable était exportée dans mon .profile

[Invité]

Personne n'a été confronté à ce problème?

[adiGuba]

Si la variable est bien exporté tu devrais normalement y avoir accès :

• Vérifies bien le nom de la variable (les Unix sont case-sensitive !)
• As-tu relancé la console après avoir modifié ton profile, car les modifs ne sont pas prise en compte immédiatement.
• Dans ton premier message tu parles de VCCTL_HOME et de JAVA_HOME : faute de frappe ?

a++

[Invité]

Si la variable est bien exporté tu devrais normalement y avoir accès :

• Vérifies bien le nom de la variable (les Unix sont case-sensitive !)
• As-tu relancé la console après avoir modifié ton profile, car les modifs ne sont pas prise en compte immédiatement.
• Dans ton premier message tu parles de VCCTL_HOME et de JAVA_HOME : faute de frappe ?

a++

Oui, tout est OK.

VCCTL_HOME, c'est le nom de ma variable d'environnement définie dans mon .profile, celle à laquelle je n'arrive pas à accéder.

J'ai discuté avec un pote et pour lui le problème vient du fait que la JVM est lancée avant que le .profile ne soit lu par le système (il me semble au passage que le .profile est lu au moment du login et que donc il n'y a plus besoin de lancer de shell une fois que le login est fait) et que la JVM n'est pas informée des nouvelles variables d'environnement exportée après son lancement.

Vous en pensez quoi?

[adiGuba]

Vous en pensez quoi?

Si la JVM est lancé avant le .profile c'est normal : les applications reçoivent leur propre environnement lorsqu'elles sont lancées, et cet environnement n'est pas partagé entre les applications.

Donc s'il est modifié par la suite ce n'est pas pris en compte...


a++

[Invité]

Si la JVM est lancé avant le .profile c'est normal : les applications reçoivent leur propre environnement lorsqu'elles sont lancées, et cet environnement n'est pas partagé entre les applications.

Donc s'il est modifié par la suite ce n'est pas pris en compte...


a++

Il est donc impossible d'accéder à des variables d'environnement définies par l'utilisateur étant donné qu'apparemment la JVM est lancée avant le login…

Hum… C'est embêtant ça… Ça limite fortement l'intérêt de la chose…

Merci en tout cas.

Il va donc falloir que je trouve un moyen pour savoir où l'utilisateur a choisi d'installer le dossier dont nous nous servons… J'avais pas envie de créer un fichier et de le parser mais bon, on dirait que je vais y être obligé

[bouye]

[HS]

J'ai discuté avec un pote et pour lui le problème vient du fait que la JVM est lancée avant que le .profile ne soit lu par le système (il me semble au passage que le .profile est lu au moment du login et que donc il n'y a plus besoin de lancer de shell une fois que le login est fait)

Il est toutefois possible (du moins sous Linux) de recharger le .profile (ou ses equivalent, ex: .bash_profile) s'il a ete modifie dans le shell courant en utilisant la commande source :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

~>source .bash_profile

Cela n'impacte bien sur que le shell courant/actif.
[/HS]

N'est-il pas possible de specifier cette variable au niveau du system dans l'un des scripts d'initialisation globaux du systeme (/etc/profile, /etc/rc.local, ... ?) ; voir carrement dans le script d'initialisation de la JVM /etc/rc.kekchose s'il y en a un ?

[Invité]

[HS]
Il est toutefois possible (du moins sous Linux) de recharger le .profile (ou ses equivalent, ex: .bash_profile) s'il a ete modifie dans le shell courant en utilisant la commande source :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

~>source .bash_profile

Cela n'impacte bien sur que le shell courant/actif.
[/HS]

Ça ne réglera pas mon problème je pense.

N'est-il pas possible de specifier cette variable au niveau du system dans l'un des scripts d'initialisation globaux du systeme (/etc/profile, /etc/rc.local, ... ?) ; voir carrement dans le script d'initialisation de la JVM /etc/rc.kekchose s'il y en a un ?

Je préfère ne pas avoir à faire ça. De toutes façon, l'utilisateur n'est pas nécessairement root.