Configuration : .profile vs .bashrc, etc. Le sujet est résolu

[LuX]

Bonjour

Je m'aperçois que mon fichier ~/.profile ne semble pas lu lorsque j'ouvre un émulateur de terminal dans une session X, et bien lu lorsque je me connecte en tty. En tout cas les variables exportées dans ~/.profile (par exemple 'export PAGER="less -l"') restent vides dans mon xterm (echo $PAGER ne renvoie rien).

Sous Arch je croyais avoir compris :
- que ~/.profile était lu par tout login-shell, interactif ou non (donc aussi bien en tty qu'en X) ;
- que les non-login shells ouverts ensuite (dans un xterm par exemple) héritaient des valeurs exportées dans ~/.profile ;
- que ~/.bashrc était lu seulement ensuite par les non-login shells.
Dans la section 7.5.3 du guide de référence Debian je lis d'ailleurs que ~/.profile est bien lu au démarrage de la session X par gdm3. Du coup je comprends mal qu'il ne semble pas lu via d'autres DM évolués comme LightDM.

Si ça fonctionne différemment sous Debian, alors j'aimerais bien savoir : quels fichiers de configurations généraux sont lus au démarrage de la session et dans quel ordre, selon la façon dont on la lance ?

Je pense en priorité à ~/.profile et ~/.bashrc, mais aussi aux fichiers suivants :
- /etc/profile (en principe lu juste avant ~/.profile et dans les mêmes cas) ;
- /etc/bash.bashrc (en principe lu juste avant ~/.bashrc et dans les même cas) ;
- ~/.xinitrc (à ma connaissance lu si X lancé par startx (donc après .profile qui est lu par le tty), mais pas lu par les DM) ;
- ~/.xprofile (à ma connaissance lu après .profile par les DM évolués comme LightDM, mais pas slim, non lu par startx) ;
- ~/.bash_profile (jamais très bien su... je n'en ai pas créé).

Et pour le lancement je pense aux alternatives suivantes (je peux me tromper sur le type de certains des shells correspondants) :
- tty (login shell interactif) ;
- X lancé depuis un tty par startx (non-login shell non-interactif) ;
- X lancé via un gestionnaire de connexion évolué comme LightDM (login shell non-interactif) ;
- dans un xterm (non-login shell interactif) ;
- après un 'su' (login shell interactif ?).

---- EDIT 20/10/2017 ----
Après pas mal de tests, je crois pouvoir dire que sous Debian (contrairement à ce que je connaissais sous Arch) ne sont lus que les fichiers suivants :
- via LightDM : .xsessionrc puis .xinitrc (d'autres DM liront sans doute .xprofile et/ou .xsession plutôt que .xinitrc) ;
- via tty : .profile ;
- après startx : .xinitrc ;
- à l'ouverture d'un terminal : .bashrc (si bash = shell par défaut) ;
- après su : .bashrc (même remarque).
En outre :
- ce qui est lancé par startx hérite de tty (donc de ce qui est exporté dans .profile) ;
- su hérite des variables exportées par l'environnement de départ (le tty ou le terminal sous X) ;
- le terminal hérite de X (donc de ce qui est exporté dans .xsessionrc ou dans .xinitrc) ;
- enfin .xsessionrc est lu au début de la session X quel que soit le gestionnaire de connexion.
Du coup je fais sourcer .bashrc par .profile par .xsessionrc pour avoir la même chose partout (et j'ai rendu mon .profile dash-compatible, voir plus loin).
----------------------------------

Cordialement,

[vv222]

Ton souci de variable non exportée est du à une faute de syntaxe.

Tu as écrit :

Code : Tout sélectionner

export $PAGER="less -l"

Mais la bonne syntaxe est :

Code : Tout sélectionner

export PAGER="less -l"

[LuX]

@vv222 : C'est corrigé, merci !

Mais la coquille était dans mon post seulement, pas dans mon ~/.profile. La question demeure donc ouverte.

[MicP]

Code : Tout sélectionner

…
~/.profile était lu par tout login-shell, interactif ou non (donc aussi bien en tty qu'en X) ;
…

Non : en X, l'émulateur de terminal (xfce4-terminal, Xterm, Kterm, etc.) n'utilise PAS un login-shell
puisqu'on s'est déjà authentifié en ouvrant sa session X par le gestionnaire de connexion (LightDm, Gdm, Kdm, etc.)
donc, ~/.profile n'est pas pris en compte

https://wiki.archlinux.org/index.php/ba ... tion_files

[vv222]

Mon ~/.profile est bien pris en compte dans ma session graphique, mais je passe par startx depuis un tty, pas par un gestionnaire de session.
Je pense que dans mon cas le ~/.profile est chargé quand j’ouvre ma session en tty, et que la session X hérite des variables ainsi définies.

[MicP]

… dans mon cas le ~/.profile est chargé quand j’ouvre ma session en tty,…

Oui : car dans ton cas, ton fichier ~/.profile a été pris en compte quant tu t'es identifié dans le terminal (donc : login-shell) avant que le serveur X ne soit lancé

[LuX]

Merci pour vos réponses.

Tout ce que j'ai lu (par exemple dans le man de bash) et expérimenté (par exemple un 'su -') le confirme : .profile est lu seulement au démarrage d'un login shell. S'il n'est pas lu ici (que ce soit en passant par lightdm, startx, su, xterm, etc... même s'il est lu avant si je lance ces commandes via un tty, comme le rapporte vv222) c'est parce que ces commandes n'ouvrent pas de login shell.

Code : Tout sélectionner

…
~/.profile était lu par tout login-shell, interactif ou non (donc aussi bien en tty qu'en X) ;
…

Non : en X, l'émulateur de terminal (xfce4-terminal, Xterm, Kterm, etc.) n'utilise PAS un login-shell
puisqu'on s'est déjà authentifié en ouvrant sa session X par le gestionnaire de connexion (LightDm, Gdm, Kdm, etc.)
donc, ~/.profile n'est pas pris en compte

Effectivement, c'est comme ça sous Debian. Mais pas sous Arch !
Je suis reparti de cette page qui explique bien les choses :

When you log in on a text console, or through SSH, or with su -, you get an interactive login shell. When you log in in graphical mode (on an X display manager), you don't get a login shell, instead you get a session manager or a window manager.
It's rare to run a non-interactive login shell, but some X settings do that when you log in with a display manager, so as to arrange to read the profile files.

Le "some X settings do that..." s'applique à Arch, d'après mon expérience : mon ~/.profile était lu à la connexion avec LightDM (ou slim, ou GDM...) sans que je ne fasse rien de spécial, ce qui confirme qu'un login-shell non interactif est lancé à la connexion, quelque soit le DM employé.

Ma question devient donc : comment faire, sous Debian, pour que le lancement de X hérite toujours d'un login shell (comme si on passait par tty+startx) ?

C'est peut-être un peu tordu, mais je pense que ça répondrait vraiment à ce que je veux : que le ~/.profile soit lu dans tous les cas, sans avoir à le sourcer un peu partout (au risque de faire des boucles, car mon ~/.profile source mon ~/.bashrc) ni à paramétrer lightdm pour ça (et perdre ce comportement quand je changerai de DM).

---- EDIT ----
Je pense que la réponse est dans le man de Xsession, mais malheureusement je n'en comprends pas tout. En tout cas j'y ai trouvé une solution de contournement : créer ~/.xsessionrc et y mettre la ligne suivante.

Code : Tout sélectionner

. $HOME/.profile

Ce fichier n'existait pas avant donc je suis sûr qu'il n'y aura pas de boucle, et il est effectivement lu au lancement de X (donc aussi le ~/.profile, du coup). Je préférerais un truc plus global, mais ce n'est déjà pas mal.
------------------

[MicP]

…Je préférerais un truc plus global,…

Dans ce cas, il te faudrait ajouter ton ~/.xsessionrc dans le répertoire personnel de chaque utilisateur déjà existant, et ajouter aussi ce fichier dans /etc/skel/ pour les futur utilisateurs qui seront créés.

Voir aussi : https://wiki.debian.org/Xsession#User_configuration

[LuX]

Oui... mais non : de façon très étrange, la lecture du ~/.xsessionrc ne donne pas exactement le résultat attendu.

Le fichier ~/.profile est bien sourcé, et les variables qu'il modifie sont bien exportées (par exemple echo $PAGER donne ce qu'il faut). Et pourtant il y a un truc qui ne fonctionne pas normalement : les codes ANSI. J'utilise des variables propres à less pour avoir des page de man en couleur :

Code : Tout sélectionner

export LESS_TERMCAP_mb=$'\E[1;31m'     # begin bold
export LESS_TERMCAP_md=$'\E[1;33m'     # begin blink
export LESS_TERMCAP_me=$'\E[0m'        # reset bold/blink
export LESS_TERMCAP_so=$'\E[01;44;33m' # begin reverse video
export LESS_TERMCAP_se=$'\E[0m'        # reset reverse video
export LESS_TERMCAP_us=$'\E[1;36m'     # begin underline
export LESS_TERMCAP_ue=$'\E[0m'        # reset underline
export GROFF_NO_SGR=1                  # for konsole and gnome-terminal

Ça fonctionne bien en tty, mais pas dans un xterm. Et pourtant le ~/.profile a bien été lu dans les deux cas, et les variables ont les valeurs attendues. Sauf que... si je re-source le ~/.profile dans le xterm, là ça marche !

Code : Tout sélectionner

*** Ouverture d'un xterm
$ echo $PAGER
less -s
$ echo $LESS_TERMCAP_md
\E[01;33m
$ man Xsession
s handle this.

       By  default  on  a Debian system, \E[01;36mXsession\E[0m is used by both common methods of starting the X Window System, \E[01;33mxdm\E[0m (or another X
       display  manager)  and  \E[01;33mstartx\E[0m.   To  change  this  for   \E[01;33mxdm,\E[0m   edit   the   ‘DisplayManager*session’   resource   in   the
       
       *** etc : les codes ANSI semblent insérés mais non interprétés.

$ . ~/.profile
$ echo $LESS_TERMCAP_md
        *** Pas de réponse visible, mais le prompt de la ligne suivante est en gras (le code ANSI de $LESS_TERMCAP_md).
$      *** Appui sur 'Enter', prompt de la ligne suivante redevenu normal.
$ 
$ man Xsession
Xsession(5)                                             File Formats Manual                                             Xsession(5)

NAME
       Xsession - initialize X session

SYNOPSIS
       Xsession [ session-type ]

DESCRIPTION
       /etc/X11/Xsession  is  a Bourne shell (sh(1)) script which is run when an X Window System session is begun by startx(1) or a
       
      *** etc : affichage normale, avec les couleurs attendues. 

Je précise que le résultat est le même que j'utilise terminator, gnome-terminal, uxterm ou lxterm.
Plutôt space, non...

[Mimoza]

J'apporte ma pierre …
Bashrc est lié au shell Bash. Il existe bien d'autre shell qui ont leur propre fichier «rc», par exemple Zsh qui a Zshrc.

[LuX]

@Mimoza: Merci pour ta remarque. Je ne parle que de .bashrc car j'utilise bash, mais en effet quelqu'un qui utilise d'autres shell aura d'autres fichiers de configuration pour son shell.

Cela dit, ça ne m'avance pas pour mon problème avec less. Comment se fait-il que, alors que les variables LESS_TERMCAP_xx soient affectées correctement grâce à la lecture de .profile en tty comme sous X, on ait la bizarrerie suivante :
- less n'affiche bien les couleurs qu'en tty, pas dans un xterm (où il affiche les codes ANSI littéralement) ;
- une fois rechargé le .profile dans le xterm, less affiche les couleurs correctement.
???

Est-ce que quelqu'un aurait une idée ?

[MicP]

Bonjour

…si je re-source le ~/.profile dans le xterm, là ça marche …


Effectivement : ça marche cette fois là, parce que ~/.profile a été sourcé par /bin/bash

sinon ~/.xsessionrc (qui avait sourcé ~/.profile) était exécuté par /bin/dash

=======
Pour que les valeurs des codes d'échappement
puissent êtres interprétées par /bin/dash aussi bien que par /bin/bash avant d'être assignés aux variables,

on pourrait les formuler comme ci-dessous :

Code : Tout sélectionner

export LESS_TERMCAP_mb=$(printf '\033[1;31m')     # begin bold
export LESS_TERMCAP_md=$(printf '\033[1;33m')     # begin blink
export LESS_TERMCAP_me=$(printf '\033[0m')        # reset bold/blink
export LESS_TERMCAP_so=$(printf '\033[01;44;33m') # begin reverse video
export LESS_TERMCAP_se=$(printf '\033[0m')        # reset reverse video
export LESS_TERMCAP_us=$(printf '\033[1;36m')     # begin underline
export LESS_TERMCAP_ue=$(printf '\033[0m')        # reset underline
export GROFF_NO_SGR=1                             # for konsole and gnome-terminal

[LuX]

Merci de ta réponse, c'était bien là le problème.

J'avais aussi essayé avec printf mais ça ne marchait pas non plus, donc à cause des '\E' :

Code : Tout sélectionner

export LESS_TERMCAP_mb=$(printf '\E[1;31m')

Et la commande 'source' non plus ne marchait pas, j'ai mis un temps fou à m'apercevoir qu'il fallait la remplacer par un "." (et jusqu'ici je ne savais pas d'où venait cette différence).

C'est assez déroutant que le premier shell de l'utilisateur soit dash alors qu'il est bien spécifié dans /etc/passwd que son shell par défaut est bash !!
D'ailleurs, pourquoi est-ce que ça marchait en tty ?

En tout cas merci à tous pour vos réponses, cette fois le sujet est "résolu".

[MicP]

…C'est assez déroutant que le premier shell de l'utilisateur soit dash…

Quand le fichier ~/xsessionrc est "sourcé" on en est encore à l'initailisation de la session
qui sera utilisée par le compte utilisateur, => ce n'est pas encore un shell qui sera utilisé par le compte utilisateur.

=======

Code : Tout sélectionner

michel@debg53sw:~$ head /etc/X11/Xsession
#!/bin/sh
#
# /etc/X11/Xsession
#
# global Xsession file -- used by display managers and xinit (startx)

# $Id: Xsession 967 2005-12-27 07:20:55Z dnusinow $

set -e

michel@debg53sw:~$ 


Et c'est dans ce même fichier qu'on retrouve :


Code : Tout sélectionner

michel@debg53sw:~$ grep \$HOME/.xsessionrc /etc/X11/Xsession
USERXSESSIONRC=$HOME/.xsessionrc
michel@debg53sw:~$ 


=======
Ci dessous, le fichier qui va "sourcer" ~/.xsessionrc

Code : Tout sélectionner

michel@debg53sw:~$ cat /etc/X11/Xsession.d/40x11-common_xsessionrc
# This file is sourced by Xsession(5), not executed.

#Source user defined xsessionrc (locales and other environment variables)
if [ -r "$USERXSESSIONRC" ]; then
  . "$USERXSESSIONRC"
fi
michel@debg53sw:~$ 


=======
Et un extrait de : https://wiki.debian.org/Xsession#System ... figuration
expliquant que le script ci-dessus est bien exécuté par /bin/sh

Code : Tout sélectionner

System-wide configuration

System-wide configuration of the Debian X session consists mainly of options inside the /etc/X11/Xsession.options file, and scripts inside the /etc/X11/Xsession.d directory.
These scripts are all dotted in by a single /bin/sh shell, in the order determined by sorting their names.
…

[LuX]

Merci MicP pour ces explications très claires et très précises. La page de wiki que tu cites dit d'ailleurs exactement ce qu'il m'aurait fallu saisir dès le départ :

User configuration may be done in a few different ways. The simplest way is to create a ~/.xsessionrc file, which will be used by all X session types. It is read by a POSIX shell (/bin/sh, typically provided by dash).
...
If you choose to dot in one of your regular shell dot files, make sure it does not use bash specific features, zsh specific features, ksh specific features, etc.

[MicP]

D'autre part,
au sujet des différents printf


Et même un troisième printf

Code : Tout sélectionner

michel@debg53sw:~$ file $(which printf)
/usr/bin/printf: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=c91a006cae33d9fbc60397a6d0c7dd08e0b828d2, stripped
michel@debg53sw:~$ 

=======
Même chose pour echo : un pour dash, un autre pour bash, et encore un qui est un exécutable : /bin/echo

En conclusion, il vaudrait peut-être mieux utiliser une syntaxe POSIX de la commande printf quand c'est possible.

Ce qui aurait donné :

Code : Tout sélectionner

printf "\n\033[01;44;33m%s\033[0m\n\n" "inverse"

[LuX]

Merci pour ces infos, très intéressantes mais quelque peu... déconcertantes.
Si je comprends bien une même commande printf ou echo dans un script shell renverrait à des programmes différents, utilisant une syntaxe différente, suivant la façon dont le script est appelé ? Il y a de quoi s'arracher les cheveux !

J'ai cherché un peu ce que tu appelles la syntaxe POSIX mais apparemment POSIX est un ensemble de normes très large, et je n'ai pas compris en quoi la page que tu pointes décrivait cette syntaxe. En particulier on n'y parle pas des différents codes d'échappement que tu as testés (\E[, \e[ et \033[). Ils n'apparaissent d'ailleurs pas non plus sur la page wikipédia des codes déchappement ANSI.

En tout cas merci pour tes tests, qui montrent bien ce qui se passe et pourquoi en pratique il faut préférer \033[ aux deux autres (en tout cas sous Debian).

[MicP]

…je n'ai pas compris en quoi la page que tu pointes décrivait cette syntaxe.…

Code : Tout sélectionner

POSIX printf 
…
EXTENDED DESCRIPTION
…

7 An additional conversion specifier character, b, shall be supported as follows. …
…
    "\0ddd", where ddd is a zero, one, two, or three-digit octal number that shall be converted to a byte with the numeric value specified by the octal number
…

=======

…différents codes d'échappement que tu as testés (\E[, \e[ et \033[)…

\e et \E sont des entités qui sont prédéfinies dans l'interpréteur de commande bash et qui seront transformées en séquence d'échappement

Voir le chapitre QUOTING dans la page man affichée par la commande suivante

Code : Tout sélectionner

man -LC bash

(tu peux aussi essayer de comprendre (en tournant en rond… :icon_e_biggrin: ) avec la page man de bash en version française)

Le caractère d'échappement peut être représenté dans des bases arithmétiques différentes
suivant la commande qui va permettre d'entrer cette séquence d'échappement
et le contexte dans laquelle cette commande sera utilisée :

Code : Tout sélectionner

en base décimale     : 27
en base octale       : 33
en base hexadécimale : 1B