1 votes

La variable globale n'est pas automatiquement chargée à partir de .profile

Afin de configurer CUDA 9.1, j'ai lu qu'il était pratique d'ajouter son dossier d'installation à l'emplacement suivant PATH y LD_LIBRARY_PATH comme :

PATH="/usr/local/cuda-9.1/bin:$PATH"
LD_LIBRARY_PATH="/usr/local/cuda-9.1/lib64:$LD_LIBRARY_PATH"

Suivant ce y ce SE réponses J'ai essayé d'éditer mon .profile en ajoutant les dernières lignes comme ci-dessous.

# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.

# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022

# if running bash
if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists
    if [ -f "$HOME/.bashrc" ]; then
    . "$HOME/.bashrc"
    fi
fi

# set PATH so it includes user's private bin directories
PATH="$HOME/bin:$HOME/.local/bin:$PATH"

# settings for CUDA
PATH="/usr/local/cuda-9.1/bin:$PATH"
LD_LIBRARY_PATH="/usr/local/cuda-9.1/lib64:$LD_LIBRARY_PATH"

Avec .profile comme ci-dessus, je peux ouvrir un terminal et exécuter echo $PATH pour voir que l'instruction a fonctionné, comme PATH contient maintenant le dossier que j'ai indiqué. Toutefois, pour une raison quelconque, cela ne fonctionne pas pour LD_LIBRARY_PATH .

Je suppose que le problème pourrait être que LD_LIBRARY_PATH n'existait pas auparavant, j'ai donc tenté de modifier .profile avec le code légèrement différent ci-dessous aux 2 dernières lignes.

PATH="/usr/local/cuda-9.1/bin:$PATH"
export LD_LIBRARY_PATH=/usr/local/cuda-9.1/lib64

Mais une fois encore, sans succès.

En remarquant le premier avertissement au début du .profile j'ai vérifié si j'avais un ~/.bash_profile ou un ~/.bash_login fichiers. Ils n'existent pas, et dans tous les cas, ils n'expliqueraient pas comment mon PATH est mis à jour avec succès.

En faisant quelques recherches, je suis tombé sur cet autre réponse, qui explique que .profile n'est pas nécessairement exécuté lorsque j'ouvre un terminal. Cependant, là encore, comment expliquer que PATH est mis à jour ?

Quel pourrait être le problème ? Y a-t-il un problème de syntaxe ?

EDIT:

J'ai essayé de me déconnecter et de me reconnecter après avoir changé le mot de passe. .profile pour contenir

PATH="/usr/local/cuda-9.1/bin:$PATH"
export LD_LIBRARY_PATH=/usr/local/cuda-9.1/lib64

et cela fonctionne maintenant. Si j'entre dans un terminal et que je tape echo $LD_LIBRARY_PATH Je le vois enfin. Je ne comprends toujours pas pourquoi la première version de ma liste d'instructions n'a pas fonctionné...

2voto

Wade73 Points 2102

La raison pour laquelle PATH fonctionne sans export c'est qu'il est défini comme une variable environnementale avant que ~/.profile est exécuté. Pour changement une variable d'environnement existante,

VAR=foo

est suffisante.

A ajouter une variable à l'environnement, vous devez faire

export NEWVAR=bar

Veuillez consulter Variables d'environnement pour de plus amples informations sur le sujet.

0voto

George Udosen Points 33267

Je pense que votre solution est explicite, la export a fait l'affaire et est nécessaire pour "exporter" les variables d'environnement à utiliser. Vous pouvez exporter les variables Shell en utilisant la commande export.

Pour voir la liste des variables exportées, exécutez export -p

Ver man bash :

export [-fn] [name[=word]] ...
export -p
           The  supplied  names are marked for automatic export to the environment of subsequently executed commands.  If the -f option is given, the names
           refer to functions.  If no names are given, or if the -p option is supplied, a list of names of all  exported  variables  is  printed.   The  -n
           option  causes  the  export property to be removed from each name.  If a variable name is followed by =word, the value of the variable is set to
           word.  export returns an exit status of 0 unless an invalid option is encountered, one of the names is not a valid shell variable name, or -f is
           supplied with a name that is not a function.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X