Forum Linux.général Login et chargement d'environnement.

• # Re: Login et chargement d'environnement.

  Posté par -=[ silmaril ]=- (site web personnel) le 01 février 2006 à 11:04. Évalué à 0.

  

  Extraordinaire ! quelqu'un qui construit une LFS sans savoir ce
  qu'il fait et sans connaitre les man ....
  
  man bash:
  

  
  
  INVOCATION
  Un shell est dit de login si le premier caractère de son argument numéro zéro est un -, ou s'il est invoqué avec l'option -login.
  
  Un shell est interactif si son entrée standard et sa sortie standard sont toutes deux connectées à un terminal (déterminé par la fonction
  isatty(3)), ou s'il est invoqué avec l'option -i. Le paramètre PS1 est positionné, et le paramètre $- contient la lettre i si bash est
  interactif, ce qui permet à un script ou à un fichier de démarrage de vérifier l'état du shell.
  
  Le paragraphe suivant décrit comment bash exécute ses fichiers d'initialisation. Si l'un de ces fichiers existe mais n'est pas accessible
  en lecture, bash signale une erreur. Les tildes sont remplacées par des noms de fichiers comme décrit dans le paragraphe Développement du
  Tilde de la section Développement.
  
  Lorsque bash est lancé comme shell de login interactif, ou comme shell non-interactif avec l'option --login, il lit et exécute tout d'abord
  les commandes se trouvant dans le fichier /etc/profile s'il existe. Après lecture de ce fichier, il recherche ~/.bash_profile,
  ~/.bash_login, et ~/.profile, dans cet ordre, et exécute les commande se trouvant dans le premier fichier existant et accessible en lecture.
  L'option --noprofile peut être utilisée au démarrage du shell pour empêcher ce comportement.
  
  Lorsqu'un shell de login se termine, bash lit et exécute les commandes du fichier ~/.bash_logout, s'il existe.
  
  Quand un shell interactif démarre sans être un shell de login, bash lit et exécute les commandes se trouvant dans ~/.bashrc s'il existe. Ce
  comportement peut être inhibé à l'aide de l'option --norc. L'option --rcfile fichier forcera bash à exécuter les commandes dans fichier
  plutôt que dans ~/.bashrc.
  
  Quand bash est démarré de manière non-interactive, pour lancer un script shell par exemple, il recherche la variable BASH_ENV dans l'envi-
  ronnement, développe son contenu si elle existe, et considère cette valeur comme le nom d'un fichier à lire et exécuter. Bash se comporte
  comme si la commande suivante se trouvait en début de script :
  if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi
  mais la valeur de la variable PATH n'est pas utilisée pour rechercher le fichier.
  
  Si bash est invoqué sous le nom sh, il essaye d'imiter le comportement de démarrage des versions historiques de sh autant que possible, tout
  en restant conforme au standard Posix. Lorsqu'il est invoqué comme shell de login interactif (ou non-interactif avec l'option --login), il
  essaye d'abord d'exécuter les commandes se trouvant dans /etc/profile et ~/.profile, dans cet ordre. L'option -noprofile peut toujours être
  utilisée pour désactiver ce comportement. Quand il est invoqué en tant que shell interactif sous le nom sh, bash consulte la variable ENV,
  développe sa valeur si elle est définie et utilise le résultat en tant que nom de fichier à lire et exécuter. Comme un shell invoqué sous
  le nom sh n'essaye pas d'exécuter d'autre fichier de démarrage, l'option --rcfile n'a aucun effet. Un shell non interactif invoqué sous le
  nom sh ne lit aucun autre fichier d'initialisation. Quand il est invoqué sous le nom sh, bash entre en mode posix après avoir lu les
  fichiers d'initialisation.
  
  Quand bash est invoqué en mode posix, avec l'option -posix sur la ligne de commande, il suit ce standard en ce qui concerne les fichiers de
  démarrage. Dans ce cas, la variable ENV est développée, et le fichier qui en résulte est exécuté. On n'exécute pas d'autre fichier d'ini-
  tialisation.
  
  Bash tente de déterminer s'il est exécuté par le démon lançant les shells distants (généralement appelé rshd ). Si bash se rend compte
  qu'il est exécuté par rshd, il lit et exécute les commandes de ~/.bashrc si ce fichier existe et est lisible. Il n'a pas ce comportement
  lorsqu'il est invoqué sous le nom sh. L'option --norc peut être utilisé pour interdire ce comportement, et l'option --rcfile permet de
  forcer l'utilisation d'un autre fichier, mais rshd n'utilise généralement pas ces options et ne permet pas non plus leur utilisation.
  
  Si le shell est lancé avec un identifiant effectif d'utilisateur (ou de groupe) différent de l'identifiant réel, et si l'option -p n'est pas
  utilisée, aucun fichier d'initialisation n'est lu, les fonctions du shell ne sont pas importées depuis l'environnement, la variable SHEL-
  LOPTS est ignorée si elle apparaît dans l'environnement, et l'identifiant effectif de l'utilisateur (du groupe) est remplacé par l'ID réel.
  Si l'option -p est fournie, le démarrage est le même mais l'ID effectif n'est pas modifié.
  
  

  
  Quand aux permission root:root et 644 pour tout les fichiers dans /etc

  • [^] # Re: Login et chargement d'environnement.

    Posté par pini le 01 février 2006 à 11:52. Évalué à 2.

    

    C'est très bien comme info, et je pense qu'on est tous capables de la trouver.
    En revanche, ayant déjà été dans la même situation que D B à m'arracher les cheveux sur les Bash Startup Files, je n'ai jamais trouvé de description convaincante sur la convention associée aux scripts suivants, et la façon propre de les appeler dans les ~/.bash_profile et ~/.bashrc :
    /etc/profile
    /etc/bashrc
    /etc/profile.d/*.sh
    Si quelqu'un a un pointeur sur une telle page, je prends et je plussoie des deux mains.
    --

  • [^] # Re: Login et chargement d'environnement.

    Posté par Gyro Gearllose le 01 février 2006 à 13:22. Évalué à 5.

    

    Dommage que tu veuilles être moralisateur dans ta réponse. Ca ne m'a pas empêché de "pertinenter" ton post, car il répond à la question, mais bon.
    Selon toi, si on installe un LFS, on est censé tout connaître ? Pour moi, c'était plutôt une façon didactique d'installer un linux, justement pour comprendre comment ça marche.
    Alors, merci bien, les systèmes info, man, --help, je connais et je sais lire. Mais ça n'empêche pas d'avoir des points d'ombre de de demander un éclaircissement à ceux qui savent.
    Voir mon post ci-dessous pour un complément de réponse.
    En lisant la doc, je n'avais pas fait attention, et je croyais que le /etc/bashrc était parsé par défaut par bash, mais ce n'est visiblement pas le cas. Tout le monde peut se tromper.
    Merci quand même.

• # logique

  Posté par fearan le 01 février 2006 à 11:46. Évalué à 2.

  

  il ne manquerai plus que ton shell se reload dès que tu changes les fichier de conf...
  
  Non il n'y a pas d'auto reload
  
  ensuite modifier les /etc/...
  
  déjà parler de "mon" fichier /etc/bashrc est une hérésie
  mon fichier ~/.bashrc oui, mais ce qui est dans /etc appartient au système et seul root a le droit de les modifier ( normalement )
  comme permissions un chmod 644 devrai être bon :P
  
  ensuite pour recharger un bash apres les avoir modifés : exec bash ( remplacement du process courrant par bash )
  pour recharger juste les fichier . ou source marchent très bien :)

  Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • [^] # Re: logique

    Posté par Gyro Gearllose le 01 février 2006 à 13:18. Évalué à 2.

    

    déjà parler de "mon" fichier /etc/bashrc est une hérésie
    
    Evidement, tourné comme ça, ça ne veut rien dire... Comme je travaille sur ma machine perso, je parlais de mon fichier, dans le sens "il m'appartient", pas au sens système....
    Pour le coup des droits, je suis d'accord, ça me va bien.
    Je pensais plutôt aux droits d'exécution, mais visiblement, il n'y en a pas besoin.
    Il faut quand même avouer que c'est un peu le bordel dans le chargement de ces fichiers....
    Si j'ai bien tout compris, le /etc/profile se charge tout seul ; il a la responsabilité de charger tout ce qui est dans /etc/profile.d/. Le ~/.bash_profile s'occupe de charger ~/bashrc. Ce dernier s'occupe de charger /etc/bashrc.
    Ben oui, c'est si simple !
    J'aurais plutôt pensé que bash saurait retrouver ses petits tout seul, mais non, ce n'est pas le cas. Par ailleurs, en fonctionnant ainsi, on peut voir l'environnement utilisateur écrasé par la conf système, alors qu'on se serait plutôt attendu au contraire.
    Pour le coup du rechargement, merci, je savais. Je n'en demandais pas tant !

    • [^] # Re: logique

      Posté par JolieLara le 02 février 2006 à 20:50. Évalué à 1.

      

      J'aurais plutôt pensé que bash saurait retrouver ses petits tout seul, mais non, ce n'est pas le cas. Par ailleurs, en fonctionnant ainsi, on peut voir l'environnement utilisateur écrasé par la conf système, alors qu'on se serait plutôt attendu au contraire.

      
      C'est justement le contraire: d'abord les fichiers système sont lus (ceux dans /etc/), puis ceux de l'utilisateur (~/.*rc).
      Lorsque tu te connectes (login en anglais) pour la première fois (après avoir rallumé ta machine, par exemple), ton fichier ~/.bash_profile est lu.
      Ensuite, à chaque lancement de console (non graphique) ou de terminal (dans un quelconque environnement graphique comme Gnome, KDE...), ton fichier ~/.bashrc est lu.
      Tu peux faire le test en lançant un terminal Gnome ou KDE, selon ce que tu utilises, dans lequel tu modifies ton fichier ~/.bashrc (en ajoutant un alias, par exemple).
      Si tu sors de l'éditeur de texte (vi, par exemple) et tapes ce nouvel alias, tu verras que ton shell courant (bash ici) ne le reconnaît pas parce que ce shell a lu ton fichier ~/.bashrc tel qu'il était avant que tu n'y ajoutes l'alias.
      En revanche, en lançant un autre terminal, il va lire le fichier ~/.bashrc avec le nouvel alias et tu verras que ce nouveau shell "connaît" ce nouvel alias...
      
      C'est encore plus "spectaculaire" en restant dans le même terminal et en lançant directement un nouveau shell, en tapant "bash": tu peux alors utiliser ton nouvel alias.
      Tape "exit" pour quitter ce nouveau shell: tu te retrouves dans l'"ancien" shell et là, le nouvel alias n'existe pas, puisque ce shell a été lancé avant que tu n'ajoutes cet alias dans ton ~/.bashrc! :-)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.